agentleFS
jacobtop-tcgjacobtop-tcg/sales-engineering-skills/skills/mutual-action-plan/SKILL.md

mutual-action-plan

Skill0 starsChanged 12 days agoMITView on GitHub

Builds and reviews a mutual action plan (mutual close plan) for a B2B software deal, with a named owner, an owner-confirmed date and a sign of completion for every step from evaluation to kickoff. Use when drafting a close plan with a customer, updating one after a slip, or reading one in a deal review to see what buying progress it actually shows.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Start from the customer's buying steps.

    line 19
  2. Distinctive:

    Write a person's name for every customer step, never "procurement" or "legal".

    line 21
  3. Distinctive:

    Treat each customer line as an evidence claim: what do we know, how, who confirmed it, what remains an assumption, and which conversation …

    line 47
  4. Distinctive:

    Ask the owner for a revised date and what the delay changes for the later steps.

    line 57

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Mutual action plan

A mutual action plan, or mutual close plan, sets out the steps customer and seller agree to take, with an owner and a date for each. It runs from the evaluation to a signed contract and the start of implementation. The plan shows buying progress when the customer's people complete the steps they own.

Ask for these inputs

  1. The customer's buying steps as far as they are known, with names where known.
  2. The date the customer needs the result, what they need to achieve by then, and who said so.
  3. Whether a Proof of Value is planned.
  4. For an existing plan: who gave each date and what has been completed.

Steps

  1. Start from the customer's buying steps. Use four columns: the step, its owner by name, the date that owner agrees and what shows the step is done.
  2. Agree the applicable steps and their sequence with the customer. Ask your contact which steps in the example below their company has and who runs each. Include the seller's own decision before the proposal.
  3. Write a person's name for every customer step, never "procurement" or "legal". Where the person is unknown, finding out is the next thing to ask.
  4. Set dates backwards from the date the customer needs the result; the seller's quarter-end is no evidence of the customer's deadline. For each step's length, ask how long it took last time, then check with the step's owner. Legal's own estimate beats your contact's guess.
  5. Put two go or no-go points in the plan. Before the proof: a line owned by the economic buyer, dated before technical validation, where the account executive and sales engineer confirm the outcomes, the timeline and the step after a successful proof. After the proof: the seller's internal decision whether to go to a proposal, which rests on the customer's line before it (whether the people who wrote the success criteria have read the results against them).
  6. Continue past signature: the value presentation and the success criteria become the customer's success plan, so the last lines hand the deal to Customer Success.

Example plan

Replace each role with a person's name, and add the date that person confirms. Both go or no-go lines are dated before the step they gate.

StepOwnerWhat shows it is done
The outcome and the date it mattersCustomer's economic buyerThe economic buyer states both in their own words
Written evaluation criteriaLead technical evaluator, with the business ownerThe customer's own criteria document, with priorities
Go or no-go before the Proof of ValueEconomic buyerEconomic buyer confirms; for a go, outcomes, timeline and next step agreed
Proof of Value against the success criteriaTechnical championResults read against the criteria by the people who wrote them
Seller's go or no-go before the proposalNamed person in the seller's account teamThe team's decision is recorded
Business caseDeal champion, with financeThe case in the customer's own format, with numbers its owners confirmed
Security reviewSecurity review ownerTheir questionnaire completed and findings closed
Legal reviewLegal reviewerLegal reviewer confirms the contract wording is agreed
Procurement and supplier setupProcurement ownerSupplier registered and order form agreed
ApprovalEconomic buyerApproval within their authority, from the people whose agreement they need
SignatureAuthorized signatoryThe signed contract
Kickoff and success plan handoverProject owner, with Customer SuccessProject owner confirms kickoff took place and the success plan was received

Grade the evidence on every customer line

Treat each customer line as an evidence claim: what do we know, how, who confirmed it, what remains an assumption, and which conversation or action could create the missing evidence? Then mark one of three levels:

  • Agreed by the champion: the champion accepted the step on someone else's behalf.
  • Confirmed by its owner: the responsible person confirmed what the step involves, its date and what will show completion.
  • Done: the step happened and the agreed evidence is available.

Where only the champion agreed a step, talk next with its owner. Completing the seller's tasks does not supply that confirmation.

When a step slips

Ask the owner for a revised date and what the delay changes for the later steps. Until that conversation, mark the completion date unconfirmed, and keep the other evidence of the owner's involvement.

Reading the plan in a deal review

Start with the customer's steps. For each line not done, ask who owns it by name, who gave the date and what will show it is done. Mark owner and date unconfirmed until that person confirms them. Then name the next conversation for each open line: for an unconfirmed approval, a meeting asking the economic buyer what they can approve and whose agreement they need; for a security review without a date, a call with the person who runs the review.

Output

The filled plan with an evidence-level column (champion / owner / done) and the next conversation for every open line.

Checks

  • A department name in the owner column means the owner is unknown.
  • A date from the seller's forecast or the contact, without the owner's confirmation, is unconfirmed.
  • A plan ending at signature lacks the handover.

Based on: Mutual action plan template: what it holds and proves

The template as a spreadsheet to fill in: Excel or CSV.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.