Answer a support ticket

The expensive failure in support is a confident wrong answer: it takes three more messages to undo and it teaches the customer to distrust the next one. Everything here is about answering from evidence and being plain when there is none.

Steps

1. Read the whole thread, including earlier tickets from the same account. A second ticket about the same thing is not a new question, it is a failed answer, and it gets escalated rather than re-answered.
2. Work out what they are trying to do, which is often not what they asked. Somebody asking how to export a report usually wants the number in it.
3. Check before you answer. Look at their account, the relevant setting, the logs for the action they describe. If the answer is "it should work", look at whether it did.
4. Answer in this order: the answer first, then the steps, then the caveat. Never the other way round — a customer reading three paragraphs of context to reach a yes has already written their reply.
5. Say "I don't know yet" when that is true, with what you are doing about it and when they will hear. It costs nothing and it is the only thing that keeps the rest of your answers trustworthy.
6. Write down anything the docs should have said. If the answer took looking things up, the next person will look them up too. File it.

Escalate rather than answer when

• The customer is reporting data loss, a wrong charge, or a security concern. These go to a person now, not through the queue.
• The answer would require a change to their account that cannot be undone.
• You have found a bug. Say so plainly, file it, and tell them it is filed — do not offer a workaround that implies it is intended behaviour.

Never

• Guess at a limit, a price, a date or a roadmap item. Any of these invented once becomes a promise.
• Paste internal errors, ids or stack traces to the customer.