'Just five minutes' does not exist

"It is only an email." "Just five minutes on the phone with the customer. Tom can do that." This is how people react when a technical customer question reaches your developers. They treat it as a small task between other work.

It looks that way. They know the answer from memory. They type it in three minutes.

Those five minutes are not five minutes

Chris Parnin studied how programmers deal with interruptions. Parnin analysed 10,000 programming sessions from 86 developers, and the result was the same each time. After an interruption, a developer needs ten to fifteen minutes before they start to edit code again. They are not slow. The problem is context. They held the details in their head: which function was open, and where they were in the code. The interruption removes that context, and they must build it again. In only one out of ten cases did a developer continue within one minute.

So that email does not cost them three minutes. It costs them twenty. This happens a few times each day. As a result, a developer keeps only one period of two hours without interruption in a full day. That number is also from Parnin.

That research is in the Software Quality Journal. Parnin also wrote a clear summary in Programmer Interrupted.

A routine question is not expensive because the answer is hard. It is expensive because it takes the developer away from the work that only they can do.

Why the question still reaches your developer

The answer to a technical customer question is rarely in a place where the customer or a colleague can find it. It is in the code, in a pull request from last month, or in the head of the person who built the feature.

A chatbot on your website does not solve this. On a technical product, a chatbot is a risk. It cannot always tell when it does not know the answer, so it gives an answer that sounds correct but is wrong. The customer uses that answer, it does not work, and the question reaches your developer anyway. Now the developer must also correct the wrong answer.

A wiki or an FAQ has a different problem. It is correct on the first day. It becomes out of date on the second. Six months later, it answers questions about a version of your product that no longer exists, and no one on the team trusts it. We explain why documentation becomes out of date, and what helps against it, in How do you keep your knowledge base up to date automatically?.

One reliable way stays: you ask the person who built it. And this way works. The customer gets a correct answer, and usually a fast one. This is why almost every software company uses it. But it is the most expensive way to answer a question, and Parnin's numbers show you why.

The best way to do it

The best way to automate technical customer questions has one rule: a human answers each question only one time.

A customer asks something that is written down nowhere. Your colleague answers it, as always. But this time the answer does not disappear. The system saves it. The next customer with the same question gets that answer directly, with your own team's words, not a guess. When the system is not sure, it does not guess. It escalates.

This last step makes the difference. Only a question that really needs a developer reaches a developer. It reaches the correct developer, with the context, and not a shared inbox where it waits for half a day. This changes the work of your developers. They no longer answer questions. They answer one question, one time, the first time, the difficult one. The routine questions do not reach them again.

How Sarrai does this

Sarrai answers from your own documentation and shows the source. It also records how sure it is of each answer. When Sarrai cannot answer a question, it asks your colleague one thing at the moment they send their reply: must this become a draft article? They click one time, and the next customer with the same question gets help. No one types the answer again.

All suggestions come together in one approval inbox. You see where each suggestion comes from, which conversation started it, and what it will change. The search work is done, and the decision stays with you. And when Sarrai cannot answer a question, it sends the question to the person who knows, not to a general mailbox.

To see what this looks like for a software company, read Sarrai for software companies.

Do this first

You do not need Sarrai to start to measure. This week, ask your developers which customer questions reach them. For each question, add one note: did this really need a developer, or did someone else know the answer too? Every question in the second group is work that you can remove today. Usually, this is most of the questions.

To automate a technical customer question, you do not start with a tool. You start when you accept one fact: "just five minutes" of your developer's time is the most expensive answer in your company.