Running a business review with a customer: how FDEs prepare the numbers, risks and next steps

Three weeks after the system goes into production, the account manager messages you: there is a quarterly review with the customer next Thursday, the VP of operations will attend, and could you prepare the technical part?

Many engineers instinctively open Jira and list everything they have shipped. That is the quickest way to waste an hour of the most powerful person in the room.

The business review is where the customer decides whether to expand, renew, or let the project quietly sink. For an FDE, it is also the measure of your work: does the pilot become production, does the customer sign again or widen the scope, or does everything stop at the trial.

Preparing a business review is therefore a real FDE skill, not admin to leave to the account manager. You understand the system better than anyone, and you are also the person who can translate it into the language of whoever signs the contract.

A progress report is not a business review

The review is not a status update, nor a technical debugging session. The agenda should revolve around the outcomes the customer has received, not a list of updates.

Nor do you need to tell everything. Pick only 2-3 achievements that show real, measurable business value, rather than presenting every activity of the team.

The simplest test: the review must lead to at least one decision, one commitment or one clear next step. Without any of these, it is just a slideshow.

So preparation starts somewhere else entirely. Before you open a spreadsheet, write one sentence: by the end of the meeting, what do you want the customer to agree to? Every number and every risk on the slides must serve that sentence.

An example: an agent that processes insurance claims

Imagine you have deployed an agent that reads and classifies claims files for an insurance company. The decision you need: the customer agrees to expand from the pilot processing team to the remaining teams next quarter.

Your first draft has p95 latency, tokens per claim and extraction accuracy on the eval set. Those are your numbers, not theirs. What belongs on the slide are the metrics that matter most to the customer’s business, so you switch to average handling time per claim and the rework rate.

Next comes a comparison with last quarter’s baseline to show the trend. Suppose your dashboard shows handling time falling from 32 minutes last quarter to 25 minutes this quarter: a clear story.

Then you ask the customer’s operations lead and discover that their internal report says 29 minutes, because they include the time a claim sits waiting in the queue.

If you put 25 on the slide while the VP holds a sheet that says 29, the whole meeting will revolve around who is right. A single mismatched number is enough to make the customer doubt every other number, and the main story is abandoned. That is why figures must be reconciled across sources before you walk into the room.

The fix is to agree definitions before the meeting, then state clearly on the slide where each metric starts and ends. You might present both numbers, with a line explaining that the gap lies in the queue. That gap could even become a proposal for next quarter.

Every risk needs a mitigation

In the example above, suppose there are two problems you know well: only some of the pilot team use the agent daily, and the agent reads handwritten claims poorly. The instinct is to hide them so the meeting looks better. That is a mistake.

Risks should be raised early, before they threaten the renewal, and each should come with a proposed mitigation. The adoption risk comes with a proposal to run two on-site training sessions.

The handwritten-claims risk comes with a proposal to route that type of claim to a human-review flow while you collect samples to improve it.

When risks are presented this way, the customer sees that you are in control. When they find them on their own, they will wonder what else you are hiding.

The one-page pre-read

Send the pre-read about 48 hours ahead, so the meeting does not spend time re-explaining context. Time together should go to debate and decisions. Here is a template you can use for the claims example:

Section	Content	Example (hypothetical)
Decision needed	One sentence, at the top	Expand to the remaining processing teams next quarter
2-3 outcomes	Customer metrics, compared with last quarter, definitions stated	Handling time per claim, rework rate
Time-to-value	From the start of the engagement to a system that runs and is actually used	Weeks from kickoff until the pilot team uses it daily
Risks	One line per risk, with a mitigation	Low adoption, with on-site training
Next 90 days	Priorities, owners and dates on both sides	Customer names a point of contact for each new team

The time-to-value line is a metric used to assess FDEs: measured from the start of the engagement to a working system that is in use. The words “in use” matter. A system that is deployed but that nobody uses has not yet created value.

End the meeting with commitments from both sides

The last part of the meeting is for agreeing the next 90 days: priorities, owners and dates, for both sides, not just yours. Ideally both sides bring a mutual success plan that records the shared goals, the milestones to measure and the risks.

Close with a joint action plan, and book the next review before anyone stands up.

If the expansion needs the customer to grant access to the new teams’ data, that must be a line with a named person on the customer side and a specific date.

The mistakes that sink a review

One of the most common is putting internal metrics such as latency or eval scores on the main slides, when the audience cares about the cost and time of their own team. Those numbers belong in the appendix, ready for when someone asks.

Then come failing to reconcile the numbers with the customer beforehand, as with the 25 and 29 minutes above, hiding risks, or raising risks without a mitigation. Worst of all is leaving with “let’s discuss further”, which means the meeting settled nothing.

Turning the review into a line on your CV

The claims example is also a template for a strong CV line. Instead of “good communication with customers”, write that you prepared and presented a quarterly review for the customer’s leadership, agreed metric definitions with the operations team, and that the meeting secured expansion to the remaining teams.

In interviews, the story of the 25 and 29 minutes is worth telling in detail. It shows you understand both the data and the people holding the data on the other side of the table.

Exercise: build a 90-day table for your project

Take the project you are working on and draw a four-column table: task, owner, which side, completion date. Write at least three lines for your side and three for the customer’s, each with a real person’s name and a specific date.

If you cannot fill in a customer-side name for a line, that is the first risk to bring to your next review, along with a proposed mitigation.

Next time the account manager asks you to “prepare the technical part”, do not open Jira first. Ask them instead: what do we need the customer to decide?