"My site is broken" is the most expensive sentence in agency life. It can mean the site is down, a form stopped sending, a page looks odd on the client's own laptop, or the client cannot find a button that has always been there. You cannot tell which from the email, and the reflex to drop everything and look is exactly what ruins a working day.
A triage system does not make problems disappear. It makes the first ten minutes of each one predictable, so the real emergencies get fast attention and the imaginary ones get a calm, quick answer.
Sort by impact and scope, not by tone
Emails arrive with emotional volume that has nothing to do with severity. "URGENT!!! SITE DOWN" is often a cached page. "Small thing, when you get a chance" sometimes turns out to be a checkout that has not taken an order in two days.
Ignore tone. Score every report on two questions:
- Impact: is money, leads, or legal exposure being lost right now?
- Scope: is it everyone, or one person on one device?
Put those together and you get four buckets.
| | Everyone affected | One user or device | |---|---|---| | Money or leads at risk | P1: act now | P2: same day | | No direct loss | P3: next business day | P4: batch weekly |
A site that is completely down for everyone is P1. A contact form that silently fails is also P1, despite the polite email, because leads are leaking. A layout glitch in one browser on one phone is P4 no matter how annoyed the sender is.
Reproduce before you diagnose
Most "broken" reports are not reproducible on the first try, and chasing them blind is where the hours go. Before you touch anything, spend five minutes on a fixed checklist:
- Load the site from your side, in a private window, on a connection that is not your office's.
- Check the uptime record for the last 24 hours. A recorded outage settles the question quickly.
- Look at the activity log for anything that changed in the last day: updates, plugin activations, a user who edited a template.
- Ask the client for a screenshot with the address bar visible, and the time it happened.
Step three finds the cause more often than any other, because in most cases something changed. Sites rarely break spontaneously. Somebody, or some update, touched them.
Ask better questions, once
The back-and-forth is where a small problem becomes a two-day thread. Instead of "can you tell me more?", use a fixed intake with the questions you actually need.
What page, and what were you trying to do? What did you expect, and what happened instead? Does it happen on another device or browser? When did you last see it working?
Four questions, sent once, save four rounds of email. The trouble is that clients will not fill in a template you send by hand. They will answer questions inside a form they reach with one click, which is a good reason to move reporting from your inbox to a help desk. WPClientHub has one, with a magic-link portal so clients do not need a password, and an AI diagnosis step that suggests likely causes from the site's own data. It is a starting point for your judgment, not a replacement for it.
Have a reply ready for each bucket
Speed of acknowledgement matters more than speed of fix. A client who hears "got it, looking now, update in 30 minutes" is calm. A client who hears nothing for two hours starts drafting an angry email.
Write four canned replies and store them where you can reach them in one click.
For P1: "Confirmed and investigating now. You will hear from me within 30 minutes, whatever I find."
For P2: "Thanks. This is affecting leads, so I am treating it as same-day. I will confirm when it is fixed."
For P3: "Received. Scheduled for tomorrow morning. I will let you know what I find."
For P4: "Thanks for flagging. I have added it to this week's batch and will update you by Friday."
Each one states what happens next and when. That is the entire trick. Vague reassurance ("we are on it") is worth less than a specific time you then meet.
Know the usual suspects
After a few months you will notice that most incidents come from a short list. Learn them and you will diagnose in minutes.
A recent update is the top one, which is why every update should have a restore point taken first; the mechanics are in safe WordPress updates, explained. Next come expired SSL certificates, exhausted disk space or PHP memory, a plugin licence that lapsed and locked features, cached pages hiding a fix that was already applied, and mail deliverability problems that look like "the form is broken" when the form is fine and the mail is landing in spam.
When you find the cause, write one line in the site's record: symptom, cause, fix. Six months later, when the same symptom appears, you will thank yourself.
Close the loop and count
Every incident should end with a short message: what was wrong, what you did, whether anything needs the client's action. It takes two minutes and it is the most persuasive marketing you do, because the client sees the value of a problem being handled.
Then, once a month, count. How many P1s, how many were caused by a client edit, how many by updates, how many by the host. Arithmetic on your own log tells you where to invest. If half your tickets are clients breaking their own pages, a limited editing role or a short training session removes them. If updates cause most of them, tighten your update process. You cannot fix a pattern you have not counted.
Where this leaves you
Score reports by impact and scope, reproduce before you diagnose, ask four questions once, and reply within a promised time. The system is dull, and dull is what you want when a client is panicking. WPClientHub is free for 3 sites if you want to try the help desk on a real client site.