Published
A proven account play often lives in an experienced seller's judgment, leaving the rest of the team to improvise the checks, evidence, and approval points that make it work. Turning that tacit method into a reusable operating procedure is the challenge.
That is what this guide is for.
A strong account-based sales process becomes reusable when another seller can follow the same checks, use the same kinds of evidence, stop at the same approval points, and produce the same decision-ready output on a different account.
That is a stricter standard than saving a prompt.
A prompt can request an account map. A reusable AI Skill also needs to say which account record to use, which roles matter, how to reconcile public and CRM data, how to label an inferred reporting line, when to stop because ownership is unclear, what the seller must approve, and what the finished account map must contain.
Amplemarket Skills are reusable instructions for sales and GTM tasks. A compatible AI client such as ChatGPT or Claude follows the instructions and can use Amplemarket MCP to retrieve authorized Amplemarket data and call supported tools.
This article focuses on how a revenue team turns one working account-based sales method into a shared, testable procedure: the Skills Library owns the catalog of available Skills; the Amplemarket MCP guide owns connection basics; and the practical account-based MCP guide shows how to run an individual account play.
Why is a strong account-based sales process difficult to repeat across a team?
The best account plays often depend on decisions that experienced sellers make without writing them down:
- whether a title represents a buyer, an influencer, or an irrelevant adjacent role;
- whether an account-level signal is recent and specific enough to investigate;
- whether CRM ownership, an open opportunity, customer status, or an exclusion should stop outreach;
- whether a missing contact represents real whitespace or incomplete data;
- which facts can support a message and which claims are only hypotheses;
- when another stakeholder would improve the buying conversation instead of creating noise.
When the method stays in one rep's memory, the team cannot inspect it, test it, or improve it. When it is reduced to a short prompt, the AI client has to fill in the missing rules.
Two reps can then run apparently similar requests and receive outputs built from different sources, assumptions, or approval standards.
The purpose of a reusable Skill is not to make every seller sound the same. It is to make the underlying checks consistent while leaving the account thesis, relationship judgment, and buyer conversation with the seller.
How are a prompt, an AI Skill, MCP, and a platform Workflow different?
These components solve different parts of the problem. Treating them as interchangeable creates unreliable automation.
A Skill is usually the right layer when the job is repeated but still needs reasoning and review. A platform Workflow is usually the better layer when the condition and action are stable enough to configure directly. A prompt is enough when the task is genuinely one-off.
Amplemarket's current Workflow Recipes show the configured trigger-and-action patterns available in the platform. That page, rather than a team Skill, is the source of truth for supported Workflow triggers and actions.
What should every reusable account-based sales Skill define?
The procedure should answer the following questions in plain language before it is shared with a team.
This is not a proprietary scoring model. It is the minimum information needed to make any team procedure inspectable.
A useful test is to remove the author from the room. If another rep cannot tell what evidence to retrieve, how to handle a conflict, or where to stop, the process is not ready to become a shared Skill.
Which account-based sales process should a team standardize first?
Choose one process that occurs often, has a visible decision or artifact, and can be checked by an experienced account owner. Do not start with the process that sounds most ambitious. Start where the team can identify incorrect inputs, incomplete evidence, unsafe actions, and a better final result.
Three candidates make the tradeoffs clear:
- Buying-group mapping: is useful when incomplete stakeholder coverage creates deal risk. The process is a good first Skill only if the team can define the decision roles and label inferred relationships. The buying-committee and multithreading guide owns the execution method.
- Signal review: is useful when teams lose time deciding whether a new event merits action. The process is a good first Skill only if the source, event date, account identity, CRM state, and stop conditions remain visible. The post-signal account-play guide owns the individual plays.
- Account-expansion review: is useful when account teams need to distinguish a defensible adjacent use case from incomplete CRM coverage. It is a good first Skill only when the account owner can correct relationship history and approve the next move. The account-expansion guide owns the procedure.
This page owns the standardization decision: how to choose, document, test, version, and maintain the method. The task-specific guides and individual Skill pages own the execution steps.
How can RevOps turn a seller's working method into a team Skill?
The conversion is an operating-design exercise. The writing comes after the team understands the decision.
Which account decision should the first Skill improve?
Choose one repeated decision with a visible failure mode. "Improve account-based selling" is too broad. Better starting points include:
- identify missing buying roles before a deal review;
- prepare a source-aware brief before an executive meeting;
- decide whether a recent public signal merits account action; or
- find plausible expansion contacts without colliding with the existing account team.
Write down the user, the moment of use, the output, and the decision that follows. If the result does not have a clear consumer or next decision, do not automate it yet.
How should the team capture the current human method?
Observe a seller who performs the task well. Ask them to work through a real, approved account and explain:
- which record they trust first;
- what they check when public and CRM data disagree;
- which title or relationship clues change their interpretation;
- which conditions make them stop;
- what they would never send or change without approval;
- what a manager needs to see in the finished output.
Capture exceptions, not only the happy path. A procedure tested only on a clean account will fail on duplicates, job changes, subsidiaries, shared ownership, active opportunities, and incomplete CRM history.
How should facts, inferences, and company policy be separated?
Every material field should fall into one of four states:
- Verified: supported by a current structured record or cited source.
- User-provided: supplied by the account owner and attributed as such.
- Inferred: a reasoned conclusion that still needs human confirmation.
- Unknown: not available or not reliable enough to use.
Company policy is different from all four. An exclusion rule, territory rule, approval requirement, or definition of a qualified account should be supplied by the organization.
The AI client should not infer policy from previous outputs.
Which data and actions should the Skill be allowed to use?
List the systems, objects, and actions separately. "Use the CRM" is not specific enough.
For a buying-group Skill, read access may include account identity, contacts, ownership, opportunity stage, previous outreach, and exclusions. Write access may be unnecessary. For a signal-to-outreach Skill, the procedure may prepare a draft or a list but require the seller to approve enrollment or launch.
Amplemarket MCP uses individual authentication and operates within the connected user's Amplemarket permissions. Current documentation covers people and company search, enrichment, accounts, contacts, exclusions, lead lists, engagement state, supported sequence work, Unibox and outbox inspection, and analytics.
Available tools can change, so the maintained Skill should link to the current MCP documentation rather than copy a permanent tool inventory into its instructions.
Where should the Skill stop for human review?
Place the checkpoint before an action that changes external or shared state, not after it.
Common checkpoints include:
- choosing which inferred stakeholders belong in the buying group;
- spending enrichment credits;
- creating or materially changing a shared list;
- preparing buyer-facing claims from a public event;
- enrolling a person in a sequence;
- changing a CRM field, owner, stage, or suppression state;
- launching outreach.
A checkpoint must name the person or role that approves the action and show the evidence needed for that decision. "Ask for confirmation" is weak if the user cannot see what will change.
What should a reusable Skill return?
Design the result around the next decision. A team account map might require:
- resolved company name, domain, and account ID;
- current owner, customer status, and open-opportunity state;
- stakeholders grouped by required buying role;
- source and freshness for each material fact;
- known, inferred, and unknown labels;
- prior engagement and relationship state;
- gaps and the evidence behind them;
- conflicts that require resolution;
- proposed next actions, separated from completed actions.
Do not ask the model for a "comprehensive report" and leave the structure open. A stable output is what lets managers compare runs, spot omissions, and improve the instructions.
How should the team test and publish the Skill?
Use a fixed set of known accounts that includes difficult cases. Run the same instructions with the same available data, permissions, and evaluation criteria. Ask account owners to record material errors, missing checks, unnecessary steps, and corrections.
Publish the Skill only after the procedure consistently:
- resolves the intended account and person records;
- checks required private state before recommending action;
- labels unknowns and inferences;
- observes its action and approval boundaries;
- returns the required fields;
- fails visibly when a required source or permission is unavailable.
The production copy should have an owner, version, review date, client compatibility, required connectors, and change log. Distribution and version-control options depend on the AI client and the organization's own operating setup; this article does not assume that Amplemarket centrally administers custom team Skills.
The following plain-text template is a practical starting point:
Task:
Use this procedure when:
Do not use it when:
Required user inputs:
Required data:
Allowed tools and actions:
Resolve identity by:
If sources conflict:
Mark as inferred when:
Mark as unknown when:
Stop and ask when:
Return:
Human approval required before:
Record after approval:
Quality checks:
Owner:
Version:
Review date:
How should a team standardize a Skill without copying the task instructions?
Do not reproduce the full buying-group, signal-review, or expansion procedure inside the team-standardization Skill. The task-specific guide or published Skill should own the execution steps.
The shared standard should define the controls that must remain consistent across those tasks.
This boundary prevents three pages from answering the same query with slightly different wording.
The task owner explains how to perform the work. This page explains how a revenue team makes that work repeatable: assign an owner, freeze required inputs and source rules, define the approval boundary, test difficult cases, publish a version, and review errors over time.
Amplemarket MCP can supply permission-scoped search, enrichment, account, engagement, list, supported sequence, and analytics tools where the chosen Skill needs them.
The AI client coordinates the procedure, the CRM contributes authorized relationship and opportunity context when connected, and the seller or account owner makes the commercial decision.
How should a revenue team measure whether a Skill is reliable?
Measure process quality before attributing pipeline.
Useful first measures include:
- Completion rate: Did the Skill return every required section?
- Record-match accuracy: Did it select the correct company and current person records?
- Required-source use: Did it check CRM ownership, opportunity state, exclusions, or other required private context?
- Unknown disclosure: Did it mark missing information rather than inventing a value?
- Seller correction rate: How many material fields or recommendations did the account owner change?
- Approval compliance: Did it stop before every controlled action?
- Time to usable output: How long did a seller need to reach a decision-ready artifact, including corrections?
- Accepted recommendation rate: Which proposed gaps or next steps did account owners accept?
- Operational conflict rate: Did the procedure cause duplicate records, owner collisions, or conflicting touches?
After the process is stable, connect it to the outcome the play was designed to influence: verified buying-role coverage, multi-threaded meetings, time from signal to reviewed action, opportunity progression, or accepted expansion hypotheses.
Do not claim the Skill caused pipeline unless the measurement design can separate the Skill from account selection, rep skill, seasonality, offer, message, and other changes.
The public Amplemarket customer page includes qualitative feedback about MCP and Skills, including Connor Grant of Browserbase:
"MCP is sick, and the Skills put it over the top."
That comment indicates user sentiment; it is not a controlled measure of revenue impact.
Who should own a reusable AI Skill for the sales team?
Shared ownership usually creates unclear ownership. Give each responsibility to a named role:
- Sales leader: chooses the account decision and defines the commercial standard.
- Experienced seller or manager: explains the working method and validates whether the output is usable.
- RevOps: defines data sources, CRM state, ownership, exclusions, permissions, approval rules, and measurement.
- GTM Engineering or AI operations: validates client behavior, tool availability, error handling, logs, credits, and connector dependencies.
- Enablement: maintains instructions, examples, rollout material, version history, and field feedback.
- Account owner: corrects account-specific inferences and approves the commercial action.
The Skill itself should have one accountable maintainer. That person does not need to own every policy, but they must know who can approve a change and when the procedure needs review.
When should a team use a prompt, a Skill, a Workflow, or no automation?
Use a prompt when the task is one-off, low risk, and does not need a stable output or repeatable checks.
Use a Skill when the job recurs across sellers or accounts, requires several data and reasoning steps, benefits from a consistent output, and still needs human judgment.
Use an Amplemarket Workflow when a known event should trigger a configured action or routing rule inside the platform and the decision can be expressed reliably in those conditions.
Use no automation when the source data cannot support the decision, policy is unresolved, the relationship is unusually sensitive, or the cost of an incorrect action is higher than the benefit of repeatability.
Some motions need both a Skill and a Workflow. A Skill can research an account, surface conflicts, and prepare a recommendation for review. After approval, a configured Workflow can handle a stable operational step. The handoff should be explicit so the AI client does not quietly turn a recommendation into an action.
When are Amplemarket Skills not the right approach?
Amplemarket Skills are not the right answer when:
- the task occurs rarely and a clear prompt is sufficient;
- the team has not agreed on the underlying account-based sales process;
- the required account or CRM context is unavailable, stale, or inaccessible to the user;
- the chosen AI client cannot use the required Skill or MCP connection;
- the organization needs centralized controls that its current AI-client deployment does not provide;
- the task requires a specialist system such as parallel-dialing coaching, full revenue forecasting, or conversation intelligence;
- policy or regulation requires a review process that has not been implemented; or
- the team wants autonomous buyer-facing action where the documented tool or company policy still requires a person to approve it.
A reusable procedure makes weak assumptions easier to see; it does not repair them automatically. If the team cannot define the buyer, account owner, approved source, or stop condition, fix that operating decision before encoding it in a Skill.
Research and disclosure
Sources: Official product documentation and product pages checked for this article. Public customer, pricing, and review evidence is used only when the named source is linked.
Check date: July 28, 2026.
Disclosure: Amplemarket publishes this article and competes in the sales technology categories discussed.
Not verified (NV): A capability or claim is marked NV when it could not be confirmed in a current public source. NV does not mean the capability is absent and is not scored as zero.
