Engineering · 3 min read
Support and customer care
Support is craft, not a cost center. Here's how we treat the people who use what we make.
How you treat people when something goes wrong tells them more about you than anything you say when it's going right. Support is where that happens, and we refuse to treat it as a cost to minimize. It's craft, same as the code and the design, and it's one of the clearest places our values show up or don't.
The people who build it help support it
We don't build a wall between the people who make the thing and the people who answer for it. The person who wrote the code is often the person who can actually fix your problem, and putting them within earshot of the people hitting it keeps everyone honest. It's harder to ship a confusing thing when you're the one explaining it at the other end.
This is the same instinct as how we build: you own what you ship, and owning it doesn't stop at deploy. Support isn't a department that catches what engineering throws over the wall. It's part of owning the work all the way through.
Fast and honest beats polished and slow
When you're stuck, a quick honest answer is worth ten slow polished ones. So we aim to reply fast, say what we actually know, and not hide behind a script. If it's a bug, we say it's a bug. If we don't know yet, we say that too, and we say when we'll know more. If we broke it, we own it instead of reaching for the passive voice.
People can tell the difference between a real person working the problem and a form letter buying time. We'd rather be the first thing, even when the honest answer is "you've found a rough edge and we haven't fixed it yet."
The tone we're after
Talk to people the way you'd want a sharp friend to talk to you when you're stuck: direct, warm, no runaround, and never pretending the problem is smaller than it is.
Every support conversation is a signal
A support ticket isn't just a thing to close. It's the product telling you where it's confusing, where it breaks, where the docs went quiet exactly when someone needed them. The same question three times isn't three tickets; it's one thing to fix. We treat the pattern in what people ask as a roadmap, and the best outcome of a support conversation is often a change that means nobody has to ask again.
That's why support living close to the people who build matters. The signal is worth the most when it reaches someone who can act on it, before it gets flattened into a number on a dashboard.
Never make someone feel stupid
Nobody hits a rough edge on purpose. When someone's confused, that's usually the product's failure to be clear, not the person's failure to be smart, and we answer like we believe that. No condescension, no "as stated in the docs," no making a person feel small for not knowing the thing we never explained well.
Being warm here isn't softness; it's respect, and it's part of our values. The people who use what we make are trusting us with their time and their work. Treating a support conversation as a chance to earn that trust, rather than a ticket to clear, is the whole point. If someone walks away from a rough moment feeling respected, we did the job right, even on a day the product let them down.