# A week late, eval below target: how to give a client bad news > Clients rarely get angry over a bad number. They get angry when it surprises them, and when the person delivering it arrives with no options. Original: https://fdetimes.net/en/guides/how-to-deliver-bad-news-to-clients/ Picture this: it is Thursday afternoon and you have just run the final eval before Monday's demo. The support-ticket classification agent scores 81%, while the kickoff slide three weeks ago clearly said the target was 90%. The client knows nothing yet. Their manager has invited their own boss to the demo. Anyone who works as an FDE long enough will face this, sometimes as a missed eval number, sometimes as a week's delay. The technical part can usually be fixed. Whether the client's trust survives depends far more on how you deliver the news in the days before the demo. The reason is simple. Every project hits problems, so clients do not judge you on whether problems happen. They judge you on when they found out, how they heard it and what plan they left the meeting with. ## Why is surprise worse than the bad news itself? Atomic Object, a software services firm, has concluded from its own experience that the worst reactions come when bad news lands without any warning. The 81% figure does not wreck the relationship. But if the client hears it for the first time in the demo, in front of their boss, the relationship really can break. So delivering bad news starts before there is any bad news. Leslie John, a professor at Harvard Business School, advises making it clear from the start of a relationship that you are on the client's side, while preparing them for the possibility of unwelcome news later. For an FDE, that means saying at kickoff that 90% is a target, and that you will report the remaining gap every week. Scott Logic, a technology consultancy, has a phrasing worth memorising: every estimate is only a snapshot at that moment, it will change, and you will update it regularly. Once a client is used to updates like this, 81% is just another update, not a shock. ## Lead with the finding, not an apology The natural instinct is to apologise first and explain later. PostHog's FDE handbook takes a different line: when talking to a client, open with what you found and what you propose to do. Do not open by saying you have just finished a report. "Here is this week's eval report" is a wasted sentence. "The agent scored 81%, short of 90%, and here is what I propose" gets straight to the point. Atomic Object advises presenting bad news clearly, without excuses, with data and visuals, and arriving with solutions already prepared so the client sees you genuinely care rather than turning up empty-handed. The Harvard Program on Negotiation adds one point: frame bad news constructively, by showing what can still be done. **Key point:** Clients forgive a bad number, but they struggle to forgive being surprised. ## A worked example: 81% instead of 90% Back to the ticket classification agent. Before writing the email, take the number apart. Suppose the test set has 200 tickets: 81% means 162 correct and 38 wrong. Group the errors and you find that 30 of the 38 fall into two ticket types, refunds and invoice disputes, which together account for 40 tickets. Now the problem looks different. Take those two types out and you have 160 tickets with 8 errors, or 95% accuracy on 80% of tickets. You no longer have only bad news: you have bad news, plus most of the scope beating the target, plus a narrow area that needs more work. The email to the client on Friday morning, before the demo, could read: > **Subject: Pre-demo eval results — 81% overall, 95% on 6 of 8 ticket types** > > Hi Minh, the final eval result is 81%, below the 90% target we agreed. The errors are concentrated in two ticket types: refunds and invoice disputes account for 30 of the 38 errors (chart attached). The other six types reach 95%. > > There are three options. (A) Demo and go live on the six passing types, with staff continuing to handle the other two. (B) Push the demo back a week to add labelled data for the two hard types. (C) Go live on all eight types, but route refund and invoice tickets through human review. > > I recommend option A. This is where things stand today, and I will send an update on the remaining two types next Friday. Could you give me 15 minutes this afternoon so we can settle on an option before Monday? Every part of the email has a reason. The subject line states the finding. The chart is data, not an excuse. The three options give the client a choice. The recommendation tells the client what you think, and the 15-minute call turns an option into a decision. Atomic Object's reminder: once you have borne the pressure of delivering bad news and discussing options, do not let the conversation end without a way forward. ## A week late: first ask why There are two kinds of delay, and each is reported differently. The first is when you estimated badly or hit a technical problem. Atomic Object argues that for schedule slips, the best option is usually to control scope by cutting part of it. The second is scope creep. Imagine you promised to integrate three systems, the client asks for two more midway, and you agree to keep the peace. PostHog's handbook is blunt: a work item that doubles in scope is a new quote, not a silent extension. When reporting the delay, separate what was committed from what was added, then propose delivering the three promised systems on time and moving the two new ones to a later phase. The best prevention still lies at the start of the project. PostHog advises agreeing a small scope, because expanding a tight scope is far cheaper than unwinding a loose one. The tighter the scope, the less bad news there is to deliver. ## Five steps, and the common mistakes The process comes down to this. Flag a risk as soon as it appears. Analyse the number until you find the part that still meets the bar. Write a message that opens with the finding and comes with data. Offer two or three options and a recommendation. Close with a decision and the date of the next update. There is a subtler mistake too: spin. Framing things positively means showing the path that is still open, not hiding the 81% behind the 95%. Scott Logic stresses that communication is the foundation of trust. That is why a rosy version the client uncovers on their own erodes the very trust you are trying to protect. ## Turning this skill into an interview advantage If an interviewer asks about a time you had to give unwelcome news to a client or stakeholder, do not answer in generalities. Prepare a real story in advance and tell it in exactly this structure: finding, data, options, decision, outcome. On your CV, instead of "strong client communication", write something like "proposed narrowing go-live scope when evals missed target, keeping the handover on schedule". Do not rehearse it for the first time in front of a real client. Bad news delivered early, with data and a way forward, usually ends with "OK, let's go with option A". Hide the same news for a few more days and it can end in a meeting you are not invited to. **Try this week:** - Pick a real risk in your current project and send the client a one-line early warning, with the date you will next update them. - Take your latest eval result, group the errors by category and recalculate accuracy for the remaining scope after removing the two largest error groups. - Draft a bad-news email in the five parts above for the situation you dread most, then ask a colleague to read it as the client. ## Sources - [How forward deployed engineers work - Handbook](https://posthog.com/handbook/forward-deployed-engineering/how-we-work) - [Problems Happen; How Do You Deliver the Bad News to Clients?](https://spin.atomicobject.com/deliver-bad-news/) - [Delivering Bad News in Negotiation](https://www.pon.harvard.edu/daily/negotiation-training-daily/dear-negotiation-coach-breaking-bad-news-nb) - [How to deliver a difficult message](https://blog.scottlogic.com/2020/08/04/how-to-deliver-a-difficult-message.html)