Customer support that doesn't eat the week

When support starts eating the week, the first move is not a new tool or a hire. It is one week of honest notes. Write every question down in one line, mark whether you have heard it before, and note when it arrived.

Oscar's week at 120 shops: about 15 hours of calls and Viber messages, sometimes at ten at night. About 60% of the questions were repeats: how to enter mileage, how to change a reminder's text, where to find the invoice, a forgotten password. Most arrived between eight and ten in the morning, when cars are handed in.

If time is spread evenly across questions, the repeats cost:

15 hours × 0.6 = 9 hours a week

That is more than a working day spent saying things he has already said. The repeats are the cheapest hours to win back, because each answer can be written once and reused.

The arrival times matter too: they tell you when someone has to be on duty and when a slower reply is perfectly fine.

Every repeated question has three possible answers, from best to worst.

1. Change the product so nobody needs to ask. If people keep asking how to change a reminder's text because the setting is hidden three screens deep, the fix is an “Edit text” button on the reminder itself, as Nina did. The question disappears for every future shop.
2. Write it down once. A help center is a small knowledge base: short articles with screenshots, one question each. Routine how-tos, such as entering mileage at hand-over, become a link instead of a five-minute voice message. Saved replies (canned responses) in Viber or email do the same for the shortest answers: two lines and a link to the billing page.
3. Type it by hand again. Fine for something truly new, expensive for the hundredth time.

One kind of message never goes down this ladder: anything that means the product has stopped doing its job, such as reminders not going out. That needs a person right away, not an article.

A help center doesn't need a writing week. Build it one article at a time with a simple habit: the second time a question arrives, write the article before you reply, then send the link. The first time you can't know whether it will repeat; by the third time you have already typed the answer twice for nothing.

The second time is also when the answer is fresh: you know what confused the customer and which screen they were on.

A useful article is small:

• a title in the customer's words: “How to enter mileage when a car is handed over”, not “Odometer data management”;
• three to six steps, each with a screenshot;
• one question per article, so a link answers exactly what was asked;
• a last line for emergencies, like Nina's “Reminders not going out? Call this number.”

Then keep a saved reply that points to it. Most people want the problem solved, not a conversation: an administrator with a car waiting at reception prefers two screenshots now to a callback in an hour.

Not every message deserves the same speed. Sort requests by what happens if nobody answers for a few hours.

• Routine how-tos: adding a second phone number, finding last month's invoice, importing a spreadsheet of clients. An article or a saved reply within the working day is enough; nothing breaks while the customer waits.
• The product isn't doing its job: none of today's reminders were delivered, reminders went out twice or to the wrong people. This may affect many shops at once and costs each of them returned cars. A person looks at it immediately, by phone.
• Money and account decisions: refunds, discounts, cancelling. They need someone who can decide, usually the same day.

The test question is simple: is the product still working for this customer? If not, it jumps the queue, whatever the time of day.

Write the categories down and tell customers which is which, for example with one line at the end of every help article saying where to call when reminders stop. Then urgent problems reach a person fast, and routine ones stop pretending to be urgent.

Answering at ten at night feels like good service, but it teaches customers that ten at night is support time, and it wears out the founders. Customers mostly need to know what to expect, not to get an instant reply to everything.

So write a short, public promise and keep it:

• routine questions are answered within the working day;
• messages that arrive at night wait until morning;
• the one exception: if reminders aren't going out, call this number at any hour.

Put it where customers look: the help center, the Viber auto-reply, the welcome message. Then a night message about an invoice isn't a broken promise when it's answered at 8:30, and Oscar can put the phone down.

A clear promise kept every time builds more trust than random late-night replies, because people can plan around it. And the exception protects what really matters: a product failure at night still reaches a person before the morning's reminders are due.

Articles and saved replies cut the repeats, but questions still grow with every new shop. Support becomes a job when it is predictable and takes hours from work only the founders can do. Part time is fine.

Check the money with a quick break-even on new revenue:

shops needed = monthly pay / price per shop, rounded up

Martha, an administrator at a customer's shop who has used GarageDesk every day since launch, joins as GarageDesk's first part-time support person: 20 hours a week for 16,000 UAH a month. New shops pay 750 UAH:

16,000 / 750 = 21.33 → 22 shops (21 × 750 = 15,750 is short; 22 × 750 = 16,500 covers it).

Always round up: a fraction of a shop pays nothing. This is a rough check on revenue. Each shop also brings its own costs, such as SMS, so the true number is a little higher.

The other side of the decision is what the freed hours buy. Oscar's fifteen hours go back to sales in Khmelnytskyi, where about 150 shops fit, so the hire can pay for itself within a few months of his normal pace. Hiring someone who already speaks the customers' language, like Martha, shortens the learning curve; asking her employer first keeps the trust.

A new support person who has to ask the founder about everything only moves the founder's hours to the phone. To make support truly independent, give four things on the first day.

1. The answers: every help center article and saved reply.
2. A written escalation rule, short enough to pin above the screen. At GarageDesk: how-tos Martha handles herself; anything that stops reminders goes to Nina at once; money and account decisions (prices, discounts, refunds, cancelling) go to Oscar.
3. The right access: seeing each shop's account and payment status, so she can check instead of asking.
4. A feedback loop: every Friday the three most common questions of the week go to Nina.

What not to give: “just ask me about anything”. It feels kind, but it keeps the founder as the bottleneck and teaches the new person not to decide.

The rule protects both sides: Martha knows exactly what she may decide alone, and the founders know a real failure will reach them fast, even at night.

The weekly list of the most common questions is not a report for its own sake. It is the cheapest product research a small team has: real customers, telling you every day where the product confuses them.

The loop has three parts: support finds the questions, the product removes them, the help center answers the rest.

Read the Friday list with one question in mind: why do people need to ask this at all?

• A question that keeps coming back despite a good article points at the product. If “how do I enter mileage” tops the list for the third week running, the mileage field is probably hard to find or unclear at hand-over. A clearer screen fixes it for every future shop.
• A question that disappears after an article was a knowledge gap. Keep the article.
• A question about money or plans may point at unclear pricing or billing pages.

The wrong reactions are writing a longer article for a screen nobody understands, or adding support hours to keep up. Both treat the symptom and let the questions grow with every new shop.