Monday morning, and the support inbox holds a mix that every agency recognises. One client’s checkout is throwing an error. Another wants the opening hours changed. A third has sent a long email titled “small tweaks” that turns out to describe a new section, a new form and a different font. A fourth is asking why their Gmail is not receiving anything. All four are marked “urgent.”
If you answer them in the order they arrived, the store loses sales while you change opening hours. If you answer the loudest first, the quiet client with the broken checkout waits. Triage is the habit of sorting requests by what they are, not by when they came in or how they are worded. It is simple to describe and takes discipline to keep, especially once part of the work is outsourced.
Four piles, not two
Most agencies sort mentally into “urgent” and “not urgent.” That misses the distinction that causes the most friction: the difference between fixing what exists and building something new. A more useful split has four piles.
- Urgent. Something that was working has stopped, and it is costing the client money, leads or reputation right now.
- Routine. Small, expected work inside whatever the client already pays for: content edits, a plugin that needs attention, a minor display problem.
- Change request. Anything that adds, redesigns or extends. It may be small, but it is new, and it needs a quote or at least a scope before anyone starts.
- Not ours, but we will point the way. Problems with email providers, the client’s own office network, an advertising account, a third-party booking platform. You may help, but the fix sits with someone else.
The fourth pile matters more than it looks. Without it, agencies end up quietly absorbing work that belongs to a host or a software vendor, and the client learns to send everything their way.
What actually makes a request urgent
Clients use the word urgent to mean “important to me today,” and that is fair. Your job is to work out whether it is urgent for the site. Four questions settle almost every case:
- Is it broken, or is it a wish? A button that no longer works is broken. A button they would like in a different colour is a wish.
- Who is affected? All visitors, some visitors, or only the client in the admin area? An editor glitch that annoys the client is real, but it is not the same as customers seeing an error.
- Is money or data at stake? Payments, bookings, enquiry forms, logins and anything that looks like a security problem move up the list straight away.
- Is it getting worse? Spam being sent from the site, pages being changed by someone unknown, or a site that slows further each hour all count as urgent even if the visible symptom is small.
If the answer to the first question is “broken” and either of the next two points to customers or money, treat it as urgent. Otherwise it is very likely routine.
Sorting real examples
| Request as written | Pile | Why |
|---|---|---|
| “Our site shows a critical error” | Urgent | Every visitor is affected |
| “Customers say payment fails at the last step” | Urgent | Lost sales right now |
| “Enquiry form says thanks but we get nothing” | Urgent | Leads are silently lost |
| “Please update the team photo” | Routine | Expected content edit |
| “There’s a weird gap under the footer on mobile” | Routine | Display issue, site works |
| “Can we add a blog to the site?” | Change request | New feature |
| “Small tweak: a members-only area” | Change request | Despite the wording, a project |
| “Our Outlook is not getting emails” | Usually not ours | Mailbox provider, unless the site’s own mail is involved |
Wording is unreliable in both directions. “Small tweak” can hide a project, and “just wondering” can hide a security problem. Sort by what the request describes.
The first reply does most of the triage
You often cannot sort a ticket from the first message. A short reply that asks the right questions sorts it for you and shows the client you are on it. Keep the questions few and easy to answer:
- Which page? Please paste the full address.
- What did you expect, and what happened instead?
- Is it happening for customers, or have you only seen it yourself?
- Roughly when did you first notice it?
If clients regularly send thin reports, it is worth giving them a short guide once. Our post on reporting a website problem usefully is written for non-technical people and can be shared as it is.
Sample replies for each pile
Having a starting point for each type of reply keeps the tone consistent, whoever on your team is answering. Adapt the wording to your own voice.
Urgent
“Thanks for flagging this. We have confirmed the checkout error and are working on it now. I will update you as soon as we know the cause, and again when it is fixed. In the meantime, if a customer contacts you, it is fine to take their order by phone or email.”
Do not promise a fix time you cannot control. Promise the next update instead, and send it. Our post on telling a client their site is down goes further into what to say during an outage.
Routine
“Got it, thanks. This is part of your regular support and is in our queue. I will let you know once the new photo is live.”
Change request
“Thanks, this is a good idea. A members area is new work rather than support, so I would like to scope it properly before we start. Could we have a short call this week? I will send a written estimate after it.”
Not ours
“Your website’s forms are sending correctly, so this looks like an issue with the mailbox itself, which is managed by your email provider. Here is what to ask them. If it helps, I am happy to join the call.”
Change requests: the boundary clients respect
Most clients do not object to paying for new work. What they object to is surprise. If you quietly do three “small tweaks” free, then quote the fourth, the client hears that you have started charging. If you name every change request as a change request from the start, politely and without fuss, the client learns where the line is. That line is also your main defence against margin leaks, which we cover in handling scope creep on WordPress projects.
A practical habit: when a message mixes support and new work, split it. Reply that you will handle the broken link now under their plan, and that the new section needs a short estimate. Two tickets, two clear expectations.
Triage when the work is outsourced
When a partner does the technical work, the sorting should stay with you. You know the client, the contract and what they pay for. Your partner sees the site but not the commercial picture. Two things help:
- Label every ticket before it goes to the partner. “Urgent: checkout failing for customers” tells the partner to drop other work. “Routine: footer gap on mobile” tells them to slot it in. Unlabelled tickets get handled in arrival order, which is exactly what triage is meant to prevent.
- Agree how urgent work reaches them. If routine tickets go by email, urgent ones probably need a different channel so they are not buried. With a large time difference, also agree what happens when an urgent problem arrives while their team is offline: who takes the first look, and what holding steps are safe, such as switching off a newly updated plugin or restoring the last backup.
Your partner should also feed information back the other way. If they open a “routine” ticket and find a security problem, they should re-label it and tell you at once, not quietly fix it in turn.
Habits that quietly break triage
- Letting the channel decide the priority. A WhatsApp message feels more pressing than an email, but the medium says nothing about the problem. Sort by content, whichever way it arrived.
- Re-sorting every time a client chases. A second “any update?” on a routine ticket does not make it urgent. Answer it kindly, keep its place.
- Never closing the loop. A ticket marked urgent that gets fixed but never confirmed to the client leaves them unsure, and the next problem arrives louder.
- Keeping the rules in one person’s head. If only the founder knows what counts as urgent, triage stops when the founder is on holiday. Write the four piles down where the whole team can see them.
Put the piles in writing
The four piles work best when the client has seen them before the first ticket. A short section in your support agreement that says what counts as urgent, what is included as routine and how change requests are handled saves arguments later. You do not need to attach response times you cannot keep; you need clear definitions. Our post on what a service level agreement should contain explains how to set that up honestly.
Triage is also one of the things that keeps an agency’s outsourcing calm rather than chaotic, which is a theme running through our overview of how agencies outsource WordPress work.
A weekly look back
Once a week, skim the tickets that came in. Which clients send the most urgent ones, and are they really urgent? Which routine requests keep repeating, and could the client be shown how to do them? Which change requests turned into paid work, and which slipped through as unpaid? A short look like this tells you more about your support setup than any dashboard.
If the sorting is under control but the volume of tickets is not, our outsourced help desk for agency client tickets takes the technical work on your labelled tickets while the client conversations stay with you.
Next in this series: Async Communication for Agencies Across Time Zones
