The Insight Desk

One Deck, Two Audiences: Keep the Buyer and Implementer in the Same Story

Show the buyer why a change is worth considering and the implementation lead what it will require. Keep both focused on the same decision.

Three colleagues review a printed proposal at a table; one points to a recommendation on the page.

Put one decision at the center of the proposal. Show the buyer why the change is worth considering and give the implementation lead a clear view of the work it would require. Keep the requested decision and scope the same in both sections.

State what “yes” means

Name the commitment before you build the slides. State whether you need approval for discovery, a pilot, vendor selection, or a full rollout.

The implementation lead should know what approval covers before reaching the technical detail. Don’t leave them to decode the ask from an appendix.

Give each reader the right detail

Build the proposal around one problem and a specific recommendation. State the decision you need today. Show the buyer the business case and the cost or risk of the proposed step. Show the implementation lead which workflow changes and who owns the work. Name system or data dependencies that could change the plan.

If an open question could change the scope or cost, put it in the main story. Leave specialist detail that cannot change the decision for the appendix.

Let's say a team is considering a shared request system

This is an example, not a client story.

The team copies requests from email into separate spreadsheets. It has trouble tracking each request’s owner and status.

Show the buyer why the team wants to explore a pilot and state that rollout cost is unknown. Show the implementation lead which requests are in scope, who owns intake, and which existing tools would change.

The team asks for a full rollout before estimating cost or running a pilot. It has not agreed what evidence would justify expanding the system.

Start with a smaller decision:

Decision today: Authorize a scoping step for a possible pilot on one request workflow.

Before a pilot: Name an owner and estimate the pilot cost. Agree what evidence would justify a wider rollout.

Scoping takes staff time. Name the lead and effort for that work on the slide. State the expected benefit as a question for the pilot. Report results after the team measures them.

Example proposal slide labeled 'EXAMPLE: NOT CLIENT WORK' asks whether to authorize a scoping step for a possible pilot on one request workflow, with buyer questions about cost and risk beside implementation questions about workflow and ownership.

Keep the versions consistent

Keep the buyer summary short and put workflow detail in the implementation section. State the same ask and scope in both. Before the meeting, show both readers the decision slide and ask what approval covers. If they give different answers, revise the deck before you present.

If the audience’s role is unclear, start with Why Good Presenters Still Bury the Ask.