The Decision Receipt: A 5-Minute Habit That Prevents Client Call Confusion

A client says, “Yes, let’s go with the simpler version,” near the end of a call. Everyone sounds aligned. Three days later, the client expects a different version of “simple,” your teammate starts the wrong task, and the project has acquired a revision no one planned for.

The problem is not that people are careless. Spoken decisions are compressed: they carry context, tone, alternatives that were rejected, and assumptions about who will act next. Once the call ends, each person expands that short sentence differently.

A decision receipt is a brief written recap sent immediately after a call or meeting. It records what was decided, what that decision means in practical terms, and what happens next. It is not a meeting transcript, a stiff legal document, or another long status email. Its job is to make one decision easy to find and hard to misremember.

Good client communication does not merely document that a conversation happened. It turns a vague moment of agreement into a workable instruction.

Why a decision receipt works when meeting notes do not

Traditional meeting notes often try to preserve everything: discussion points, attendees, open questions, and background. They can be useful, but they are easy to postpone writing and difficult to scan later. A decision receipt has a narrower purpose. It answers, “What now counts as the plan?”

That distinction matters most when a choice affects cost, timing, scope, responsibility, or the work already underway. A simple written recap creates a shared reference point before the project team invests more effort.

It also gives the client a low-pressure chance to correct a misunderstanding. “That is not what I meant” is much easier to say an hour after a call than after a draft, invoice, or missed launch date makes the misunderstanding feel expensive.

Use it for decisions, not every conversation

Send a receipt when the conversation produces a choice someone will need to act on. Typical triggers include:

You do not need one after a casual check-in or a call that ends only with “we’ll think about it.” In those cases, write an open-question note instead. Calling an unresolved idea a decision creates false certainty.

The four lines that make up a useful receipt

Keep the format predictable. A recipient should be able to read it on a phone and understand the project’s direction without reopening the whole conversation.

  1. Decision. State the choice in plain language. Begin with “We agreed to…” or “The selected approach is…”
  2. Boundary. Say what is included, excluded, delayed, or unchanged because of that choice.
  3. Next owner and action. Name who will do what. Avoid passive wording such as “the materials will be sent.”
  4. Correction window. Invite a prompt correction if your recap is off, without demanding ceremonial approval for routine matters.

Here is a compact example:

Subject: Decision recap — homepage draft
We agreed to lead the homepage with the service overview rather than the founder story.
This means the founder-story section moves to the About page; the existing photography stays in the first draft.
Our team will revise the wireframe by Thursday. Jordan will send the final service descriptions before then.
If I have captured this differently from your intent, please reply with the correction before we begin the revision.

The receipt does not try to prove who was right in every detail. It makes the operational consequence unmistakable: what moves, what stays, and what each side does next.

Write the operational meaning, not just the label

Many project disagreements begin with labels that seem clear but are not. “Keep it simple,” “make it more premium,” “use the standard package,” and “prioritize the launch” may all conceal several possible actions.

When you write the receipt, translate the label into observable work. If a client chooses the “simple” option, explain whether that means fewer pages, one review round, a reduced feature set, or a shorter production schedule. If none of those details were settled, say so and list them as open questions.

A quick clarity check before sending

Read your draft and ask four questions:

If the answer to the last question is uncertain, use the client’s own plain wording once, then define it. For example: “You chose the ‘lighter’ visual direction: more white space, fewer decorative elements, and no additional illustration work in this phase.”

Make the reply request proportionate

One common mistake is ending every recap with “Please confirm.” That can turn routine communication into a chain of approvals, slow work, and train clients to ignore messages that appear to require a response.

Match the request to the consequence. For a small sequencing choice, an invitation to correct is enough. For a significant scope or deadline change, ask for explicit confirmation before acting. The receipt format remains the same; only the final line changes.

Choose the response request based on what the decision changes
Type of decision Appropriate closing line Why
Minor working detail “Reply if I missed anything.” Keeps work moving while allowing a correction.
New dependency or handoff “Please let me know if the named owner or date needs to change.” Checks the practical commitment without creating needless formality.
Material change to scope, budget, or delivery timing “Please confirm this revised plan before we proceed.” Prevents work from starting on an assumption with larger consequences.

If your business uses contracts, change orders, or a formal approval system, a decision receipt should support that process rather than replace it. It is a working communication tool, not a substitute for documents your agreement requires.

Give each receipt a home your team can actually use

A beautifully written recap is still weak if it disappears into an inbox. Choose one consistent place for the working record: the project-management task, the client folder, the shared project channel, or a designated section of the project brief.

Store the sent text or a link to the message beside the task it affects. Then add the decision date and a short label, such as “Homepage priority — service overview.” The label should describe the choice, not the meeting: “Tuesday call notes” is hard to retrieve when the question arises weeks later.

For a small team, this also reduces dependence on the person who attended the call. The designer, coordinator, or contractor can see the current direction and the reason for it without asking someone to reconstruct a conversation from memory.

Three ways the habit goes wrong

Turning the receipt into a transcript

Long recaps bury the decision in conversational detail. Keep background only when it explains an important constraint. If the client considered five options but selected one, record the selected option and the relevant tradeoff, not every comment made along the way.

Softening the language until nothing is decided

“We may look at potentially using…” is appropriate for an idea, not a settled choice. Use decisive verbs when a decision was made. If it was not made, say: “Still open: whether the second page is included in this phase.”

Sending it too late

A recap sent after the team has already built the next draft can feel like retroactive paperwork. Send it while the conversation is fresh and before the choice starts generating work. Five minutes after the call is usually more valuable than a polished summary the next day.

A realistic project example

Imagine a bookkeeping firm is preparing a new client welcome packet. On a call, the client asks to “make onboarding less overwhelming.” The project lead hears “shorten the packet.” The writer hears “use friendlier language.” Both are plausible, and both could lead to avoidable work.

A decision receipt can separate the two: “We agreed to reduce the first-send packet to the three forms required to begin service. The remaining reference materials will be provided after setup. We will retain the existing plain-language tone; rewriting the full guide is not part of this revision.”

Now the team knows that the decision changes sequence and volume, not necessarily copy style. If the client wanted a tone change too, the correction is easy and timely.

Start with the next consequential call

Create a reusable draft with four headings: Decision, Boundary, Next action, and Correction or confirmation. Keep it where you can open it during a call. When a client makes a choice that changes someone’s work, fill in those four lines and send them before moving to your next task.

The first goal is not perfect documentation. It is a shared, findable answer to a simple question: What did we decide, and what does that mean now?