The One-Person Support Team Playbook

Running support alone is a coverage problem disguised as a workload problem. You can be twice as fast and still not be awake at 3am, and no amount of effort fixes a timezone.

Here is what actually works.

Accept the real constraint

One person covers roughly forty hours. Your customers exist across every hour. That gap is arithmetic, not a personal failing, and every solution starts by naming it rather than trying to work through it.

The fragility is also worth naming. Illness, holidays, and volume spikes all produce total outages of the support function. That is a business risk, not just a personal one, and it is worth raising with whoever thinks support is covered.

Publish honest expectations

The single cheapest intervention available.

Telling customers you reply within one working day, and doing so consistently, generates fewer complaints than implying immediacy and delivering a day. Customers plan around what you tell them. They get annoyed by the gap between the implied promise and reality, not by the reality itself.

Put it where they will see it before they contact you: the contact form, the chat widget, the help centre header. Then meet it.

Document your top ten answers

Take the ten questions you answer most often and write them properly. Use the words customers use, not your internal terminology. Put the answer in the first paragraph.

This is one afternoon. It pays back every week for years, and it is the only piece of work on this list that compounds.

Where to find the ten: your sent folder. The replies you have written most often, or the macros you use most if you have a helpdesk. That is the list, already ranked.

Defend a weekly block for content

The queue will consume every available minute unless you actively defend time against it. Two hours a week, in the calendar, treated as unmovable.

Without this you will spend a year intending to write documentation and answering the same questions instead. This is the discipline that separates solo support functions that stabilise from ones that get steadily worse.

Prioritise deliberately, not by recency

With one person, ordering matters more than speed. Decide what jumps the queue and apply it consistently:

• Anything blocking a paying customer from using the product.
• Anything from an account at renewal.
• Anything a trial user is stuck on, because they will not wait.
• Everything else in age order, oldest first.

Working newest-first feels productive and buries the oldest customers, who are the ones most likely to leave.

Read your help centre search logs

Every zero-result search is a customer telling you what is missing and how they phrase it. This report takes five minutes to read monthly and it tells you exactly what to write next.

Almost nobody reads it. It is free, ranked, and derived from real demand rather than intuition.

Cover the hours you cannot work

This is where the coverage problem gets solved rather than managed.

If your documented questions can be answered automatically, at any hour, then most of what arrives overnight is handled before you wake up. What remains in the morning is the work that genuinely needs you, which is a very different start to the day than a full inbox.

It also covers holidays, illness, and the evening a launch generates unexpected volume. That is not a productivity improvement, it is the removal of a structural fragility.

Fidiora does this at $0.59 per genuine resolution with no seat fee and a spend cap you set, grounded in whatever documentation you have. We would rather be direct about the bias: whether it helps depends entirely on whether your questions repeat. If every contact is genuinely bespoke, this will not do much and you need a second person.

Handling holidays

Publish the reduced expectation in advance, on the contact form and in your auto-reply. Make sure documented questions are still being answered. Set one clear escalation path for genuine emergencies, and give it to the person covering.

Customers are considerably more understanding of a stated absence than of unexplained silence. Say it plainly and most people will simply wait.

Knowing when to hire

Hire when the volume that genuinely needs judgement, after documentation and automation have done their work, consistently exceeds what you can handle.

Hiring before that point means paying someone to answer questions that never needed a person, and it makes the role less appealing to the person you hire. The best time to add a second person is when the first person’s day is mostly interesting work, because that is a role someone will stay in.