How Do You Tell A Client You Were Wrong?

How do you tell a client you got something wrong?

Directly, early, and with the fix already in hand. You name the mistake in plain language, you say what it cost them, you say what you are doing about it, and you do not decorate any of those three. The whole message should fit in a short paragraph and should not contain the word unfortunately.

I have been doing this work for over six years, across more than seventy projects for twenty-five-plus clients, and the pattern is consistent. The conversations that damaged relationships were never the ones where I owned a mistake quickly. They were the ones where I managed the information.

This is not a piece about a particular incident, because I am not going to dress up a composite story as a case study. It is about the method I arrived at, and why the obvious instinct is the wrong one.

Why is hiding a mistake the expensive option?

Because you are betting that nobody will ever look, and in this work people eventually look. A wrong redirect shows up in Search Console. A broken sync shows up as missing records. A schema error shows up the first time someone runs a validator. The discovery is not in your control and the timing will be worse than now.

The cost is not the mistake, it is the delay. A client who hears about a problem from me treats it as competence. A client who finds it themselves three weeks later has to reconsider everything else I told them in those three weeks, including the things that were true.

That reassessment is the real damage, and it is disproportionate. One concealed error does not cost you one unit of trust. It costs you the assumption that you are the one reporting accurately, which is the entire basis of hiring an outside specialist.

When should you say it?

As soon as you are certain of what happened, and not one moment before. Those are two different pieces of advice and people usually only hear the first one. Speed matters, but a panicked message that turns out to be wrong about the cause makes things worse than a message an hour later that is correct.

So the sequence is: establish what actually happened, establish the blast radius, work out the fix and roughly how long it takes, then write. On most problems that is under an hour of work, which means you are still telling them the same day.

What you must not do is wait for the fix to be finished. Telling someone after you have quietly repaired it denies them the chance to make their own decisions in the meantime, and if they find out later that you knew and stayed silent, the repair counts for nothing.

The exception worth naming is the trivial mistake you catch and fix within minutes, before it had any effect. Reporting every one of those is not honesty, it is noise, and it trains people to stop reading your messages.

What words actually work?

Short, specific, unhedged ones. I got this wrong. Here is what happened. Here is what it affected. Here is what I am doing about it and by when. Four statements, in that order, with no cushioning between them and no throat-clearing in front of them. If you need a fifth sentence, it is probably an excuse.

Name the thing concretely rather than abstractly. Not there was an issue with the migration, but the redirects for the old blog URLs were not in place for two days, so anyone clicking an old link got a 404. The specific version is easier to trust because it is falsifiable, and people can tell the difference.

Quantify the impact if you honestly can, and say you do not know if you cannot. I do not yet know how many people hit those links, I am checking now, and I will tell you this afternoon is a perfectly good sentence. Precision about your own uncertainty reads as competence, not weakness.

Then stop writing. The urge to add a paragraph explaining why it was understandable is strong and it undoes everything above it. An explanation invited is context; an explanation volunteered is an excuse.

What should you not say?

Anything in the passive voice. Mistakes were made, the file got overwritten, the setting was changed. Every one of those sentences describes an event with no author, and the client can feel the missing subject even if they cannot name the grammar.

Do not blame the platform when the decision was yours. Tools do surprising things and sometimes that genuinely is the cause, but I have watched people reach for that explanation reflexively, and a client who knows the tool better than you expect will notice.

Do not ask for reassurance in the same message. I hope this is not a problem invites them to manage your feelings at the exact moment they are dealing with a problem you created. Tell them what happened and let them respond however they respond.

Who pays for the mistake?

I do, and fixed-fee pricing makes that answer easy. I price most projects between one thousand and ten thousand dollars as a fixed fee, which means the hours I spend fixing my own error are simply hours I do not get paid for, and nobody has to negotiate about it.

That was not the reason I moved to fixed fees, but it turned out to be one of the best side effects. Under hourly billing, every mistake creates an awkward conversation about whether the client is funding the repair. Under a fixed fee there is nothing to discuss, and the absence of that discussion is worth a great deal.

Where it gets genuinely harder is when the error cost them something outside my scope, such as ad spend sent to a broken page. My view is that you offer something real rather than something symbolic. Extra work, a credit, a reduced next invoice. What you do not do is apologise and move on as though the money were theoretical.

This is a different situation from a project that grows beyond what was agreed, which is a negotiation rather than a debt. I wrote about that distinction in what I do when a fixed-fee project goes over scope, and confusing the two is how people end up paying for their own mistakes twice.

Does admitting a mistake cost you the relationship?

In my experience it much more often strengthens it, which surprised me early on and no longer does. Clients have worked with suppliers before. They already assume something will go wrong at some point. What they have not often seen is somebody tell them about it first.

There is a caveat I want to be honest about. This works when it is occasional. A steady stream of well-written apologies is not a trust-building practice, it is evidence that your process is broken, and no amount of good wording fixes that.

It also works because of what it signals about everything else. If I tell you when I got something wrong, my assessment of what is going right becomes worth something. That is the same reason I refuse to promise outcomes I cannot control, which I explained in how I respond when a client asks for guaranteed rankings.

How do you make sure it does not happen again?

Change something structural and tell them what you changed. An apology without a change is a performance, and clients who have been around a while can tell the difference immediately. The change is the part that makes the apology mean anything, because it converts a promise about your intentions into a fact about your process.

Usually the structural fix is a check rather than more care. More care is not a plan, because you were already trying. A pre-launch pass that verifies redirects resolve, a validator run before a schema change ships, a scheduled look at whether a sync actually moved records this week. Boring, specific, repeatable.

Then write the check down where it will be seen again, not in your head. I keep this kind of thing in a short list I read before anything goes live, and the list has grown mostly out of my own errors. That is the useful function of a mistake: it tells you exactly where your process had no guard.

Finally, put it in your regular client update rather than leaving it as a one-off message. Fixed this, added this check, here is what changed, reads as a practice rather than an incident. That is one of the quieter reasons I send a written wrap to clients every week, which I described in the Friday wrap letter I send retainer clients.

What should you do next?

If you are sitting on something right now, send the message today. Four sentences: what you got wrong, what it affected, what you are doing, by when. Do not draft it five times, and do not wait until you have fixed it, because the waiting is the part that does the damage.

If you are not sitting on anything, spend twenty minutes writing down the last three mistakes you made and what check would have caught each one. That list is more useful than any process document you could buy, because it is about your actual failure modes rather than somebody else's.

And if you want to talk through how to handle one of these with a client, reach out. I have had this conversation from both sides and I am happy to help you word it.