There's a specific sinking moment that everyone in service work knows. You realise you've made a mistake — missed a requirement, delivered the wrong version, got a fact wrong in something that's already published, misunderstood the brief in a way that's only now obvious. And in the seconds after that realisation comes the temptation: maybe they won't notice. Maybe you can quietly fix it. Maybe you can mention it later, when it's less raw.
That temptation is the actual danger, and it's worth being clear about why. Mistakes themselves are survivable and expected — clients have worked with providers before, they know that projects have problems, and a competent person occasionally getting something wrong is unremarkable. What isn't survivable is discovering that you knew and didn't say, because that changes the question from "are they perfect" to "can I trust them," and the second question is the one the relationship actually depends on.
There's something more counterintuitive here too, and it's genuinely useful to know: a mistake handled well can leave a relationship stronger than it was. Everyone can look competent when things go smoothly, so a client learns very little about you from a project with no problems. They learn a great deal from a project where something went wrong and you told them immediately, took responsibility, and fixed it properly — because that's evidence about your character rather than your luck, and it's exactly the evidence they need to trust you with something important later.
So the useful frame isn't how to avoid mistakes, which you can't entirely, but how to handle them — and it's a fairly short list: tell them fast, own it plainly, arrive with a solution, fix it properly, and be honest about the cost. Here's each part, and the instincts worth resisting.
Key Takeaways
- Tell them immediately. Speed is the single most important variable. A mistake disclosed early is a manageable problem; the same mistake discovered later is a trust problem.
- Own it without grovelling. Take clear responsibility, apologise once, and move to the fix. Excessive apology makes it about your feelings rather than their situation.
- Never arrive with only a problem. Bring the mistake and your proposed solution together — it turns an alarming message into a manageable one.
- Be honest about the cost. If fixing it was your error, absorb it. Trying to bill for correcting your own mistake destroys more value than it recovers.
- A well-handled mistake can strengthen a relationship. Clients learn nothing about your character from smooth projects and a great deal from how you handle a bad one.
Tell Them Fast
Of everything here, speed matters most. The moment you become aware of a significant mistake, the clock starts, and every hour that passes makes the situation worse in two ways: the practical damage accumulates, and the disclosure becomes harder to make cleanly. Tell them as soon as you reasonably can — ideally immediately, and certainly before they find out another way.
The practical argument is straightforward. Most mistakes are far more fixable early: the file hasn't been distributed yet, the campaign hasn't launched, the client can still adjust their plans, the error hasn't propagated into everything downstream. Delay converts a contained problem into a spreading one, and the client's options shrink with every hour they don't know.
The trust argument matters more. A client who learns you knew about a problem and didn't tell them has learned something about you that no amount of good work erases — and it recontextualises everything, since if you concealed this, what else? Whereas a client told immediately sees someone whose reports they can rely on, which is precisely what allows them to stop supervising you. This is the same principle as flagging a slipping deadline early: people handle almost anything better when they're informed and worst when they're surprised, and the surprise is what does the damage. [BACKLINK PLACEHOLDER → suggestion: internal link to article #91, how to manage multiple projects / telling clients early rather than at the deadline]
The instinct to wait usually comes from hoping the situation will improve — that you'll find a fix and can present the problem as already solved. Occasionally that works. More often the delay costs options and the fix takes longer than expected, and now you're disclosing both the mistake and the concealment. If you can genuinely resolve something in the next twenty minutes, resolve it; anything beyond that, tell them.
Own It Plainly, Without Grovelling
How you take responsibility matters, and there are two failure modes on either side of the right approach. The first is deflection: explaining the circumstances, noting that the brief was ambiguous, mentioning the timeline pressure. Even where these are true, leading with them reads as avoiding responsibility, and clients notice immediately. Say plainly what went wrong and that it was your error, without qualification.
The second failure is excessive apology, which is more common among conscientious people and does real damage of its own. Repeated, elaborate apologising makes the conversation about your distress rather than their problem — and now the client has to manage your feelings on top of dealing with the situation, which is an additional burden at exactly the wrong moment. It also reads as less professional rather than more, since disproportionate contrition suggests someone who doesn't handle problems routinely.
The functional version is brief: a clear acknowledgment, one genuine apology, and then straight to what happens now. Something like "this was my mistake — I'm sorry, and here's how I'm fixing it" covers everything necessary in a sentence. Clients overwhelmingly care about resolution rather than remorse, and the fastest route to reassuring them is demonstrating competent handling rather than depth of regret. Save the self-criticism for your own review afterwards, where it can actually produce a change. [BACKLINK PLACEHOLDER → suggestion: internal link to article #60, how to handle negative comments and criticism online / responding without over-apologising or getting defensive]
Arrive With a Solution
The single most effective habit in this whole area is never delivering a problem without a proposed solution attached. A message that says only "something has gone wrong" hands the client an alarming situation and nothing to do with it, which produces exactly the panic you'd want to avoid. The same message with a solution attached is a manageable event.
In practice that means taking a short time to work out your recommended fix, the timeline for it, and the implications, then presenting all of it together: here's what happened, here's what I propose, here's when it'll be resolved, here's what it means for the schedule. The client's experience shifts from "there's a crisis and I have to work out what to do" to "there was a problem and it's being handled," which is a completely different emotional register — and it's largely what determines whether they lose confidence in you.
Where there are genuinely different options with real trade-offs, present them with a recommendation rather than as an open question, since a client dealing with a problem you caused shouldn't also have to do the analysis. And where you can't yet see the full fix, say what you're doing to determine it and when you'll report back, which is still infinitely better than an unqualified problem. The principle is that you should be doing the work of resolving it, not transferring that work to them. [BACKLINK PLACEHOLDER → suggestion: internal link to article #107, your client wants to think about this less than you do / bring recommendations rather than handing decisions back]
🎬 Embed a short comparison of two disclosure messages — one presenting only a problem, one presenting the problem with a fix, timeline, and implications — and how differently each lands.
Fix It Properly and Absorb the Cost
Then actually fix it, and fix it properly rather than patching it. A hasty repair that leaves residual problems compounds the original error and suggests you were more interested in closing the issue than in getting it right — which undermines the trust you were trying to rebuild. Where the fix takes time, keep them updated as it progresses rather than going silent until it's done, since silence after a problem is particularly uncomfortable for a client who's now paying attention.
On cost: if the mistake was yours, absorb the cost of fixing it. This is occasionally painful, especially where the correction involves substantial rework, and attempting to charge for it is almost always the wrong economic decision — the amount you'd recover is small relative to the damage to a relationship that could produce years of work and referrals. Fixing your own error at your own expense is what a professional relationship assumes, and doing it without being asked signals seriousness far more effectively than any apology.
Whether to offer additional compensation — a discount, extra work, something to acknowledge disruption — depends on the severity and on what the client actually suffered. It can be a genuine gesture where the impact was significant, and it can also be unnecessary or even awkward for a minor issue promptly resolved, where it may inflate the event beyond its actual weight. The judgment is proportionality: match the response to the real impact rather than to your own discomfort, since over-compensating out of guilt is a version of making it about your feelings again.
Learn From It, and Change Something
The last step is the one that determines whether the same thing happens again, and it's worth doing properly rather than as self-reproach. After the situation is resolved, look at what actually caused it — not "I should have been more careful," which changes nothing, but the specific mechanism: was the brief unclear, was there no check before delivery, was the timeline unrealistic, did something fall through a gap between people?
Most recurring mistakes have process causes rather than character causes, and process causes are fixable. A missed requirement suggests a checklist or a clearer brief. Delivering the wrong version suggests a file organisation problem. A misunderstanding suggests a confirmation step that would have surfaced it. An overrun suggests estimating from optimism rather than history. In each case there's a change available that makes recurrence meaningfully less likely, which is worth far more than resolving to try harder. [BACKLINK PLACEHOLDER → suggestion: internal link to article #96, how to write a project brief / unclear briefs are behind a large share of avoidable errors]
It's also worth telling the client what you've changed, where it's proportionate. Saying that you've added a specific check to prevent recurrence is concrete reassurance in a way that a promise to be careful isn't — it demonstrates that the mistake produced a systemic response rather than just an apology, which is what a client needs to feel comfortable continuing.
