Organising customer support in a small business

In a company of ten or twenty people, customer support is rarely anybody's job: it is what gets added to everybody's job. Nobody designed it — it accumulated. An address that started by accident, two colleagues who reply when they can, and one important request that turns out to be closed because each of them assumed the other had picked it up.

None of the five decisions below requires buying anything. You can make them with the tools you already have, and that is the point: make them first and ticketing software speeds up an organisation that exists; skip them and it files the mess neatly and leaves it there.

1. One way in, and only one

The first cost of disorganised support is not response time. It is the time spent finding where the request landed. If customers write to the salesperson they know, the engineer in their address book and a generic mailbox — sometimes all three — every request exists in three copies, and two of them answer themselves by staying unanswered.

Choose a single entry point and publish it where customers look for it: email signatures, the website, the contract. Then do the uncomfortable part, which is the only part that matters. When a request arrives on a personal channel, reply with one line asking them to use the right address, and handle that one anyway. A single entry point that is declared and not enforced lasts about three weeks.

2. One owner per request

A shared mailbox where anyone may reply is a mailbox where nobody has to. That is not laziness: without a name attached, responsibility belongs to everyone, and responsibility that belongs to everyone cannot be checked or handed over.

The useful rule is that every request has an owner by the end of the day — provisional is fine, and it does not have to be the person who will solve it. The owner is the one who speaks to the customer, and if the work moves to a colleague, the handover is said out loud. Otherwise it only happened in one person's head. Unowned requests are the queue to look at every morning: those are the ones that age.

3. Priorities agreed before the busy week

When things are calm, priorities are unnecessary. They become necessary on the day twelve requests arrive at once — which is the worst possible day to start debating them. Agree them in advance, in words that describe the customer's situation rather than your own irritation.

• Blocking: the customer cannot do something they need to do today, and there is no way around it.
• Degrading: it can be done, but slowly, manually or badly.
• Not urgent: it needs fixing, but not today.

Three levels are usually enough. Five levels produce four extra arguments and the same decisions. And one rule that always holds: your team sets the priority by reading the request — the customer does not pick it from a menu. If they pick it, everything is urgent within six months.

4. The answers you keep repeating

Every small business has five or six replies that get rewritten from scratch every week: how to reset an account, what details are needed to open a request, what happens after a fault is reported. Rewriting one costs little once and a great deal fifty times — and each rewrite differs slightly from the last, which is how two customers end up with two versions of the same rule.

Write them once in a shared document, and treat them as text to copy and adapt, not to paste. A canned reply sent untouched is recognisable immediately, and the person who receives one stops reading the next.

5. Three measurements are enough

You do not need a dashboard. You need three numbers, looked at once a month, that can be counted by hand in a spreadsheet:

• How many requests arrived. Without it, every discussion about workload is an impression.
• How long until the customer got a first reply. Not the solution: the first reply written by a person. It is the figure customers actually experience.
• How many stayed open longer than a week. That is the list of what you are losing, and it is usually short and embarrassing.

If the three numbers are steady, support works even when it feels chaotic. If the third one grows month after month, no tool will fix it: somebody's time is missing, and that is a staffing decision.

When organising is not the problem

These five decisions are not for everyone. If you receive three requests a month from customers you know by name, a process adds friction and removes nothing: the mailbox is enough, and it will stay enough. If requests are numerous but nearly identical, the problem is not how support is organised — the product or the instructions are generating that demand, and it has to be fixed upstream.

Then there is the case nobody likes to admit. If requests stay open because the people who should answer are doing something else, organising makes the delay visible without reducing it. That is still useful — many companies have never seen that number — but it remains a question of people, not of method.

How this maps to OglutTicket

The first two decisions are what a ticketing system does natively: a public form and a project email address become the single entry point, and every request carries an owner and a status visible in the list. The third is a property of the ticket. The fifth needs no report to configure — requests open for several days are a filter.

The fourth stays your work, and it is worth saying plainly: OglutTicket has no library of saved replies, so those five texts will keep living in a shared document. If that matters to you, check it before buying rather than after.

To see the full path of a request, how it works walks through it screen by screen. For declared times there is the guide on SLAs and priorities, and if your starting point is a shared mailbox, the move to a ticketing system is described week by week.