# Client silence after a demo is decided before the meeting ends

> A mutual action plan with dated milestones, named owners on both sides and a technical part written by the FDE does what follow-up emails cannot.

Original: https://fdetimes.net/en/guides/mutual-action-plan-after-demo/

The demo went smoothly. The agent read a logistics company's sample invoices correctly, the head of operations nodded along, and then someone said: "Nice. Let us discuss it internally and get back to you." Two weeks later, the inbox is still empty.

Spend long enough as an FDE and you will have been there. The usual reflex is to send a "just checking in" email, and then another.

But the outcome was usually settled in the last five minutes of the demo. Either you left with a next step that had a date, an owner and a decision-maker, or you left with a promise that bound nobody.

Many people see this as sales work. In practice the FDE is the person the client trusts on the technical side, and the person who knows what data the pilot needs, what access it requires and who in IT has to sign off. So a plan for the next step is only realistic if the FDE writes its technical part.

## Silence usually means there is no plan yet

The tool for this is the mutual action plan (MAP). Rework's guide to MAPs sets three requirements. Every milestone must have a specific calendar date, not "in two weeks" or "as soon as possible".

Every milestone must have a named owner on both the buying and the selling side. And the decision-maker must explicitly confirm that the milestones are achievable.

Calendar dates matter because a milestone without a date drifts, as Sybill, a company that builds tools for sales teams, observes. For the logistics company, "IT will look at it next week" sits in nobody's diary. "On 20 November, the IT engineer approves the data-flow diagram" is a task its owner knows they will be asked about.

The third requirement is the one most often skipped. Agreement from the head of operations is not enough. The person with the authority to say "yes" has to look at the milestones and confirm they are realistic.

## When to bring out the plan without the client feeling pushed

A MAP produced straight after a demo is easily read as a closing tactic, Rework warns. So timing and framing matter as much as content. Sybill advises proposing a plan only once the client has confirmed three things on the call: the problem is worth solving, they know which route the budget will take, and they want to move forward.

Apply that to the invoice demo. The three confirmations might be: the head of operations says manual invoice entry is costing headcount, explains that the spend will go through the chief financial officer, and asks unprompted what the next step is. If any of the three is missing, do not rush to the milestone table; keep asking until it is clear.

These three confirmations also resolve the apparent conflict between that warning and agreeing the next step in the meeting itself: when the client has just said they want to move forward, the milestone table answers their question rather than serving as a closing tactic.

Once all three are in place, present the plan as a technical plan. Do not say "when will you sign". Say "for the pilot to run, we need these things; tell me who on your side can own each one".

## A script for the last five minutes

With the logistics company having confirmed all three, the FDE might say:

> "Let's agree three things before we finish. One: which metric proves the pilot has succeeded, so I can put it in writing.
>
> Two: I need one month of anonymised invoices, and your IT team needs to approve how we connect. Who on your side can handle those two, and by what date?
>
> Three: at the end of the pilot, who decides whether to go ahead, and can we put a meeting with that person in the diary now?"

If the head of operations answers "I'd have to ask my boss", you have learned something important: the person in front of you is not the decision-maker. The next move is to ask for a short meeting with that other person. During the call, sketch the following milestone table and send it within the hour:

| Milestone | Date | Client side | FDE side |
|---|---|---|---|
| Agree written success criteria | 13 Nov | Head of operations | FDE drafts |
| Confirm the timeline is realistic | 16 Nov | Chief financial officer | FDE and account lead |
| Provide sample data, IT approves connection | 20 Nov | IT engineer in charge | FDE sends data-flow diagram |
| Pilot starts (30 days) | 23 Nov | Head of operations | FDE |
| Pilot ends | 22 Dec | Head of operations | FDE sends report against criteria |
| Go/no-go meeting | 23 Dec | Chief financial officer | FDE and account lead |

In a real table, the owner columns carry people's names, not job titles. When a milestone slips, you need to know whom to ask, and that person needs to know the task is theirs.

## A pilot needs an end date

The last row of the table matters most. Echai Ventures, a go-to-market consultancy, argues that a pilot that is to end in a contract rather than a shrug needs four things: written success criteria, a named decision-maker, an end date and a price.

The table above has only the first three. Price is something to agree with the account lead and add to the plan before 23 November, so that the go/no-go meeting does not open a fresh negotiation.

The pilot here runs exactly 30 days, from 23 November to 22 December, following the same consultancy's advice: a 90-day pilot has no urgency left, and is where deals "die".

For an FDE, the limit also helps technically, because it forces you to pick a narrow, measurable workflow, such as one month of invoices, instead of promising to integrate every system.

The 16 November milestone is no accident. A named economic buyer with authority over the budget should be involved from the start of the pilot, and the pilot should end in a formal go/no-go meeting with that same person, according to Stackmatix's guide to turning pilots into contracts.

If the chief financial officer appears only in the last row, the person signing will be hearing about the project for the first time on the day they have to decide.

## The person nodding is not always the decision-maker

In the MEDDPICC framework, the decision process is the sequence of steps, approvals and dates the client goes through to buy, and the economic buyer is the person with the final say on budget. The most enthusiastic person in the demo is often not that person.

Exec's guide to MEDDPICC offers a test for telling a real champion from someone who merely gives you feedback: does this person sell for you when you are not in the room? If you suspect the head of operations will not mention the pilot at the internal meeting, your plan rests on someone who will not push it forward.

There is one more risk: the champion leaves or moves teams midway. Stackmatix advises finding a replacement or escalating to someone more senior, rather than waiting for the newcomer to come to you.

## Keeping momentum after the call

The plan is useful only if it stays current: update it after every call and attach the latest version to every follow-up email. That replaces the "checking in" email with a specific question: "Is IT still on track for 20 November?"

If the client keeps dodging, refusing to put down dates or name owners, read that as a signal. As Rework observes, a client reluctant to commit to the plan is usually not yet ready to commit to the deal.

**Key point:** A client who will not put dates in the plan is usually not planning to buy yet.

When you see that signal, do not push harder. Ask directly what is holding them back. Learning early that a deal will not happen is far cheaper than dragging out a pilot with no end.

## Common mistakes

The first mistake is ending the meeting with "I'll send over some materials", which leaves you with work and the client with none. The second is accepting milestones like "early next month", because milestones like that drift.

The third is building the plan only with the end users, then discovering at the end of the pilot that the person who signs the contract has never heard of it.

The fourth is producing the milestone table too early, before the client has confirmed the problem is worth solving, which makes the whole demo look like a sales pitch. The last is letting the pilot run on indefinitely without a go/no-go meeting.

For your career, this is a skill worth stating plainly on your CV. Rather than "supported demos", describe how you turned demos into pilots with written criteria and a go/no-go meeting.

When interviewing for an FDE role, ask who on the team is responsible for agreeing the next step after a demo; the answer tells you what the company expects of you.

Next time a client says "let us discuss it internally", reply: "Of course. Then let's agree now who will discuss it, and the date I'll follow up with you."

**Try this week:**

- Reopen the follow-up email from your most recent demo. Strike out every phrase like 'as soon as possible' or 'next week' and replace it with a calendar date and a specific person's name.
- Before your next demo, write down three questions to confirm: is the problem worth solving, whose hands does the budget go through, and does the client want to move forward.
- For each client you are working with, ask yourself whether your contact sells for you when you are not there. If not, write down the name of the person you still need to meet.

## Sources

- [Mutual Action Plan (MAP): How to Build One](https://resources.rework.com/libraries/pipeline-management/mutual-action-plan)

- [How to Create a Mutual Action Plan After a Sales Call [2026 Guide]](https://www.sybill.ai/blogs/mutual-action-plan-after-sales-call)

- [They want a pilot before they commit. How do I run one that ends in a contract instead of a shrug?](https://echai.ventures/gtm/gtm-sales-process/they-want-a-pilot-before-they-commit-how-do-i-run-one-that-ends-in-a-contract-instead-of-a-shrug)

- [Enterprise Pilot to Paid Contract: A Startup Conversion Playbook](https://www.stackmatix.com/blog/enterprise-pilot-to-paid-contract)

- [MEDDPICC: The Complete Guide to the Sales Qualification Framework](https://www.exec.com/learn/meddpicc-the-complete-guide)