In a small business, support is rarely anyone's whole job. The person who answers a billing question is also sending invoices, and the person fixing a login problem has a project due on Friday. Requests arrive by email, by phone, through a chat message to whoever seems to know, and sometimes in a corridor.
That works while the volume is low. Then a customer chases a question nobody wrote down, two people answer the same email in different ways, or a request sits in someone's inbox while they are on holiday.
You do not need a support department to fix this. You need one place where requests land, a clear owner for each one and a few simple habits. This guide covers how to set that up and keep it running with the team you already have.
Bring every request into one queue
The single biggest improvement is to stop support living in personal inboxes. When a request goes to one person, only that person knows it exists. When it goes into a shared queue, anyone can see it, pick it up or cover it.
Start by listing every way people currently ask you for help. For most small businesses that is a mix of a general email address, a contact form, direct messages to staff and phone calls. Then decide which of those should create a ticket and point people towards them:
- A form or portal for customers. A short form that asks for the right details up front saves a round of questions later.
- A route for your own applicants or partners. If you recruit, candidates have questions too, and they deserve the same care as customers.
- A habit for everything else. When a request arrives by phone or in passing, whoever takes it logs it as a ticket. It takes a minute and means nothing relies on memory.
Keep statuses and priorities simple
A small team does not need a dozen workflow stages. Four statuses cover almost every request: open, in progress, resolved and closed. Anyone glancing at the queue can tell what is waiting, what is being worked on and what is done.
Priorities work the same way. Low, medium, high and urgent is enough, as long as everyone agrees what they mean. Write a one line definition for each, for example:
- Urgent. Something is broken for a customer right now and they cannot work.
- High. A real problem with a workaround, or a deadline in the next day or two.
- Medium. A normal question or request. Most tickets belong here.
- Low. Ideas, feature requests and anything that can wait.
If everything is urgent, nothing is. Agreed definitions stop priority becoming a measure of how loudly someone asked.
Use categories to see where the work comes from
Categories tell you what people need help with. Keep the list short, five or six at most, such as general questions, technical problems, billing, access and other. Too many and people pick at random. Too few and you learn nothing.
Review the categories every few months. If one keeps growing, it is telling you something: a confusing invoice layout, a sign in step that trips people up, or a product area that needs better instructions.
Give every ticket one owner
Shared queues have one weakness. When everyone can see a ticket, everyone can assume someone else has it. The fix is simple: every ticket in progress has exactly one named owner.
- Check the unassigned pile daily. Decide who looks at new tickets each morning, or take turns by day or by week.
- Claim before you start. Assign the ticket to yourself before replying, so two people never answer at once.
- Hand over in writing. When you pass a ticket on, leave a note explaining what has been tried and what the requester has been told.
- Cover holidays. Before time off, reassign anything still open. Our guide to running time off and leave covers planning cover in more detail.
Separate replies from internal notes
Every ticket has two conversations. One is with the person who asked for help. The other is between your team: what you have checked, who you have asked and what you suspect is wrong.
Keep them apart. Internal notes give the next person full context without ever reaching the customer, and they stop that discussion drifting into a separate chat thread where it is lost. If your team already relies on chat, our guide to team chat for small teams explains where chat helps and where a ticket is the better home.
Set response targets you can keep
People mostly want to know they have been heard and when to expect an answer. A promise you keep is worth more than an ambitious one you miss.
Write down simple targets, such as a first reply within one working day and urgent tickets looked at within two hours during office hours. Share them with customers on your contact page. Then check the queue against them each week, and adjust the targets or the rota if you keep missing them.
Targets work best when the queue shows them. A ticket that says it is due in an hour gets picked up. A promise written in a policy document nobody opens does not.
A good first reply does three things: it confirms what you understood, says what happens next and gives a rough timescale. Even when you do not have the answer yet, that reply stops the follow up emails.
Answer common questions once
Look at your last fifty tickets and you will find the same handful of questions again and again. How do I reset my password, where is my invoice, how do I change my details. Each one costs a reply every time it comes in.
Write each of these up once as a short help article, with clear steps. Then use them in two ways. Link to the article in your reply instead of writing the answer from scratch, and publish the articles where people can find them before they raise a ticket. Every question answered by an article is one your team does not have to answer.
Keep articles short and update them whenever a ticket shows one is out of date or unclear.
Review the queue every week
Fifteen minutes a week is enough. Look at how many tickets came in, how many are still open and which categories are growing. Ask three questions:
- Is anything old still open, and why?
- Which questions came up more than twice, and should they become help articles?
- Is the load fair across the team, or is one person carrying it?
Small, regular fixes add up. Most support load comes from a few repeated causes, and a weekly look is how you find them.
Decide who can see what
Tickets often contain personal details, invoices and account information. Not everyone needs access to every ticket, and not everyone who can read them needs to delete them. Decide who can view, reply to and remove tickets, and set this by role rather than person by person. Our guide to roles and permissions for small businesses walks through how to decide.
How Wizard Application helps
The Help Desk in Wizard Application is included on every plan, including the free Starter plan, and is built around the habits above.
- One queue, several ways in. Your own team raises tickets inside the app and follows the replies under My Support Tickets. Customers, client companies and candidates raise tickets from their own portals. Tickets can also come from forms, a support ticket block on your website and a hand-off from the website chatbot, and staff can log a ticket on someone's behalf.
- Clear statuses and priorities. Every ticket gets its own number. Open, in progress, resolved and closed, with low, medium, high and urgent priorities. Work through tickets as a list sorted by priority or move them across a board by status.
- Response targets on every ticket. Set a first reply and a resolution target for each priority. Each ticket shows when it is due, due soon or overdue, and you can filter the queue to overdue tickets only.
- Categories you control. Start with general, technical, billing, access, bug report, feature request and other, then rename them or add your own.
- One owner per ticket. Assign a ticket to anyone on your team and they are notified straight away. Filter by my tickets, unassigned, status, category or who raised it, and save the views you use every day.
- Replies and internal notes. Public replies are emailed to the requester, and internal notes are visible to your team only. Every reply, assignment and status change is recorded in the ticket history.
- A knowledge base that deflects questions. Articles written in Content are suggested while someone writes a ticket and shown as related reading on the ticket itself.
- AI that saves time. With AI switched on, each ticket gets a short summary with a suggested category and priority for your team to accept or ignore. Draft reply writes a response from your knowledge base articles and shows its sources, so you check and edit before sending.
- Reports. See tickets over time and by status, filtered by assignee or customer.
Frequently asked questions
Do small businesses need help desk software?
Once more than one person answers support requests, a shared queue usually pays for itself. It stops requests getting lost in personal inboxes and lets anyone cover when someone is away.
How many people does it take to run a help desk?
One is enough to start. What matters is a clear owner for each ticket and someone checking new requests every day. As volume grows, share the daily check on a rota.
What is a good response time for a small business?
A first reply within one working day is a sensible starting point, with urgent problems looked at within a few hours. Choose targets you can meet every week and tell customers what they are.
What is the difference between a reply and an internal note?
A reply goes to the person who raised the ticket. An internal note is visible to your team only and is used to share context, hand a ticket over or record what has been tried.
How do I reduce the number of support tickets?
Find the questions that come up most often and answer each one in a short help article. Make the articles easy to find before someone raises a ticket, and link to them in replies.
A help desk is one part of looking after customers well. If you are still tracking leads and customers in spreadsheets, our guide to sales pipeline stages covers the other end of the relationship, and our article on the signs your business has outgrown spreadsheets helps you decide what to move first.
