Blog

How to build a strategic account plan, step by step

A strategic account plan is a longer-range plan for an account that could be worth a lot to you: the kind where several teams are involved, the deal takes months, and one good conversation will not close it. It differs from a call plan, which covers the next meeting, and from a territory list, which ranks many accounts. It answers a harder question: over the next two or three quarters, how do we become a vendor this company trusts?

This article shows how to build one in six steps for an account that sells to or through engineering teams. If you want a copyable outline first, use the account plan template. This article explains how to think while you fill it in.

Step 1: Choose which accounts deserve a strategic plan

You can't write a strategic plan for 300 accounts, and you shouldn't. Rank your territory first, then write a full plan for the top handful, a short plan for the next tier, and only a watch note for the rest. Two tests help:

  • Fit. Does the account match who you sell to, with evidence from its own pages, job posts or engineering writing?
  • Reach. Can you name at least one person near the problem, and does the account have a reason to move this year?

An account that passes both is worth the hours. One that fits but shows no reason to move belongs on the watch list.

Step 2: Learn what the company is trying to do

A strategic plan starts with the customer's goals, not your product. Look in the places where a company states its goals in public:

  • Annual reports and filings, if the company is public, for stated priorities and risks.
  • Engineering blog posts and conference talks, for what the technical teams are building or fixing.
  • Job posts, for the roles it is adding and the work those roles own.

Write down three goals in the company's words, each with a source and date. Then write one sentence on how each goal touches the problem you solve. If one doesn't touch it, drop it. The method for researching a technical account covers where to find each source.

Step 3: Map the stakeholders

In a technical deal many people take part: the people who feel the problem, the team owner, those who review security or architecture, and whoever controls the budget. Stakeholder mapping means writing down who they are, what each one cares about, and how well you know them. Use a simple table:

Person or roleTheir part in the dealWhat they care aboutYour contact so far
Staff reliability engineerFeels the problemFewer pages that nobody acts onNone yet
Director of platform engineeringOwns the team's toolsWhat a new tool replacesNone yet
Security reviewer (name unknown)Can block a trialWhere data goesAsk who it is

Confirm every name against a recent source, and write the date you checked. The article on finding the right person at a large company shows how.

Step 4: Find where you fit

Compare what the company is trying to do (step 2) with what it already runs. If you don't know what it runs, find out what tools it uses first. You are looking for three kinds of opening:

  • A goal with no clear tool behind it.
  • A tool that is being replaced or moved, shown by a migration post or a related hire.
  • A team with a problem that your product solves and that other teams in the company share.

Be honest about blockers too: a stack you don't support, a review you can't pass, a competitor with a strong footing. A plan that lists only openings is optimism, not strategy.

Step 5: Set objectives and actions

State what success looks like in stages, and tie each stage to an action, a person and a date:

  1. Learn. Get one conversation with someone near the problem. Action: a note about their talk, sent by Friday.
  2. Test. Agree on a small trial with one team. Action: ask who reviews new tools before the trial.
  3. Expand. Bring in the reviewer and the team owner. Action: a short brief for the next call.

Keep each stage small enough that you know what to do this week. If the plan is vague about this week, it isn't finished.

Step 6: Review on a schedule

Strategic plans go stale. Pick a rhythm, such as every two weeks for your top accounts, and on each review check three things: whether a why-now line has aged out, whether a person has moved, and whether the last contact changed the plan. Update the plan first, then log what happened. A plan nobody reviews is a document, not a plan.

Common mistakes

  • Writing a company profile. A page of facts about the company with no actions is research, not a plan.
  • Stating guesses as facts. Mark every inference as a guess. It tells you what to ask.
  • Planning around one contact. If that person leaves or goes quiet, you have nothing. Map more than one.
  • Skipping the blockers. They show up late and cost you the quarter.

Where Repclose fits

Repclose helps with steps 1 to 4. You upload your accounts and a sales profile, and it ranks them. For the top-ranked accounts only (the top 10 by default), it lists about 10 people, gives the top 5 a profile check, and writes a short card on why they might care. The plan shows why now, green flags and supporting sources, each point linked to its source with the publication date where one is available. Steps 5 and 6 are yours: you set the objectives, add notes, and decide what to do next.

See a finished plan in the sample brief, or start with your first 5 plans free. For the longer picture, read about account planning and research with Repclose.