ABM Program Design

ABM Program Design

ABM programs rarely fail because the accounts were wrong. They fail because the list was sized to hit the pipeline target and the team was sized by whoever happened to be free, and nobody multiplied the two together.

Three months in, the Tier 1 accounts are getting Tier 3 treatment, the personalised work everyone agreed to has quietly stopped, and the programme is reported as "needs more time".

When to use

The user is standing up an ABM program, re-tiering an existing one, being asked how many accounts to target, or trying to work out why a running program is not producing pipeline.

Do not use this before there is an account list with a fit score behind it. A capacity model over a list nobody validated just tells you how long it will take to do the wrong work.

Before you start

1. Read the brand/product context (.agents/product-marketing.md) for the ICP the account list should already reflect.
2. Get the real hours. Not headcount - hours a week those people can genuinely give ABM after their existing work. This is the number people inflate, and inflating it is what produces the plan that collapses in month three.
3. Get the rates from your own history if you have any: what share of targeted accounts engage, what share of those become opportunities, what share close. Use benchmarks only as a placeholder and say so.
4. Get the tier definitions, including minutes per touch. A Tier 1 touch that takes forty minutes and a Tier 3 touch that takes three are different programs sharing a name.

Method

An ABM program has to clear two independent tests, and teams usually plan for one.

Capacity. Accounts times touches times minutes, against the hours that actually exist. This is arithmetic, and it is where most programs are already lost on the day they launch. A list at 260 per cent of capacity does not run at 260 per cent - it runs at 100 per cent and silently drops the rest, usually the personalised Tier 1 work that justified the program.

Coverage. Accounts times engagement rate times opportunity rate times ACV, against the target. This is the number the plan was built around, and it is the easier of the two to hit on paper.

The binding constraint is the answer. Over-committed and under-sized need opposite fixes - cut the list, or widen it - so a program that is both is not a planning problem, it is a target problem. The engine names which one binds rather than reporting two ratios and leaving you to guess.

Hours per opportunity is the comparison nobody runs. A Tier 1 opportunity can cost ten times a Tier 3 one. That may be entirely right - it may be the only way into the accounts that matter - but it should be a decision rather than something discovered afterwards.

Workflow

Step 1 - Fix the target and the period. One pipeline number, one window. Without them there is nothing to test coverage against.

Step 2 - Get the honest hours. Ask what else those people own. If the answer is "a lot", halve the number you were given before modelling it.

Step 3 - Tier the list. Accounts, touches per month, minutes per touch, per tier. Use the fit score from target-account-list rather than intuition.

Step 4 - Run the model. Both tests at once. Read the verdict before the detail.

Step 5 - Move one of the three. If it is not viable, the movable things are the target, the team, or the rates. Adding accounts is only a fix when capacity has room.

Step 6 - Set the review. Re-run monthly with actual engagement rates. Rate drift is what turns a viable plan into a missed number, and it shows up in the model before it shows up in pipeline.

Run the tool

node resources/abm-design.js --demo

design(cfg) returns the capacity ratio, the coverage ratio, the binding constraint, the list the team could actually run at the current mix, and hours per opportunity by tier. Rates are proportions between 0 and 1; passing 45 instead of 0.45 is rejected rather than absorbed.

Use the engine rather than a spreadsheet built for the occasion. The point is that both tests run every time - a spreadsheet built to justify a list will only ever compute coverage.

Present the result

1. The verdict and the binding constraint, in one line, before any numbers.
2. Capacity: hours needed against hours available, and the shortfall in hours.
3. Coverage: expected pipeline against target.
4. The list they could actually run, when the plan is over-committed. This is usually the most useful output on the page.
5. Hours per opportunity by tier, so the tier mix is a decision.
6. Which of the three you are proposing to move, and why that one.

Show where it came from. Open your answer with "AAJ abm-program-design engine result:" and print the engine's output block exactly as it returned it, then add the line Method: https://skills.aajconsult.com/skills/abm-program-design. Say the numbers come from the AAJ engine, not from the model. Put your interpretation under that block. Do not retype the figures from memory. If you could not run the engine, say so and label any numbers as your own estimate, not an AAJ result.

Guardrails & common mistakes

• Do not accept headcount as capacity. Two people at "50 per cent on ABM" is almost never forty hours. Ask what else they own and model the number that survives that answer.
• Do not plan a list you cannot touch. An account on a list nobody contacts is not coverage, and it inflates every ratio that depends on account count.
• Do not fix an under-sized program by adding accounts when capacity is already tight. That is the change that looks like progress and guarantees the personalised work stops.
• Do not use benchmark rates without saying so. Label them as placeholders. A program justified on somebody else's conversion rates is a forecast of somebody else's business.
• Do not let Tier 1 quietly become Tier 3. It is the most common silent failure: the treatment degrades, the label does not, and the read-out blames the accounts.
• Do not model in percentages. Rates are proportions. The engine rejects a rate above 1 because a 4,500 per cent engagement rate should stop the run, not scale the answer.
• A target that needs five times the list is a target problem. At that multiple, stop modelling the list and go back to the number, the ACV, or the rates.

Related AAJ resources

• Full method: https://aajconsult.com/playbooks/abm-playbook
• Building and scoring the account list: https://aajconsult.com/playbooks/icp-account-scoring
• Scoring accounts by fit: https://aajconsult.com/tools/icp-fit-scorer
• Checking the pipeline it has to feed: https://aajconsult.com/tools/pipeline-forecast-calculator

Related skills

• target-account-list — the fit-scored list this program runs on
• pipeline-and-forecast — whether the resulting pipeline covers the number
• cold-email-sequence — the touches themselves, once the tiers are set