Every support message is a decision you already made

Published September 7, 2026 · 7 min read

A message arrives asking where to find something. You answer it in ninety seconds and feel efficient. The same question arrives again the following week from someone else, and again a fortnight later, and each time you answer it in ninety seconds and feel efficient. Nothing about the product has changed, and nothing will, because answering is quick and fixing is not, and the only person keeping count is nobody.

Cheap to answer, expensive to keep answering

A support question has two costs. The obvious one is the time it takes to reply, which for a small operation is small enough to be invisible. The hidden one is that every recurring question is a permanent tax on every future customer, most of whom will not write in at all. They will read the same unclear screen, reach the same wrong conclusion, and quietly leave.

This is why support volume is a misleading measure of anything. The people who write to you are the persistent minority. They are self-selected for patience, for having already decided the thing is worth the trouble. Behind each one is a larger group who met the same obstacle and were not sufficiently invested to send a message about it.

The question is a description of a decision

Almost every repeated question is a design decision that has come back with a verdict attached. Someone decided the label was self-explanatory. Someone decided that step did not need a confirmation. Someone decided the pricing page did not need to state what happens after the trial, because it seemed obvious from the context.

None of those decisions were made carelessly. They were made by a person who already knew the answer, which is the single condition under which it is impossible to judge whether something is clear. The support message is the only mechanism by which that knowledge gets corrected, and answering it privately deletes the correction.

Record before you answer

The whole discipline reduces to one change of order. Before writing the reply, write the question down somewhere durable, in the words the person actually used. Not a summary in your words, which will smuggle in the understanding they lacked. Then answer.

• Keep it in a single plain file, one line per distinct question, with a tally for repeats. The point is accumulation, not sophistication.
• Preserve the phrasing. The vocabulary mismatch between what you called a thing and what they called it is often the entire finding.
• Note where they were when they got stuck, not just what they asked. The location is usually more actionable than the question.
• Separate questions about basics from questions about edge cases. The first is a design problem; the second is often just a legitimately complicated situation and always will be.
• Review the file on a fixed schedule rather than when it feels urgent, because it will never feel urgent.

What the tally is for

The tally converts a series of individually trivial interruptions into a ranked list, and a ranked list is something you can act on. The top item is almost never a surprise once you see it written down; it is usually something you have been vaguely aware of for months and never had a reason to prioritise over whatever was newer and more interesting.

That is the real function here. Small operators do not fail to fix these things because they lack the skill. They fail because a new feature is more appealing to build than a clearer sentence on an existing page, and nothing in the normal run of the week ever makes the case for the sentence. The tally makes the case.

The fix is usually smaller than the feature you were going to build

When operators finally act on this, the correction is rarely a rebuild. It is a renamed button, a sentence added where a question kept being asked, a confirmation screen that says what just happened, a reordering of two steps, a default that matches what people actually choose.

There is something deflating about this. The work that most improves the product is often the least satisfying work available, and it never looks like progress in any summary of the month. That is precisely why it needs a written record to survive contact with a normal working week.

The trap of getting good at support

There is a version of this that goes wrong in the opposite direction. An operator becomes genuinely excellent at support — fast, warm, thorough — and the excellence becomes the thing that keeps the product tolerable. Customers stay because the person is good, not because the product is.

That works, and it does not scale, and it cannot be handed to anyone. It also feels great, which is the dangerous part: the daily evidence is a stream of grateful replies. The measure worth watching is not whether people are happy with your answers. It is whether the same question is still being asked a year from now.

One question a month

The whole practice fits into a modest commitment: read the file once a month, take the question at the top of the tally, and make it structurally impossible to ask again. Not easier to answer — impossible to ask. Then start the tally for that question over at zero and see whether you were right.

Twelve of those in a year is a meaningfully different product, arrived at without a single guess about what customers want, because none of it was a guess. Each one was a decision you already made, returned to you with a note attached explaining how it landed.

Common questions