I assist a web design agency by handling the support side of the business. Front-line tickets, technical triage, enforcing policy, and quoting custom work like landing pages, custom forms, and thank you pages, then building all of it myself. Often all before noon.
Six thousand tickets is enough volume that patterns stop being anecdotes. The same five arguments show up over and over with different names attached. What follows is what actually held up.
Some context first, because it shapes everything below. The agency I assist handles light changes at no charge. Swap a photo, fix a typo, update a phone number. Anything larger gets quoted and billed hourly. That single line determines most of my day. Every ticket that arrives is really a question about which side of it a request falls on, and a fair number of tickets are an attempt to move the line.
Your shop may draw it somewhere else entirely, or not draw it at all. Swap the specifics. What follows is about the mechanics, not the pricing.
1. Your response time is a policy, whether you wrote one or not
The instinct is to answer fast. It shows you care, clients notice it, and nobody has ever complained that support was too responsive. For a long time I replied to most tickets within fifteen minutes and considered it a competitive advantage.
It is one. It is also a training program, and I didn’t understand what I was teaching.
An example. A client emailed asking for a disclosure line to be added to his footer. Small change, done in a few minutes, no charge. He replied asking to move it to a different spot. Done. Then reword it. Done. Then reword it again. Then swap out a set of buttons across the site, then repoint some menu links, then remove a page. By the end of the week that thread held nine separate requests, and each one arrived faster than the one before it, because each of my replies came back faster than the last.
Now look at what happened to the free-changes policy. Every single item on that list, taken on its own, is a light change. Two minutes, five minutes, no invoice. Strung together it was most of a workday, delivered for free, one small favor at a time.
That is the danger, and it is easy to miss because there is no villain in it. He wasn’t gaming me. He was behaving rationally inside a system where requests were free to send and answered instantly. Thinking his changes through in advance would have cost him effort and gained him nothing. So he didn’t, and I would have done the same in his position.
Speed sets the price of a client’s attention. Make requests free and immediate and the cheapest thing a client can do is stop thinking before they send. Organizing becomes the expensive option. Nobody drip-feeds a channel that replies tomorrow morning, because waiting a day per item is painful, so they sit down and write one complete list instead. I had removed every reason to do that, then got frustrated when nobody did.
The piece that took me longest to accept is this. A client cannot tell the difference between a five-minute reply and a three-hour reply. Both read as excellent support. I can absolutely tell the difference across a full day, because one version leaves my afternoon intact and the other leaves it in pieces.
So the fix has two halves.
The first is cadence. Answer in windows rather than instantly. Let real outages jump the line and let everything else wait for the next window. Nothing is lost, because what clients actually value isn’t speed. It’s reliability. When I answer, it’s correct and nothing falls through the cracks. That holds at any cadence.
The second half is a question, and it does more work than the cadence does. Before I build anything, I ask for the finalized list of changes.
That one request sorts people immediately. A client who has thought it through sends a list, and now I can see the real scope up front instead of discovering it across nine emails. A client who hasn’t either goes quiet or comes back with something much shorter, because being asked to name everything is often the first time they’ve thought past whatever is bothering them at this exact moment. And a client hoping to get a project done in free-sized pieces learns right away that it isn’t going to work that way.
Most people don’t think beyond the surface of a request, and that isn’t a character flaw. It’s just how requests get made. But it means “can you move this button” is frequently the visible tip of a redesign nobody has articulated yet, including the person asking. Making them name the whole thing turns a vague itch into something you can scope, price, and finish, which is better for them too, even though it rarely feels that way when you ask.
The lesson: how fast you reply is a rule you’re teaching whether you meant to write one or not. Answer in windows, and ask for the complete list before you start. One request at a time works fine with a handful of clients. At volume it fails quietly, as a slow leak of unbilled hours that nobody ever files a complaint about.
2. Draw the line before the work, not after
This one is harder than it sounds, because the wrong move feels generous.
A request comes in that’s a little past what’s included in the free-change policy. Not egregious, just over the line. You could quote it, but it’s twenty minutes and the client seems reasonable, and quoting twenty minutes feels petty. So you do it and add a note: happy to take care of this one as a courtesy, going forward changes like this will be quoted.
That felt like good service to me for a long time. I’m solving their problem, I’m being flexible, and I’m still communicating the policy. The client gets what they need and learns where the line is. Everybody wins, and I get to be the person who goes above and beyond instead of the person who nickels and dimes over twenty minutes.
On paper it’s the right call. In practice you’ve just taught them the opposite of what you wrote.
I know because I did it for about a year.
Go back to that same thread. Every reply I sent closed with some version of “any further changes will need to be quoted.” I wrote that sentence four separate times across nine requests. Not once did I write it before doing the work.
Every one of those was a one-time courtesy in my head. Each felt like a small, reasonable exception on its own merits. Four of them in a row is not a series of exceptions. It’s the actual policy, demonstrated four times.
Put yourself in his chair and the outcome is obvious. He was told four times that changes get quoted, and four times the change showed up finished and free within minutes. So the rule he learned was the accurate one. Anything phrased as a quick tweak is free, and the line about quoting is just how this guy signs off his emails. He wasn’t ignoring the policy. He had correctly worked out that the policy was a sentence rather than a behavior.
The uncomfortable part is that the courtesy didn’t even buy goodwill. It bought a shorter interval before the next request. Free work performed at speed doesn’t read as generosity to the person receiving it. It reads as the service level.
A boundary isn’t created by describing it. It’s created by not doing the work. Clients believe what you do, and the words come a distant second.
Which means timing is the entire game. Scope a request when it arrives, not when you deliver it. If a request touches several systems at once, arrives as an attached document, or contains the word “also” three times, it gets priced before anything happens. That isn’t being difficult. A quote sent up front is information the client needs in order to decide, and most of them would rather have it than get surprised later.
And if you’ve already blown past your threshold, resist the urge to bill backwards for work you’ve already handed over. That fight isn’t winnable and it makes you look erratic. Say plainly where things stand and set a clean line going forward instead.
The version I’d give someone in their first week: it’s counting to three and never getting to three. Kids sort that out in about a day. So do clients.
The lesson: decide free or billable before you touch the work, because a policy announced after delivery isn’t a policy. It’s a signature line.
3. A rule they can read beats a rule they have to hear from you
When you know your policies cold, handling scope case by case feels efficient. You’re reasonable. You’ll explain it when it comes up.
The problem is that anything living only in your head is negotiable by definition. Every conversation becomes a fresh negotiation, and the client who pushes hardest ends up with the best terms. That’s the opposite of fair, and it’s exhausting to run.
A client contact once pushed back on our hourly rate and asked for a flat quote instead. When that didn’t move me, they brought their CEO into the email thread as leverage. My position was correct and it held. It also cost several days, because everything I was defending lived in my head and in precedent rather than in a document they could go read for themselves.
Compare that to how the same conversation goes when the policy is written down and was shared at the start. “Here’s what’s included, here’s what gets quoted” stops being my opinion and becomes a fact of the arrangement, the same as the monthly rate. There’s nothing to argue with, because I’m not the one who decided it in that moment.
This matters even more for the things you don’t control. Tools the client bought directly. Accounts in their name that you can’t log into. Platforms their compliance team picked. A boundary presented up front as a known condition of the service costs you nothing. The same boundary defended in the middle of an escalation costs you a week.
Small companies run on shared memory until they can’t. The moment more than one person has to enforce the same rule, or the moment the same argument happens twice, it needs to exist somewhere a client can read it.
The lesson: put the policy somewhere the client can read it themselves, and share it before the first ticket. A rule that only exists in your head is a rule you’ll renegotiate with every account, forever.
4. “It’s broken” often means “it isn’t what I pictured”
A good share of tickets that report a broken website are not reporting a broken website. They’re reporting a gap between what the client expected to see and how the technology actually works. Both arrive worded exactly the same way, and telling them apart before you start fixing things matters more than almost anything else in this job.
Here’s the ticket that taught me that.
A client noticed that when he zoomed in on his laptop, the navigation menu across the top of his site collapsed into a hamburger icon. He reported it as broken and asked us to fix it. Nothing was broken. That’s responsive design doing exactly what it’s built to do. When the usable width of the window gets small enough, whether because the window shrank, the user zoomed in, or the visitor is on a phone, the full menu collapses into an icon so it still fits.
I explained that. He didn’t accept it. I explained it again with more detail. He didn’t accept that either. This ran across four separate tickets over about two months, and every round he was more certain than the last that we had broken his website.
This is the confidently incorrect client, and every support person knows the type. Not hostile, not stupid, not trying to get anything for free. Just completely sure about something that isn’t true, and getting surer each time you correct them. Confidence and accuracy are separate things, and when they come apart like this, no amount of additional explanation closes the gap. More detail reads as excuses. Repeating yourself reads as stonewalling. The clearer you get, the more it looks like you’re defending a mistake.
Eventually I gave him what he was asking for. I disabled the collapsing menu so the full navigation would stay visible no matter how narrow the window got.
It worked. For about a week.
Then the complaints started about the site being unusable on phones, which was accurate, because I had just removed the thing that makes a site usable on a phone. Visitors on mobile were now getting the full desktop navigation crammed into a four-inch screen, unreadable and impossible to tap. To satisfy one person’s expectation on his own laptop, I had degraded the site for every actual visitor he had.
The root cause turned out to have nothing to do with menus. He believed a “mobile version” was a separate website that we simply hadn’t built yet. That was genuinely how it worked around fifteen years ago, and nobody had ever updated him. Every complaint he filed made complete sense from inside that belief, which is why more technical detail never helped. I kept answering the question he asked instead of correcting the assumption underneath it.
There’s a second flavor of this that’s easier to resolve. Sometimes the site really is fine and something in the client’s own environment is interfering. A browser extension blocking part of a page. A corporate VPN routing traffic oddly. A stale cached copy of the page on one laptop. DNS changes that haven’t finished propagating, so the client sees the old site while everyone else sees the new one. From their side, every one of these looks identical to “the website is broken,” which is a fair conclusion for someone non-technical to reach. They’re looking at their screen and their screen is wrong.
For those, stop explaining and hand over a test they can run themselves. Open the page in a private browsing window, which loads it without extensions or cached files. If the problem disappears, it’s local to their setup. If it doesn’t, we’ve learned something new and I’ll keep looking.
That move works where repetition fails, because the client proves it to themselves. I’m no longer asking anyone to accept my assessment, which means nobody has to be wrong out loud. It also keeps me honest, since occasionally the client is right and the problem really is ours.
But no test resolves the first flavor, and that’s the one worth being careful about. When a client’s expectation is simply wrong, the fix isn’t technical. It’s correcting the belief, and if you can’t correct it, bending the product to match it can cost you more than the argument would have.
The lesson: confirm something is actually broken before you fix it. If the complaint is really an expectation problem, address the expectation, because changing the product to satisfy one person’s mental model can quietly break it for everyone else.
5. A moving target isn’t a communication problem
Early on I treated escalation as an admission that I couldn’t manage my own account. So I held on to things far longer than I should have, and the clearest example ran two months.
It was the same account I mentioned earlier, the one whose marketing contact pushed back on our hourly rate and brought their CEO into the thread. That pricing argument was the opening act. Once it settled and we actually started the project, things got considerably worse.
The request was a custom landing page. What arrived was an AI-generated HTML mockup with the instruction to build a page matching it exactly.
Two problems before anyone writes a line of code. First, the mockup ignored the website it was supposed to live on. Different fonts, different imagery, different color treatment, different everything. It shared nothing with their existing brand, so building it as specified meant producing a page that looked like it belonged to another company. Second, matching it exactly was well over a dozen hours of work, which is a real project with a real price, not a change request.
Then there’s the practical problem, and this is the one that actually consumed the two months. We require assets before a custom build starts. Real images, final copy, actual headlines. The mockup had none of that. It was full of placeholder text and placeholder image blocks, which is what these files always are, because the AI doesn’t have their photos or their approved messaging. So I did what you have to do and replied asking for the specifics. What image goes in this block. What does this headline actually say. Is this section real or filler.
Here’s what came back. Not answers, but a new version of the file.
Every time I asked for clarification on one section, they’d go back to the AI to sort it out, and the AI would regenerate the whole document. The section I’d asked about might now be resolved, and four other sections would have changed shape. New layout, new blocks, sometimes an entire module I’d already scoped simply gone. So my questions from the previous round no longer applied to anything, and I’d have to start over on a file I’d never seen before.
That loop ran for weeks. Each attempt to clarify one part broke several others, and the scope got vaguer with every round instead of tighter. We were moving backwards, and the harder they worked at it, the further back we went.
All I wanted was a decision. What is this page for. Who is it talking to. What should someone do when they land on it. Answer any one of those and I can build something and we can both move on with our lives. But those questions never got answered, because there was nothing underneath the request except a preference for whatever had been generated most recently. They liked how it looked. That was the entire case for it, and it’s an impossible case to argue with, because there’s no reasoning to engage.
Running underneath all of it was a steady argument about our policies. The hourly rate. The requirement that assets arrive before work begins. Whether any of it should apply to them. And whenever a point wasn’t going their way, the CEO would get copied in, which was clearly meant as pressure. It backfired every time, because each round of it put more of the thread in front of the one person on their side who could see what was actually happening.
That’s the part that wore on me. It wasn’t difficult work. It was the absence of work, stretched across two months, with a goalpost that moved every time I got near it. I’d open the inbox in the morning already tired of it. I started rereading my own replies looking for the sentence that would finally make it click, as though the problem was that I hadn’t found the right phrasing yet.
It was never phrasing. The person I was corresponding with had been handed a project bigger than their experience, and they were using AI to close that gap. Not maliciously, and not lazily. It genuinely looked like progress from where they were standing. But it meant every decision I needed from them was a decision nobody on their side was equipped to make, and no email I wrote was going to change that.
By week six I’d stopped doing support and started doing archaeology. Most of my hours were going into rereading old threads to reconstruct what had been agreed to and when, rather than into building anything. When that’s where the time is going, the ticket has already changed category and you’re usually the last one to notice.
It ended when their CEO, who had been copied on the thread as leverage during the earlier pricing argument, read enough of it to see what was happening. He replied with an apology, paused the project, and said they needed to get their own house in order first. He reached in about ten minutes a conclusion I’d spent six weeks not reaching, and only because he wasn’t inside it.
The delay was mine. I kept treating a stalled engagement as a communication problem I could solve with one more carefully worded email, and I kept treating my inability to solve it as evidence I wasn’t doing my job well enough. It was neither. It was a question about whether the project should continue in its current form, and that was never my question to answer.
The lesson: when a request keeps changing shape every time you respond, you aren’t close to a resolution. You’re stuck. Hand it up, because holding a stalled project to prove you can handle it costs far more than passing it along.
6. Asking AI for improvements feels like progress. It usually isn’t.
Back to that same landing page project, the two-month one with the mockups that changed every week. Running alongside it was a second thread, and that one has turned out to be the most relevant thing in this article to anyone doing support work today.
While the mockups were still cycling, a separate document arrived. Sixteen pages, fifty-eight requested website changes, generated by AI. A large share of the items didn’t apply to the site at all. Some referred to features the site doesn’t have. Some contradicted other items in the same document. Nobody had read it end to end before sending it, because reading it would have caught that.
The intent wasn’t bad. From their side this looked like productivity. A comprehensive optimization audit, delivered in a day, evidence of someone doing their job well. From my side it was a pile of busywork that had to be evaluated item by item and mostly discarded, and every hour spent doing that was an hour not spent building anything.
Two things changed at once here, and they compound.
Volume. Writing a detailed, professional-looking request used to take real effort, and that effort acted as a filter. A long document usually meant long thinking. That filter is gone. Anyone can now generate fifty recommendations in a minute and forward them to support, and doing it feels like diligence.
Meanwhile the work on the other end still has to be evaluated, sequenced, and built by a person who understands the site. Some of that has gotten faster too, and I use these tools daily. But nothing about generating a request in thirty seconds makes it thirty seconds cheaper to answer, so what actually happens is that the queue grows while the thinking behind each item shrinks.
Authority. Clients now arrive holding a confident answer about a system the AI has never seen. It doesn’t know their plan, their platform, or what’s actually installed on their site. But it sounds certain, so they argue from it. The job shifts from explaining something to someone who’s confused, to competing with something that already told them what to think.
Worth understanding why the output is so convincing. Ask an AI to review any website and it will return recommendations. Any website at all. Feed it Zillow or Walmart and you’ll get a tidy list of improvements for those too. Try it sometime. The output is generic by construction, surface-level and plausible and largely indifferent to the industry, the business model, or what the site is actually for. It reads as expert analysis because it’s organized and confident, not because it knows anything specific about you.
So the trap is that polish reads as competence. When output looks finished, people apply that feeling to their own understanding, not just to the document. That’s why it gets defended so hard. There’s no independent read underneath it to fall back on, so questioning the document feels like questioning them.
None of this makes AI useless, and I’d be a hypocrite to argue that. It’s a good tool for a first pass, a rough concept, or getting unstuck on a blank page, and it’s genuinely useful on my side of the desk too. The failure isn’t the tool. It’s treating the output as a decision rather than a starting point. A generated list can’t tell you what matters to your business, and it can’t be held accountable for a recommendation the way a person can.
The practical response is to stop reacting to the artifact and start asking what it’s supposed to accomplish. Not what it should look like. What it should do. Where does this information go when someone submits the form? What happens on a phone? Of these fifty-eight items, which five actually matter to the business?
If nobody can answer those questions, that isn’t a delay in the project. That’s the finding.
The lesson: a generated audit isn’t a plan and a mockup isn’t a specification. When a client can produce fifty recommendations in a minute, the thinking that used to happen before a request was sent now lands on your desk instead, and it stays there unless you hand it back.
7. Difficult and lost look identical in an inbox
The natural way to sort clients is by how much friction they generate. It’s also the wrong way, because volume tells you nothing about cause.
One client filed twenty-nine tickets in about six weeks. My read was high-maintenance nightmare and I was braced accordingly. Then I sat down and actually read what he was asking. How do I change this text color. Where’s the table tool. What does this plugin do.
He wasn’t pushing me. He was drowning.
Those are two different clients and they need opposite responses. The one testing whether your boundary is real needs it firm, short, and unmoving. Warmth reads as an opening and invites another round. The one who’s early on the learning curve needs links, screenshots, and patience, and most of them level off on their own if you don’t personally become their tutor.
Getting these backwards is expensive in both directions. Treat a struggling client like a demanding one and you manufacture the exact escalation you were trying to avoid, because now they’re frustrated and confused instead of just confused. Treat a demanding client like a struggling one and you spend a month being agreeable while the scope grows.
The tell is usually in what they’re asking for rather than how much they’re asking. Twenty-nine questions about how the tools work is someone learning. Three requests to reconsider your pricing is someone negotiating.
And worth remembering when the tickets stack up: a client not understanding the technical piece is the reason this job exists. That’s the demand signal. It isn’t a character flaw.
The lesson: before you decide someone is difficult, read what they’re actually asking for. Ticket volume tells you nothing about cause, and treating a struggling client like a demanding one creates the fight you were trying to avoid.
9 Non-Negotiable Rules for Support at a High-Volume Web Design Agency
Everything above, compressed into the version you can pin above your desk. These are written as mechanics rather than policies, because the policies won’t transfer. Whatever your shop charges for and whatever it gives away, the way clients respond to those decisions works the same.
- Your response time is a policy whether you wrote one or not. Clients learn what a channel is from how fast it answers, not from what you tell them it is.
- Ask for the finalized list before you build anything. It reveals real scope, filters people who haven’t thought it through, and stops a project from arriving one free-sized piece at a time.
- Draw the line before the work, not after. A boundary stated on delivery is a signature line. The boundary is created by not doing the work.
- Write the rule down or plan to renegotiate it forever. Whatever lives only in your head is negotiable, and the client who pushes hardest gets the best terms.
- Check whether anything is actually broken. “It’s broken” often means “it isn’t what I pictured,” and bending the product to match one person’s picture can break it for everyone else.
- Hand back a test, not an argument. You cannot out-explain a confidently incorrect client. A diagnostic they can run themselves ends a standoff that repetition never will.
- A request that changes every time you respond isn’t close to done. Hand it up rather than spending another month proving you can handle it.
- A mockup is not a specification. Ask what it should do, not what it should look like. If nobody can answer, that’s the finding.
- Sort by cause, not by volume. Difficult and lost produce identical ticket counts and need opposite responses.
What all of this actually comes down to
Read those nine rules again and you’ll notice they’re all versions of the same three ideas.
The first is that most of what frustrates you in this job, you built. Not on purpose, and usually while trying to be helpful. Fast replies taught clients to send half-formed requests. Free courtesies taught them the policy was optional. An unwritten rule invited a negotiation. Every one of those started as generosity and ended as a pattern I resented. Once you can see your own fingerprints on the behavior, the problem stops being the client’s character and becomes something you can actually change, which is a much better position to be in.
The second is that timing beats wording. Almost every hard situation in this article had a moment where the outcome was still cheap to change, and I missed it because I was busy being accommodating. Scope the request before you build it. Ask for the complete list before you start. Confirm something is broken before you fix it. Hand a stalled project up before month two. None of that requires a difficult conversation. It requires having the easy conversation earlier than feels necessary, and the whole skill is recognizing the moment while it’s still in front of you.
The third is that you can’t give someone judgment they don’t have. This is the one AI has made urgent. You will get requests with no thinking behind them, from people who are certain about things that aren’t true, holding documents they can’t explain. You cannot fix that with a better email, and every hour spent trying is an hour you don’t get back. What you can do is build gates that make their skill level matter less: required assets, a finalized list, a written policy, a test they can run themselves. Structure does the work that persuasion won’t.
None of this is about caring less. The tickets that wore me down were never the technically hard ones, because hard problems are fun. They were the ones where the work kept going after my part was finished, where I’d already given the answer, documented it, watched it get ignored, and then kept carrying the outcome anyway.
So do the work. Say the true thing once. Write it down.
Then let the rest of it belong to the client.
