“How do I get developers to respond to customers in a timely manner?”

Recently someone wrote to me about a few of the challenges they’ve been facing with their support team. There was one problem in particular that made my ears perk up:

Biggest hurdle right now: making sure that a person who takes responsibility for a support request gets back to the customer in a timely manner, without being distracted by something else. Developers… ;-)

Developers dropping the ball when it comes to support is an endemic problem, and manifests itself in so many ways. Sometimes it’s forgetting to follow-up with the customer, other times it’s not actually apologizing for a mistake, or even dismissing bugs as “not reproducible” after just a few minutes of testing.

As a developer, I can understand why these things happen. It’s really hard to break the habit of thinking of bugs as a punch-list: knock it out and move onto the next thing as quickly as possible.

A disconnect problem

Developers are in a unique position where they directly affect the day-to-day operations of an application but can be totally disconnected from the user’s mindset. You can spend all day working on new features, performance tuning, or refactoring code. Heck, you can even fix bugs without knowing anything about who reported them: “Just give me steps to reproduce and I’ll look into it”.

Problems with following up, empathizing, or communication are signs that your developers aren’t actively invested in your customers. To them, the customers are an outside force that pokes at the program and occasionally causes some…interesting state changes. When we trip and fall we don’t try to see the issue from gravity’s perspective; likewise a disconnected developer focuses on the bug, not the nebulous “Customer”.

If we want better apps and happier customers, we need to remove this disconnect.

How can you fix it?

One of the best parts about working at Noko is how developers stay connected to our customers. I’ve always done my best work when I can directly see how it affects users and talk to them. At Noko, we make this happen with a combination of culture, workflow tweaks, and intelligent notifications.

A Support Culture

We emphasize customer support across the entire team. At the bare minimum, everyone knows how to write a good, basic support response. This is because we all talk directly to the customer in some form or another, and invariably someone’s hit a snag in the app. Even if all you can say is “I’m not quite sure, but going to look into this and get back to you ASAP!”, it’s better than throwing the customer a wet towel and retreating into your shell.

Why is it so important to talk directly to the customer, even if it’s awkward and painful and you hate it so much? Because it builds awareness for who actually uses your app, what problems they run into, and why you’re in business.

Mistakes will most certainly be made and you’ll run into some rough patches, but doing this makes you better at your job. I’m not only better at writing support messages, I also care more about how our customers feel when they use Noko. It also motivates me to write better code because I know some of the people who will end up using it, and I don’t want to let them down.

It actually makes bug fixing easier too! You aren’t fighting some unknowable “Customer” force pushing against your app, you gain intuition and insight into why these bugs happen. So it’s a win-win-win: Your customers like you more, you write more bug-free code, and it takes less time to fix the bugs that do come up.

Workflow Adjustments

At Noko, developers have a fair bit of autonomy over the support process. When there’s a bug, a developer coordinates with the support staff to figure out exactly what to ask the customer (something I’ll be writing about in the next few weeks). The developer also replies to any additional contact from the customer, since they’re the ones responsible for the outcome. Finally, the developer is the one who replies back to the customer to let them know the bug’s been fixed.

There’s a fair bit going on behind the scenes that makes this happen smoothly. The first and foremost thing is that developers can ask for coaching from the support staff. A lot of awkwardness when developers handle support stems from a lack of confidence in their response.

Developer: Hey #support, can you look over this response? I’m trying to let the customer know that X is fixed, but I’m still working on Y. Y’s more tricky than I anticipated, so it might take me a bit longer but I’m focusing all my effort on it:

Hey there!

I’ve finished fixing X, so you should be good to go there. :) Unfortunately, I’m still working on Y, which is a little more tricky than I anticipated.

Best,

Support: Yeah, sure thing, reading it now! :)

I think the first part is pretty good! You might want to open with “I have some good news, I’ve finished…” . I think the last part could use some tweaking though.

Starting off with “Unfortunately, …” kinda makes it sound like you’re disappointed to be fixing the bug they reported. I get what you’re trying to say (that you’re sorry that you haven’t fixed the bug yet), but I think the customer would be much happier hearing that you’re focusing all your effort on Y.

“I’m hard at work fixing this for you!” feels much better than “Your problem is a lot harder than I anticipated”; and who knows, you might make a breakthrough soon. :)

So maybe something like: “I’m working on Y right now, and I’ll let you know as soon as it’s fixed! :)”

I would also end with “Thank you for all the info and being so patient as we get this fixed for you,” they’ve been super helpful with figuring this out.

Developer: Thanks, that makes a lot of sense! Fixing it up now.

Good coaching builds a developer’s confidence and gives them a “framework” for handling issues on their own. It becomes a lot easier once a developer has a few templates to work from and a good handle on the tone.

We’ve also integrated our support tool and issue tracker. It’s basic, but it’s done a lot to create a consistent flow from support to development, and back again:

We get a support message, and once it’s confirmed as a bug the support staff makes a new issue. The new issue includes a link to the support message.
Since we use a “branch/pull request” workflow, developers make sure the branch name starts with the issue number and the pull request links back to the issue.
Once the PR is merged, the developer just has to follow the links to reply back to the customer.

But, the million dollar question is: How do you get developers to do that last step? What’s stopping them from forgetting to email the customer?

Intelligent Notifications

Slack helps us make sure we all follow through in support. Our Slack has a #supportops channel, where a bot posts an activity feed from our support tool. Any time a customer writes in, someone replies to a message, internal notes are added to a conversation, or someone’s assigned to a conversation; it shows up in the feed. This adds a level of accountability, because everyone can see when you don’t get back to a customer. And it helps the team help each other. I’ve had moments where I got caught up in something else and one of my coworkers nudged me, “have you replied to that customer yet?” Also: when something happens in a conversation I’m assigned to, the bot @-mentions me. If I’m busy, I can mark that @-mention as unread so I don’t forget

The payoff

While it does involve playing traffic cop for a bit, engaging your developers throughout the support process can have a huge payoff. Not only will your developers get back to customers faster (and with better responses), they’ll also start writing more bug-free code. Creating an easily trackable workflow speeds up the bug fixing process for everyone, and coaching developers on how to write support messages will help the support staff write better ones themselves.