How to build a support workflow that actually scales
A good support workflow comes down to three things working together: tags that categorise conversations by type and priority, filters that surface what needs attention first, and assignment rules that spread work fairly across your team. Set these three up properly in a shared inbox, and a lean three-person team can often absorb noticeably more volume than the same three people working across disconnected tools. Not because they're working harder, but because they've stopped losing time to duplicate handling, tool-switching and inbox-scrolling to work out what's urgent and who's covering it.
If you're currently bouncing between a live chat tool, an email inbox and maybe a spreadsheet to track who's doing what, I get it. I've worked with small UK support teams, including a five-person team at an online homeware retailer, who were burning hours every week just working out what needed a reply next. The good news is that fixing this isn't about adding headcount. It's about adding structure, and building the kind of team collaboration that doesn't rely on someone shouting across the room to ask "has anyone replied to this yet?" Let's build that structure together.
Why a shared inbox and better organisation beat more headcount
Here's a trap I see small teams fall into constantly: response times start slipping, so the instinct is "we need to hire." But before you post that job listing, and go through the cost and time of recruiting in today's market, it's worth asking whether the real problem is actually a workflow problem wearing a headcount costume.
When you're juggling separate tools for live chat and email, you create blind spots almost by accident. A customer messages you on chat, then follows up by email an hour later because they're not sure you saw it. Now two people might be working on the same issue without knowing it, or worse, nobody is. That's not a staffing problem. That's a visibility problem.
Everything changes when your conversations live in one shared inbox instead of scattered across three browser tabs. Suddenly you're not asking "did anyone see this?" You're looking at one queue, with context attached, and you can actually tell what's been touched and what hasn't. In my experience working with small support teams, this shift alone, before any filters or assignment rules are even added, tends to cut down on duplicate replies and missed follow-ups significantly. The exact numbers vary by team and ticket volume, but the pattern holds: less time spent hunting for context means more time spent actually helping customers.
The honest truth is that most small teams don't have a people problem. They have an organisation problem. And organisation is fixable in an afternoon, not a hiring cycle. That matters if you're a UK team weighing up the cost of a new hire against National Insurance contributions, pension auto-enrolment, and the usual recruitment overheads, before you've even worked out whether you needed the extra headcount in the first place.
What tags should I use for customer support tickets?
Tags are where most teams either set themselves up for smooth sailing or quietly build a mess they'll regret in three months. The difference comes down to intention. A tag that helps you filter, route or report on something is doing a job. A tag that just describes a vibe ("weird one", "annoying customer") is clutter dressed up as organisation.
So what tags should you actually use for customer support tickets? Here's a structure that works well for most small teams right out of the gate:
Category tags: what is this conversation actually about?
- billing
- bug-report
- feature-request
- onboarding
- refund
Priority tags: how urgently does this need attention?
- urgent
- standard
- low-priority
Channel-source tags: even in a unified inbox, it's still useful to know where something started
- chat-initiated
- email-initiated
Add those up and you get ten tags in total: five category tags, three priority tags and two channel tags. That's not too many for a small team to manage, but there's a shortcut worth knowing first. Many shared inbox tools, Sonny included, already track the channel a conversation started on as metadata, without you needing to apply a tag at all. If yours does the same, your real manual tag count drops to eight (five category plus three priority), and you can skip channel tags entirely.
Either way, eight to ten tags is a sensible range to start with. My rule of thumb: if you wouldn't filter by it, don't tag it. Ask yourself, "would I ever build a view or a report around this tag?" If the answer is no, skip it. Tags aren't meant to be a filing cabinet for every possible descriptor. They're meant to power action.
One more practical point: category and priority tags aren't mutually exclusive. A conversation can, and often should, carry one of each, like billing plus urgent. Think of category as answering "what" and priority as answering "how fast", and apply both.
How do filters help prioritise support requests?
Tags on their own are just labels. The magic happens when filters use those labels to turn a messy, unsorted inbox into a prioritised queue that basically tells your team what to work on next.
Think about it this way: without filters, your team is scanning a long list of conversations trying to eyeball which ones matter most. With filters, you build the queue once, and it works for you every single day after that.
So how do filters help prioritise support requests, practically speaking? You combine tag, ticket status, wait time and customer type into a single view. For example, you might build a filter with these exact conditions: priority = urgent, status = open, assignee = unassigned, waiting time > 60 minutes. That combination catches the conversations that are quietly becoming a problem before a customer has to complain about it. And because status and assignee are part of the filter, you're finding urgent tickets that nobody has actually claimed yet, not just urgent tickets in general.
A few filter combinations worth setting up early:
- Urgent, unanswered over 1 hour: your "don't let this slip" safety net (priority = urgent, status = open, waiting > 60 min)
- VIP customer, any tag: so your highest-value accounts never wait in a generic queue (customer type = VIP, status = open)
- Billing, unassigned: so money-related questions don't sit untouched (tag = billing, assignee = unassigned)
Filters aren't just for triage, either. They're a quiet reporting tool too. If you notice your "bug-report" filter is constantly overflowing on Monday mornings, a common pattern after a weekend of unanswered queries piling up, that's worth digging into. Filters let you spot these trends without building a single spreadsheet. And when a filter does surface a stale ticket, decide in advance what the escalation action actually is: does it get reassigned automatically, does it ping a team lead, or does it just sit at the top of the queue with a visual flag? Pick one and stick to it, or the filter becomes noise instead of signal.
How do I assign conversations fairly across a small team?
Here's something I've seen happen over and over: manual assignment works fine when there are two of you. You just kind of know who's handling what. But the moment a third person joins, that informal system breaks down fast. Suddenly someone's queue has twelve unanswered conversations while another teammate has two, and nobody planned it that way. It just happened.
So how do you assign conversations fairly across a small team without a manager babysitting the inbox all day? Two models tend to work well, often in combination. But "fair" needs a proper definition first, because equal ticket counts and fair workload aren't always the same thing.
- Round-robin assignment: conversations get distributed evenly, one at a time, so nobody's queue silently balloons while someone else coasts. On its own, though, plain round-robin has a blind spot: it doesn't know that someone's on annual leave, that a teammate already has eight open tickets from yesterday, or that the conversation it just assigned is a fifteen-message saga while the last one was a one-line question. Build in safeguards: skip agents marked as offline or on leave, cap how many open conversations someone can be assigned before they're skipped in the rotation, and weight distribution by open ticket count rather than raw conversation count.
- Skill-based assignment: certain tags route to certain people automatically, like sending anything tagged "billing" straight to the teammate who actually knows your billing system inside and out.
The combination matters. Round-robin keeps things fair on volume, once you've added the availability and workload safeguards above. Skill-based routing keeps things fair on complexity. Nobody wants to be the person who gets every single refund request just because they answered one well once. But watch for the obvious risk with skill-based routing: if only one person understands billing, that person becomes a bottleneck the moment they're on holiday or off sick. Cross-train a second person on each specialist area, even if they're not the primary owner, so skill-based routing doesn't quietly create a single point of failure.
It's also worth deciding, upfront, who owns escalation. If a conversation has been reassigned twice and still isn't resolved, who does it go to next? In a small team, this is often whoever set the workflow up in the first place. But naming that person explicitly, rather than assuming it's obvious, avoids the awkward moment where a frustrated customer's third message lands in nobody's queue.
One more piece that's easy to overlook: internal notes. When a conversation gets reassigned or escalated, context needs to travel with it. A quick internal note, something like "customer already tried resetting their password twice, this is likely a backend issue," saves the next person from asking the customer to repeat themselves. That's a small thing that makes a real difference in how professional your support feels from the outside. It's also worth a quick mention that if your team handles any personal customer data in those notes, it's good practice to keep them factual and relevant, rather than including anything you wouldn't want the customer to see if they ever requested their data under UK GDPR.
A sample support workflow for a 3-person team
Let's make this concrete. Here's a workflow you can copy today, almost exactly as-is, if you're running a lean two-to-six-person support team. I'll use three named roles, Triage, Billing Specialist and Generalist, to make ownership clear, but scale the number of generalists up or down depending on your headcount.
Set up 8 core tags covering category and priority. Five category tags plus three priority tags, as covered above. Keep it lean at the start: billing, bug-report, feature-request, urgent, standard is a solid launch set. You can always expand once you see what actually shows up in your conversations.
Build 3 filters for urgent items, ageing tickets and VIP customers. Start with the "urgent, unanswered over 1 hour" filter. It catches the conversations most likely to turn into a frustrated customer if ignored. Decide now what happens when a ticket hits that filter: does it auto-reassign to the Triage role, or does it just flag for attention?
Assign one person as Triage for the first hour of each day, rotating weekly. This person's job is to scan new conversations, apply tags if they weren't auto-applied, and make sure nothing urgent sits unclaimed. Rotating it weekly keeps it from becoming one person's permanent chore, and build in a simple cover plan: if the scheduled Triage person is on leave or off sick, the rota just skips to the next name rather than leaving the slot empty.
Use skill-based assignment for billing tickets, and cross-train a backup. Route billing tickets straight to your Billing Specialist so customers get accurate answers faster instead of bouncing between teammates. But make sure at least one other person on the team can cover billing questions competently when the specialist is away.
Set a simple rule for stale and reopened tickets. Anything unanswered for more than four working hours (adjust to your own service hours) gets automatically flagged to the Triage role for that day. Reopened tickets, where a customer replies after a conversation was marked resolved, should route back to whoever last handled it, not to the back of a general queue, so context isn't lost.
Review tag and filter performance weekly using built-in reporting. Are certain tags never getting used? Is one filter constantly overflowing? Adjust as you go. This workflow should evolve with your team, not stay frozen from day one.
What I like about this setup is how little time it takes to actually build. Tools designed specifically for small support teams, Sonny is the one I know best, let you configure tags, filters and assignment rules yourself, often in well under an hour, without needing to book an onboarding call first. You're not waiting on a demo scheduled for next Tuesday. You just set it up and start working.
Bringing your support workflow together
A support workflow built on tags, filters and assignment rules doesn't add complexity to your team's day. It removes the guesswork that's currently eating up your time. When everything lives in one shared inbox instead of scattered across live chat and email tools, team collaboration stops depending on someone remembering to mention a conversation in Slack or shouting across the office. The system just handles it, and everyone can see the same queue, the same context and the same history.
A quick note on pricing: if you're evaluating tools to run this kind of workflow, it's worth checking whether pricing is per-seat or flat-rate. Per-seat pricing can quietly punish exactly the growth this workflow is designed to support: every new teammate you add to spread the workload becomes a new line item. Flat-rate tools for small teams, including Sonny, are built around unlimited agents on one monthly rate, which is worth factoring into your decision if you expect your team to grow.
Support workflow FAQ
How many tags should a small support team actually use? Start with eight to ten tags: five covering category (billing, bug-report, feature-request, onboarding, refund), three covering priority (urgent, standard, low-priority), and channel-source tags only if your shared inbox doesn't already track that automatically. More than 12 to 15 tags usually creates confusion rather than clarity, so add more only once you see patterns that justify it.
Can filters and tags work across both live chat and email in one inbox? Yes, and this is exactly the point of unifying channels. In a properly configured shared inbox, a tag or filter applies the same way whether the conversation started as a live chat message or came in through email, so your team isn't managing two separate systems or two separate sets of rules.
How do I stop the same issue creating duplicate tickets across chat and email? This is one of the main reasons to move to a shared inbox in the first place. When chat and email both feed into one system, a customer's follow-up email on an existing chat conversation can be merged or linked rather than treated as a brand-new ticket, so you're not accidentally assigning two people to the same problem.
What's the difference between a filter and an assignment rule? A filter surfaces conversations based on criteria you set, such as tag, wait time or customer type, so you can see what needs attention. An assignment rule automatically routes those conversations to a specific person or team once they're identified, so nothing sits unclaimed waiting for someone to notice it.
Do I need per-seat pricing to give my whole team access to tags and filters? Not necessarily. Flat-rate pricing models exist specifically so that every team member can use tags, filters and assignment rules without your costs climbing every time you add a person. It's worth checking this before committing to a tool, especially if you expect your team to grow.