When a Buyer Asks for an Implementation Plan Before Signing

Send the buyer a proposed implementation plan they can review and share. Show the work, who needs to take part and what has to happen before a date can be confirmed. If a dependency is still unknown, put it beside the step it affects.

A buyer may need this before they can recommend a purchase internally. Asking them to sign first can leave the practical question unanswered: “Who on our team will have to do what?” You can help with that question without promising a launch date your delivery colleague hasn't agreed to.

Find out what the buyer needs the plan to settle

Start with the reason for the request. Is the buyer checking whether their administrator has enough time? Do they need to explain the rollout to a team lead? Are they working backward from an event that already has a fixed date?

Those uses call for different detail. A manager checking workload needs the buyer's tasks and likely participants. Someone preparing a recommendation may need to see the order of work and the questions still open. A person asking whether a particular deadline is possible needs the relevant delivery colleague to check it.

You could ask: “What does this plan need to help your team decide, and who will be reading it?” If the answer is already in the buyer's email, use it. Don't make another meeting a condition of sending a useful first version.

This follows the same principle as a quote request before discovery: give the information you can accurately provide, then ask for the missing details that would change it.

A worked example: start with the first team, not the whole rollout

Consider this fictional request from a buyer evaluating a workflow tool:

“Could you send an implementation plan? We'd like the support team using it on December 1. I need to show our operations manager what we'd be taking on.”

The seller knows that the buyer wants one team to handle incoming requests. They haven't agreed which requests belong in the first rollout, whether historical records need to be moved or who will administer the setup. The seller's delivery colleague hasn't checked availability.

“Implementation takes two weeks” wouldn't answer those gaps. It would give the buyer a duration to repeat without explaining the work behind it. Send a smaller plan that they and the delivery colleague can correct.

Choose the first workflow

Proposed work: walk through one ordinary incoming request, from arrival to assignment and follow-up. Identify the first team and the cases they will handle.

People needed: the buyer's operations manager and someone who does the work, with the seller's delivery colleague.

Open question: does the first rollout include only new requests, or must it also cover older open requests? The answer changes the setup and checking work.

Ready to move on when: both sides can describe the first workflow and what will be left for later. A description of the buyer's requirement still needs a separate check that the proposed product and setup can meet it.

Check the setup and access work

Proposed work: identify the system administrator, the required configuration and any access decisions needed for that first workflow.

People needed: the administrator who can assess the buyer's setup and the delivery colleague who can explain the supported procedure.

Open question: who can approve and perform the buyer's access work, and when are they available? Listing an administrator's name doesn't mean that person has accepted the task.

Ready to move on when: the responsible people have checked the procedure, confirmed their part and named anything that needs a separate review. The sales plan should point to the agreed access process; it shouldn't ask the buyer to email passwords or grant broad access to speed things up.

Try one request before inviting the whole team

Proposed work: use an agreed example to check assignment and follow-up in the intended setup. Arrange suitable example data through the buyer's normal process.

People needed: a team lead and a person who will use the workflow, with delivery support as agreed.

Open question: what result would let the team proceed, and who decides? “Training complete” doesn't tell you whether the intended work can be done.

Ready to move on when: the named reviewer has checked the result and agreed whether to proceed, fix something or reduce the first rollout. A calendar invitation for this check is a plan to review the work, not evidence that it passed.

Use dates that tell the reader what is actually agreed

Keep December 1 in the document as the buyer's requested start date. Put the current answer beside it: feasibility still to be checked with the administrator and delivery colleague.

Then give the next check its own date, if someone has agreed to it. For example: “Delivery colleague to review this outline by November 12.” That promise belongs to the person who accepted the review; it doesn't confirm the later launch.

A plan can also show the order of work without assigning a day to every step. “After the first workflow is agreed, check the configuration and access tasks” is more useful than filling a calendar with dates nobody has accepted.

If you include estimated effort, say which task it describes, whose time it uses and what the estimate depends on. Leave it open when you don't have an informed estimate. Write ‘effort not yet estimated’ and name who will check it. That gives the buyer a useful next step while the workload is still unknown.

A reply the buyer can forward

For the fictional request above, a first reply could read:

“I've attached a proposed plan for the support team's first workflow. It shows the tasks we'd need to check together and the people likely to be involved.

December 1 is your requested start date. We haven't confirmed that date yet. The two things that could change the plan most are whether older open requests need to be included and when your administrator can take part.

Would you mark up those two points and tell me who should review your team’s tasks? I'll ask our delivery colleague to review the setup work and availability before we turn the outline into an agreed schedule.

If your operations manager needs a different level of detail for the recommendation, let me know what they need to decide.”

The buyer can forward that reply with the plan and retain the distinction between their target date and the open scheduling question. They also have a specific way to correct it.

Change the affected step when a dependency moves

Suppose the buyer replies that their administrator is unavailable until December 4. Update the access step and the requested start date discussion. Don't leave December 1 at the top of the plan while hoping the reader notices the new note farther down.

A useful update would say: “The administrator can't join before December 4. Setup requiring their participation therefore remains unscheduled. We need to reassess the requested December 1 start, or identify a smaller first step that the responsible people confirm can happen independently.”

That smaller step might be a requirements review. It would need its own agreed purpose and participants; it shouldn't be relabeled as the launch. Ask the buyer whether it would help, then check that your colleague can support it.

If you already sent an inaccurate commitment, correct the original message directly. A revised attachment alone may leave the buyer working from the earlier version.

Keep a reusable plan note

Download the blank implementation-plan note and fill it with the buyer’s own scope, participants and open questions.

Use the following fields for each meaningful step. Keep the blank version separate from your filled example so a colleague doesn't accidentally carry fictional names or dates into a buyer's document.

• Plan purpose: the decision this outline should help the buyer make.
• First workflow and scope: the team, work and starting point included; important work being left for later.
• Step and expected result: what will be done and what someone should be able to check afterward.
• Buyer participant: the role needed, whether a person has been identified and whether they've accepted the task.
• Seller participant: the colleague needed and what they've agreed to review or deliver.
• Dependency or open question: what must be settled before the step can be scheduled or completed.
• Date: requested, proposed, estimated or confirmed, with the person responsible for checking it.
• Next check: who will reply, about what and by when, if agreed.

Before sending, ask the people responsible for delivery to review the tasks attributed to them. Let them change the scope or say what still needs investigation. If answering the buyer requires a larger piece of design work, explain what you can send now and what would need a separate discussion.

The outline has done its job when the buyer can see the work clearly enough to question it and the delivery colleague can see what remains to be agreed. Acceptance of the outline is one decision. A purchase, an agreed delivery schedule and a successfully completed rollout each need their own confirmation.