Every agency that keeps clients after launch ends up running a help desk, whether or not it calls it one. “Can you change the phone number on the contact page?” “The form isn’t sending.” “Why does the site look different on my phone?” Each request is small. Together they fill the gaps in your designers’ and developers’ weeks, and the project work that actually pays well keeps getting pushed back.
We take that queue off your team’s hands. Your clients keep writing to you, exactly as they do now. The WordPress requests are passed to us, we sort them, fix what can be fixed, and give your team ready-to-send replies. This is one of the services described in our guide for agencies that outsource WordPress work, and it is probably the one that changes your team’s day the most.
What the ticket problem really costs an agency
The cost is rarely the time spent on any single request. It is the interruption. A developer halfway through building a template stops to fix a menu link, then spends twenty minutes getting back into the template. Multiply that across a week and a couple of senior people are working at half speed.
There are quieter costs too:
- Small requests sit for days because each person assumes someone else picked them up.
- Clients chase, and the chasing email takes longer to answer than the fix would have.
- Change requests sneak in as “quick support questions” and are done without being billed.
- Nobody has a clear picture of which clients generate most of the requests, so plans never get adjusted.
An outsourced help desk helps with all of these, but only if the arrangement is set up so that responsibility is clear and your client never feels a hand-off.
How requests reach us
We fit around how your clients already contact you. The common set-ups are:
- Forwarding. Your account manager forwards a client email, or a rule on your support address sends WordPress requests to a shared inbox we read.
- Your ticket system. If your agency already uses a help desk tool, you can give us a login on it, and we work the tickets assigned to us there.
- A shared channel. Some agencies prefer a dedicated Slack channel or WhatsApp group per client or for all clients, where they drop requests as they arrive.
Whatever the route, we need the same things with each request: the site, what the client actually said, and anything your team already knows about it. A screenshot from the client is worth more than a paraphrase. Our post on describing a website problem so a developer can act on it is written for site owners, but the same checklist works for account managers passing requests along.
Sorting before fixing
The first thing we do with any request is decide what kind it is. We use three buckets, and you agree the rules with us at the start:
- Urgent. The site is down, the checkout or contact form is failing, the client is seeing a security warning, or something is visibly broken on a page that matters. These are treated as urgent client-site problems and handled first.
- Routine support. Content edits, small layout fixes, plugin settings, image swaps, a menu that needs reordering. These are worked through in order.
- Change request. A new page template, a new feature, a new integration. These are not fixed straight away. We send your team a short scope and estimate so you can quote the client.
That third bucket is where agencies quietly lose money, and it is why triage comes before anything else. If you want to build your own rules for it, our post on sorting client requests into urgent, routine and change work goes into detail, and the one on keeping scope creep under control on WordPress projects covers what to say when a client pushes back.
Who writes to the client
You do. Of everything involved in handling your clients’ support tickets, this is the rule we are firmest about. We do not reply to your clients, even from an address that looks like yours, because the moment two different people are writing in your name the tone drifts and the client notices.
What we give your team instead is a drafted reply for each ticket we close: what was changed, in plain words, with anything the client needs to check. Your account manager reads it, adjusts it if they like, and sends it. For simple requests that takes seconds. For awkward ones, such as a client asking why a page broke after they edited it themselves, a careful draft saves your team the hardest part of the job.
What your client experiences
From the client’s side, very little changes, except that things get done. They email the same address and hear back from the same person. Their requests are handled more consistently, and the replies explain what happened rather than just saying “done”.
Because our team is in India, a request your client sends late in their afternoon often reaches us while your office is closed. That does not mean every ticket is finished overnight, and we do not promise times. It does mean the queue can move while your team sleeps, so the morning starts with drafted replies waiting rather than a pile of unread requests. Our post on communication habits that work across time zones explains how to make the most of that.
What stays in your hands
- The decision on what counts as support and what counts as a billable change.
- Every word the client reads.
- Which clients are covered and which requests you would rather handle yourself.
- Any request that touches money, contracts or the client’s own customers.
If a ticket looks like it is about something bigger than WordPress, for example a client unhappy with the relationship, a dispute about an invoice or a legal question about their privacy policy, we flag it back to you untouched.
When a ticket turns out to be a bigger job
Some requests that look small are not. “The form isn’t sending” can be a plugin setting or a mail configuration problem on the host. “The site is slow today” can be a single heavy image or a server issue. When a ticket grows, we stop, tell your team what we found, and give an estimate before going further. Deeper faults move to our one-off bug fixing for agency client sites, and if you are simply short of hands for a busy month, overflow development help may suit better than ticket work.
Before any change on a live site we take a backup, and where the site has a staging copy we test there first. Each closed ticket has a short internal note of what was done, separate from the client draft, so your team can answer follow-up questions without asking us.
The first few weeks
A help desk only works once the person answering knows the sites. So the start is deliberately slow. You send a list of the client sites in scope, the access you are comfortable sharing for each, and, if you have it, a sample of recent requests and the replies your team sent. Those old replies tell us more about your agency’s tone than any style guide.
For the first stretch, we suggest your account managers read every draft closely before sending, and tell us when something does not sound like them. Most of the adjustments are small: a greeting you never use, a level of detail one client finds patronising and another finds reassuring. We keep a short note per client of those preferences, along with anything quirky about their site, such as a page builder the client edits themselves or a plugin that must never be updated without warning them first.
The weekly picture
Once a week, or on whatever rhythm suits you, you get a short summary of the queue: what was closed, what is waiting on the client, what was sent back as a change request, and which sites generated the most requests. That last point is useful when you review plans. A client who sends a steady stream of edits may belong on a different plan, and a site that keeps breaking in the same way may need a proper fix rather than another ticket. Agencies that already pass their recurring updates to our maintenance service run under your name often find the ticket count drops once the underlying sites are kept in better shape.
For the bigger picture of how we work with agencies, see the white label development and support page.