Introduction — The Twenty Tickets a Day That Were Sixty on Mondays

An hourly rate built from a quiet trial week met thirty-five weekdays and sixty Mondays.

Noor quoted an hourly rate for "email support, about twenty tickets a day".

The number came from a trial week. It had been a quiet week — Noor found out later that it had been chosen for that reason, though nobody had decided to mislead anybody. Twenty tickets a day at the pace of that week was about two and a half hours. That felt like a manageable evening commitment.

Then the real months started.

Twenty a day was an average across seven days. Weekdays were closer to thirty-five. Mondays were sixty, because two days of weekend enquiries arrived at once. And the average was calculated over a period that did not include a product launch, a shipping delay or a payment-processor outage, all three of which happened in the first quarter and none of which Noor was told about in advance.

Then there was the knowledge base. It was a document, shared with view access, last edited fourteen months earlier. It covered about six of the twelve questions customers actually asked. For the rest, Noor had to ask the client — and the client answered within an hour sometimes and within four days other times. Meanwhile the tickets sat open, the client's average response time got worse, and the client raised it with Noor as a performance problem.

Roughly two-fifths of tickets could not be answered without asking somebody. That number, more than any other, was the business.

That would be a story about an inexperienced provider if it had ended there. It did not.

Month three. Noor answered eleven refund enquiries by quoting the refund window in the knowledge base. The window had been changed nine months earlier and nobody had updated the document. The client honoured all eleven, because Noor had said it in their name to their customers, and lost money doing it. The conversation afterwards was not about the document.

Month six. A product launch tripled the queue with no warning. Noor worked through a Saturday and still missed the response time on about a third of the tickets. The client's view was that the service level had been agreed. Noor's view was that the volume had not. Both were correct.

Month nine. A customer posted a screenshot of one of Noor's replies. The reply was accurate — it correctly explained why a request could not be accommodated — and it was tone-deaf, in the way that a technically correct sentence written at the end of a long evening can be. It went out under the client's name. The founder saw it.

Month twelve. The client asked Noor to take live chat as well, at the same hourly rate, because "it's the same work really".

None of those four were failures of effort or of politeness. Noor was conscientious throughout. What failed was procedure — and every one of them traces to something structural about the work rather than to something personal about Noor.

This book is built on the four properties of the work that produced them.

You are speaking as somebody else, to their customer. Every reply is published under the client's name and becomes their reputation, and the person reading it believes they are talking to the company.

You can only answer what you have been told. The knowledge base is always incomplete and often stale, and the gap between what customers ask and what you have is where this job actually lives.

The queue is not yours and it does not warn you. Launches, outages, delays and campaigns triple the volume without notice, and the service level does not move when they do.

You are paid per hour or per ticket, and both reward the wrong thing. An hourly rate rewards slowness; a per-ticket rate rewards closing rather than resolving. There is no third price that fixes this except pricing coverage.

The book runs on three numbers.

Revenue per support hour — net revenue divided by every hour from onboarding to reporting, including the knowledge-base work, the time waiting on escalations, the chasing and the records.

Tickets resolved per support hour — resolved rather than closed, which is a distinction the client may not make and you must.

Knowledge-base coverage — the share of tickets you can answer without asking anybody. It costs nothing to record, it explains more variance than any other figure in this trade, and almost nobody measures it.

By month twenty-six, Noor was at roughly 9.4 tickets resolved per support hour, up from about 3.2. Coverage had gone from around 55% to around 92%. Revenue per support hour had roughly tripled, and the hourly rate had not moved in the first year. Almost all of the change came from writing entries rather than from typing faster.

The revenue mix by then: retained email and ticket support 38%, knowledge-base build and maintenance 20%, overflow and peak cover 16%, live chat 14%, help-desk setup and workflow builds 12%.

Read Chapters 5 to 8 first, in order. They are the four rules, and every later chapter refers back to them.

Then read Chapter 20 before your next onboarding, because the knowledge base decides more about a contract's profitability than any other single thing.

If you want the single highest-return action available today: run a coverage check before you quote — take fifty of the client's recent tickets and count how many you could answer from what they have given you. That one number is the whole difference between two and a half hours an evening and a Saturday.

Chapter 1 — Why Customer-Support Outsourcing Works as a Side Hustle

You are speaking as somebody else, to their customer, and they must never know.

1.1 What this work actually is

Not what the title suggests.

⚠ The job is answering a stranger's question, in somebody else's voice, using information you were given by a third party who has not kept it current. Chapter 6.1.

What that involves in practice:

⚠ Checking what you have been given before agreeing to anything. Chapter 20.2.

⚠ Triaging a queue whose size you did not choose. Chapter 22.2.

⚠ Answering from the knowledge base rather than from inference. Chapter 19.5.

⚠ Escalating what you cannot answer, and holding the customer while you wait. Chapter 24.4.

⚠ Writing an entry for every gap you found. Chapter 20.7.

⚠ And a check before the shift closes. Chapter 19.8.

⚠ The proportion of the job that is typing a reply is smaller than anybody expects, and it is not where the money is lost. Chapter 8.1.

1.2 Why the demand does not stop

Structural, rather than a trend.

⚠ Every business that sells anything receives questions, and the volume grows with the business rather than with anything you do. Chapter 7.2.

⚠ The questions arrive continuously and do not accumulate into a project that finishes.

⚠ Nobody who founded a business did it in order to answer emails, and almost all of them are doing it themselves at eleven at night. Chapter 1.3.

⚠ And the alternative — hiring somebody — carries a commitment most small businesses cannot make for a few hours a day. Chapter 2.8.

⚠ What that produces commercially: a client who needs the same coverage every week, indefinitely, and who feels the absence immediately if it stops. Chapter 28.1.

⚠ Which is the best structural position a side hustle can occupy, and the one that will quietly consume every evening you have if you do not price and bound it deliberately. Chapter 8.6.

1.3 What a client is unable to do themselves

Four things, and only one is about workload.

⚠ Answer at a predictable time. A founder answers when they can, which is why their response time is erratic. Chapter 23.2.

⚠ Answer consistently. Two people answering the same question differently is the commonest complaint a small business generates about itself. Chapter 21.7.

⚠ Write down what they know. The knowledge is in somebody's head and stays there until an outsider needs it. Chapter 20.4.

⚠ And stop. A queue with nobody accountable for it grows until it is a crisis. Chapter 22.9.

⚠ The one that is actually about workload is the least important, and it is the one they think they are hiring you for. Chapter 2.2.

Resource 1.

1.4 The four rules, stated once

Everything in this book refers back to these.

⚠ One — you are speaking as somebody else, to their customer. Chapter 5.1.

⚠ Two — you can only answer what you have been told. Chapter 6.1.

⚠ Three — the queue is not yours and it does not warn you. Chapter 7.1.

⚠ Four — you are paid per hour or per ticket, and both reward the wrong thing. Chapter 8.1.

What they have in common:

⚠ None is about how well you write, and all four are about a gap between what the client can see and what the work actually is. Chapter 2.4.

⚠ And three of the four produce failures that land on the client's reputation rather than on yours. Chapter 5.8.

Resource 3.

1.5 Why the answered ticket is not the product

The product is a queue somebody else is accountable for, answered consistently, at a predictable time.

What that means:

⚠ Replies arriving inside the agreed window, reliably. Chapter 23.2.

⚠ The same question answered the same way every time. Chapter 21.7.

⚠ Nothing said that the client then has to walk back. Chapter 6.6.

⚠ Nothing sent that they would be uncomfortable seeing screenshotted. Chapter 5.8.

⚠ And a queue that is empty at the end of a shift rather than deferred. Chapter 19.8.

⚠ What this means for how you are judged: a client who receives beautifully written replies two days late will replace you, and one whose replies are merely competent and always on time will not. Chapter 2.5.

1.6 The hours that are invisible in a quote

Where an hourly or per-ticket price quietly goes.

⚠ Onboarding, and reading everything they have. Chapter 19.2.

⚠ Asking the client the questions the knowledge base does not answer. Chapter 20.8.

⚠ Waiting for those answers, with the ticket open. Chapter 23.4.

⚠ Writing entries so the same gap does not recur. Chapter 20.7.

⚠ Tagging, so the reporting means anything. Chapter 22.3.

⚠ Handover notes between shifts. Chapter 16.6.

⚠ Reporting, which the client will ask for. Chapter 16.5.

⚠ And the end-of-shift check. Chapter 19.8.

⚠ Across a contract these routinely exceed the replying itself, and none of them is what the client thinks they are paying for. Chapter 31.2.

1.7 What experience actually changes

Not typing speed.

⚠ Running a coverage check before quoting. Chapter 20.2.

⚠ Requiring a named escalation contact and a response window. Chapter 24.3.

⚠ Requiring the client to tell you about launches and outages. Chapter 7.7.

⚠ Writing an entry every time a gap appears, so coverage rises. Chapter 20.7.

⚠ Having a macro library so the twentieth identical question costs seconds. Chapter 16.2.

⚠ And getting the voice agreed before volume rather than after a complaint. Chapter 21.10.

⚠ A third-year provider is not much faster at writing than a first-year one. They are enormously faster because they are answering more from what they already have, which is coverage. Chapter 27.3.

1.8 Who this is genuinely suitable for

Be honest about the fit.

It suits somebody who:

⚠ Can write clearly in a voice that is not their own. Chapter 21.1.

⚠ Is comfortable saying "I need to check that" rather than guessing. Chapter 6.7.

⚠ Can hold a predictable coverage window most weeks. Chapter 33.2.

⚠ And will write the entry rather than answering the same question forty times. Chapter 20.7.

It does not suit somebody who:

⚠ Needs the work to be visible, because it is invisible by design. Chapter 18.1.

⚠ Finds it hard to be agreeable to somebody who is angry with a company that is not yours. Chapter 5.5.

⚠ Or is uncomfortable holding a boundary about what they are authorised to say. Chapter 15.5.

1.9 What the first year actually looks like

Realistically, and without encouragement.

⚠ Months one to three: every week takes longer than quoted, mostly because of the gap between what you were given and what customers ask. Chapter 6.4.

⚠ Months three to six: the first incident — a wrong policy quoted in good faith, or a reply that was accurate and badly received. Chapter 5.6.

⚠ Months six to nine: the knowledge base you have been writing starts paying, and the hours per ticket fall sharply. Chapter 20.7.

⚠ Months nine to twelve: the first properly priced contract, and the first client that brings support in-house. Chapter 32.5.

⚠ What rises across that year is coverage, and almost none of the improvement comes from working faster. Chapter 27.3.

⚠ What does not happen in year one: a rate rise. The hourly rate set on a quiet trial week is usually still in force in month fourteen, which is Rule 4 operating exactly as described. Chapter 8.4.

1.10 Chapter summary

The job is answering a stranger's question in somebody else's voice using information a third party has not kept current — and the typing is the smallest part. Demand does not stop because every business that sells anything receives questions, and nobody founded a business to answer emails. A client cannot answer at a predictable time, cannot answer consistently, cannot write down what they know, and cannot stop. The product is a queue somebody else is accountable for. The invisible hours — onboarding, asking, waiting, writing entries, tagging, reporting — routinely exceed the replying. And what a third year changes is coverage.

AI prompts for this chapter

Prompt 1 — Assess Whether This Fits Your Week

"Assess honestly whether customer-support outsourcing fits my situation. ⚠ It needs the ability to write clearly in a voice that is not my own, comfort saying 'I need to check that' rather than guessing, a coverage window I can hold most weeks, and the discipline to write an entry rather than answering the same question forty times — and it does not suit somebody who needs the work to be visible, because it is invisible by design, or who finds it hard to be agreeable to somebody angry with a company that is not mine. ⚠ I will describe my week and temperament. ⚠ Give me the honest assessment including the reasons against."

Prompt 2 — List the Invisible Hours

"List every hour an hourly or per-ticket price has to cover. ⚠ Onboarding and reading everything they have; asking the client what the knowledge base does not answer; waiting for those answers with the ticket open; writing entries so the same gap does not recur; tagging so the reporting means anything; handover notes; reporting; and the end-of-shift check — and across a contract these routinely exceed the replying itself. ⚠ I will describe a typical week. ⚠ Produce the full list with my estimate against each, and tell me which is largest."

Prompt 3 — Name What the Client Cannot Do

"Help me articulate what a client cannot do themselves. ⚠ They cannot answer at a predictable time, because a founder answers when they can; cannot answer consistently, because two people answering the same question differently is the commonest complaint a small business generates about itself; cannot write down what they know, because it is in somebody's head until an outsider needs it; and cannot stop, because a queue with nobody accountable grows until it is a crisis — and the workload, which is what they think they are hiring me for, is the least important. ⚠ I will describe my target clients. ⚠ Write how I would explain this without being insulting."

Prompt 4 — Map a Realistic First Year

"Map what my first year is likely to look like. ⚠ Months one to three: every week takes longer than quoted, because of the gap between what I was given and what customers ask. Months three to six: the first incident — a wrong policy quoted in good faith, or a reply that was accurate and badly received. Months six to nine: the knowledge base I have been writing starts paying and hours per ticket fall sharply. Months nine to twelve: the first properly priced contract and the first client that brings support in-house. And no rate rise in year one. ⚠ I will describe my starting point. ⚠ Produce the map."

⚠ AI checkpoint for this chapter

One — did it describe this as typing work? Coverage is the job.

Two — did it promise income or client retention? No book can.

Three — did it skip the waiting and the entry-writing? Those exceed the replying.

Four — did it assume the rate rises in year one? It usually does not.

Do This Now

1. Write down every hour last week actually took, by category.

2. Answer the ten fit questions honestly.

3. Count how many of last week's tickets you could not answer alone.

4. Read Chapters 5 to 8 before you quote on anything.

5. Start a log today, even with one line in it. Resource 1 and Resource 3.

Look inside AI-Powered Customer-Support Outsourcing