The ABM loop: how I build an account-based GTM system

Picture a founder checking Monday's account alerts. Someone has completed the website grader, explored a benchmark and asked for a report. An email draft is waiting.

The same company already has an open opportunity. Another colleague owns the relationship. The assessment uncovered an implementation problem, while the draft offers a generic introduction.

This is an illustrative scenario. It shows the coordination problem I design the system around. Collecting more signals would leave the team with more alerts and the same missing context.

My ABM system turns account evidence into a useful next action, then uses the outcome to improve the next decision.

Account-based marketing starts with the companies we choose to serve. The work continues through the people involved, their buying decisions and the value they get after signing.

I use 6 steps inside the DECODE, SHAPE, AMPLIFY and EVOLVE framework. These are an ABM application of the framework, rather than a replacement for its 12 levers.

Explore the ABM workflow

Follow the connectors from customer evidence to the next cycle. Open a step for its inputs, decisions and output. The signal example is an editable demonstration, not a forecast of conversion.

1. DECODE: define the ICP and buyer personas, analyse existing accounts and find more suitable companies.
2. DECODE → SHAPE: combine account research, lead enrichment and CRM cleanup in one repeatable process.
3. SHAPE: capture signals, including interactions with tools you build yourself, and qualify the account.
4. SHAPE: assess connection strength and awareness without confusing activity with buying progress.
5. AMPLIFY: choose the useful demand-generation or outreach action, with a clear owner.
6. EVOLVE: review progress, customer outcomes and the rules that should change.

The shared context sits across the whole loop. It holds the approved ICP, positioning, messaging, proof and playbooks. The CRM holds the current account state. People and agents need access to both.

1. DECODE: analyse the customers you have, then find more

I start with the accounts we can learn from. That includes customers who renew, customers who expand, customers who struggle and deals we lose.

The largest closed-won deal can be a poor model for the next one. I want to understand the conditions under which the customer gets value and we can serve them well.

Build an ICP from evidence

I compare accounts by the problem they bought us to solve, their use case, adoption, buying process and commercial outcome. Company size, region and technology help describe the pattern. They do not explain it on their own.

When the CRM cannot explain a pattern, I talk to customers. I also involve account executives, customer success and the people delivering the work.

The questions are practical. What happened before the customer started looking? Which alternative did they consider? Who made the change possible? What nearly stopped it? What happened after implementation?

I turn that into a written ideal customer profile, or ICP, with 4 parts:

• Problem fit: the conditions under which our offer is useful.
• Observable criteria: characteristics research can actually verify.
• Exclusions: accounts we deliberately avoid or serve only through another motion.
• Open questions: assumptions that still need discovery.

An agent should be able to explain why an account qualifies and show its evidence. When evidence is missing, the answer is unknown. That is a research queue, not an automatic rejection.

I describe the starting discipline in how I define the ICP before researching leads.

Define buyer personas through the decision

A buyer persona earns its place when it changes the research, message or next action.

I map the person living with the problem, a potential champion, the budget owner and the people evaluating risk. One person can play several roles. A senior title alone proves none of them.

The account map records the role, what matters to that person, the relationship owner and what we still need to learn. It should help a rep prepare a conversation, rather than fill a slide with fictional demographics.

Expand the account list deliberately

I compare the current CRM with the ICP before buying another list. Existing customers, past opportunities, partner relationships and former champions provide a starting set.

Then I look for gaps. General databases help find companies and people. Lookalike research can expose adjacent companies. Industry directories and specialist sources can cover a niche that broad filters miss.

Apollo, LinkedIn Sales Navigator, ZoomInfo, Ocean.io, Discolike and AI Ark are examples to evaluate for those jobs. Apify or a research workflow can help with permitted public sources. None removes the need to check the result against the ICP.

I record source provenance, normalise domains and review duplicate entities. A parent company and a subsidiary may share a brand while buying separately.

The output is a target-account list with reasons, exclusions and uncertainty. I expand coverage when it produces useful accounts at an acceptable cost.

2. DECODE → SHAPE: combine enrichment, research and CRM cleanup

I build one enrichment process that can handle the existing CRM and new records. Separate one-off spreadsheets would give us two standards to maintain.

The first job is to define the account model. HubSpot, Salesforce, Attio and Pipedrive can occupy the CRM position in the workflow. I adapt the model to the relationships, fields and automation available in the chosen setup.

Research towards a decision

For every research field, I want to know what someone will do differently when it is filled.

Company structure may affect account ownership. Technology may affect compatibility. A recent leadership change may justify fresh discovery. A contact's responsibilities may change the opening message.

I separate company facts, contact facts and research interpretations. A job advert is evidence of hiring. The operational problem behind that hiring is a hypothesis.

Information	What I preserve	How it helps
Account identity	Stable account ID, domain, aliases, parent and subsidiary links	Match activity to the right entity
Account fit	Criteria, supporting evidence, unknowns and model version	Explain qualification and tier
Buying group	Contact, role, relationship owner and verification date	Prepare the right conversation
Research	Finding, source URL, checked date and uncertainty	Let a person inspect the reasoning
Commercial state	Customer status, open opportunity and next action	Prevent conflicting plays
Contact preferences	Current choices and suppression state	Stop inappropriate follow-up

Clean before writing back

I audit existing properties before adding new ones. A field already used by another workflow needs an agreed meaning, rather than a near-duplicate name.

I define the match and merge rules, then test them on a small sample. Domain changes, shared domains and personal email addresses need exceptions. I preserve the original source alongside the latest interaction.

Enrichment also gets an overwrite policy. A verified value entered after a customer conversation should survive a lower-confidence research result. Conflicting evidence goes to review.

Make the same process reusable

The process accepts an account or contact, checks whether it already exists, researches the missing information and proposes a bounded update. It records the source, the time and the result.

Clay can combine research and data providers. A coding agent can prepare transformations and checks. n8n, Make or Zapier can connect supported events and actions. I choose the combination the team can operate and maintain.

Backfills run in batches. New records enter the same process. Refresh rules follow how quickly a field can change, rather than one expiry date for the whole record.

I expose the useful output inside the CRM: account summary, missing stakeholders, evidence and next step. Reps should not need to reconstruct the research across several tabs.

The output is an enriched account record that can be inspected, corrected and refreshed.

3. SHAPE: make signals the evidence layer

This is the part I give the most attention. A signal needs a defined meaning, a source and a response rule before it becomes useful.

I separate 3 questions. Does the account fit? What did we actually observe? What might that observation mean?

The first question determines qualification. The next two guide investigation and timing.

First-party: interactions with our own channels

First-party data comes from our direct relationship with the audience: our website, product, CRM, conversations and tools. Salesforce's overview describes this source relationship.

I include the website in general, not only gated downloads. Useful events can include an identified visitor returning to a relevant page, a person asking a question, an assessment completion or a product workspace reaching a milestone.

I also distinguish opening an event invitation from attending it, clicking an email from replying and starting a trial from using the product meaningfully.

The event's meaning matters more than the category label. A positive request to discuss a problem deserves different treatment from an email open.

Build a useful application before asking for a meeting

I want the prospect to experience a small part of our know-how. A working assessment can make that experience concrete.

A founder can build an interactive form, website grader, benchmark explorer, calculator or diagnostic around a problem the ICP recognises. Lovable or another coding workflow can help turn the logic into an application.

The hard work is choosing the questions and making the result useful. An attractive interface wrapped around generic advice gives us little to learn from.

The Teklens PM Grader is an example of showing the method. It starts with 6 practical situations and offers a profile and suggested next activities. Its initial experience works without an email address.

The AI Monitor explorer shows another pattern: let someone compare a situation with a benchmark. The point is to make the underlying knowledge usable.

For an ABM play, I would build the tool around a decision we can help the buyer make:

Tool idea	Useful output for the visitor	Signal worth keeping
Website positioning grader	A short explanation of unclear positioning and practical revisions	The problem examined and the requested follow-up
CRM readiness check	A prioritised list of gaps in account data and ownership	Reported systems, constraints and selected priorities
Interactive benchmark	A relevant comparison with visible limits and sample context	The comparison the visitor chose to explore
Business-case calculator	A range based on explicit assumptions	Assumptions volunteered by the visitor
Buying-group checklist	Missing roles and a suggested next conversation	The buying roles the person asks for help with
Implementation planner	A sequence of decisions and dependencies	The constraint the visitor wants to address

These are tool concepts, not claims about measured results from a campaign.

Gate the extension, preserve the useful preview

I can show the first result immediately and offer an optional saved report, deeper analysis or discussion. The visitor should understand what they receive before sharing more information.

I keep the request for a report separate from a request for sales contact. I explain how the information will be used and preserve the person's choices. The ICO's guidance on collecting information for direct marketing explains the importance of clear purpose and transparency.

I do not treat first-party data as automatically accurate or automatically permissioned. The implementation needs those properties by design.

For the event model, I keep a small useful set: tool started, tool completed, result viewed, report requested and conversation requested. Each event carries a tool version, timestamp and reliable account or contact match where available.

I store the minimum useful result. Raw answers, confidential uploads and personal information do not belong in every alert. An anonymous completion remains anonymous until we have a reliable basis to connect it to an account.

An assessment finding is evidence of the situation the visitor reported. It still needs a conversation before becoming a confirmed buying project.

Second-party: information shared by a direct partner

Second-party data is another organisation's first-party data shared directly with us. That source relationship is the distinction in this data-provenance comparison.

Examples include a partner introduction, an agreed account overlap or participation in a co-hosted event. I record who supplied it, what was shared and the permitted use.

Crossbeam, PartnerStack, WorkSpan, Commsor or The Swarm can be relevant examples for partnership and relationship workflows. A product name alone does not tell us what access or permission exists.

Third-party and external research: evidence from outside that relationship

External sources help us see changes around an account. I keep these observations separate from direct engagement.

• Company and people data: firmographics, role changes, stakeholder research and account relationships.
• Technology: products in use, compatibility clues and changes in the technical environment.
• Business events: funding, leadership changes, expansion, acquisitions and relevant news.
• Hiring: open roles, team changes and responsibilities that may point to a current constraint.
• Public activity: relevant posts, published discussions, review content and competitive changes.
• Search and web research: topics, page changes, public directories and evidence gathered from company websites.

The same event does not become stronger because 3 providers repeat it. I deduplicate it against the underlying event and keep the original evidence.

Data type follows provenance. Engagement with our own post differs from a vendor's inferred interest model. A review platform's directly shared activity differs from a public review we read on the web. Champion tracking is external research unless the information comes from a direct relationship.

Keep fit tiers separate from signal priority

I use Tier 1, Tier 2 and Tier 3 to describe account fit and the level of service we can justify. Confirmed exclusions are disqualified. Incomplete research remains unresolved.

The signal score helps order the work inside those boundaries. It cannot turn an excluded company into an ICP account.

The interactive example uses an illustrative weighting model. Direct buyer requests carry more weight than passive activity. Completed tools and substantive replies carry more weight than general browsing. External events provide supporting context.

I cap repeated events, reduce the contribution of older observations and carry match confidence into the calculation. The weights are starting hypotheses for the demonstration. They need back-testing against our own account outcomes.

The output is a qualified account, a prioritised evidence summary and a proposed action. A score without that explanation is difficult to challenge.

4. SHAPE: assess awareness and connection strength

Fit, engagement and relationships answer different questions. I keep them visible together.

An account can fit well while having little awareness of us. Another can know us through a trusted partner while having no active project. A third can be evaluating while our access to the decision group remains weak.

Use awareness stages as an evidence summary

The stages are a working model of our evidence. They are not a claim that we can read a buyer's mind.

Stage	Evidence I would look for	What I would do next
Identified	A qualified account with no reliable engagement evidence	Learn the account and find a relevant route in
Aware	A reliable, relevant interaction with our company or content	Offer a useful next piece of context
Interested	Meaningful engagement, such as a substantive reply or a completed relevant assessment	Understand the problem behind it
Considering	A buyer confirms a problem and agrees to explore an approach	Clarify evaluation criteria and participants
Selecting	A confirmed evaluation and buying process involving the relevant people	Help the group reach an informed decision

A person can open 20 pages without agreeing to evaluate anything. I require buyer evidence for Considering and Selecting. Creating an opportunity record does not supply that evidence on its own.

Recency changes confidence in current engagement. A past decision remains in the history even when its activity becomes stale.

Make relationship access explicit

Alongside awareness, I record connection strength: no relationship, a recognised connection, a meaningful exchange, a trusted introduction or champion, and access across the buying group.

These are working descriptions, not universal steps. A champion needs evidence of influence and willingness to help. Several contacts in the CRM do not prove a strong relationship.

The next action follows the combination. A Tier 1 account showing interest with weak access may need an introduction. An evaluating account with a single contact may need help involving security, finance or the eventual users.

This is where the buyer-led enterprise sales process becomes useful. The task is to help people complete the decision together.

5. AMPLIFY: connect demand generation and the outreach engine

I choose the offer before I choose the sequence.

An unfamiliar account may benefit from a useful insight or self-assessment. An interested account may want a benchmark or small discussion. An evaluating account may need a focused workshop, technical answer or pilot plan.

The channels read the same account context. Marketing and sales should not run competing plays against the same company.

Match attention to the account

For Tier 1, I expect a person to review the account and choose the approach. That can include a warm introduction, a tailored diagnostic, a relevant event invitation or direct outreach grounded in the buyer's situation.

For Tier 2, I look for repeatable plays around a shared problem, with research and drafting prepared in advance. For Tier 3, I keep the motion proportionate to the likely value and service cost.

A direct buyer request can still deserve a prompt response at any fit tier. It does not change the account's fit.

Make outreach a bounded workflow

Before a message can leave, the workflow checks the current owner, opportunity, customer state, recent conversations and contact preferences. It should detect a reply or meeting and stop the relevant sequence.

The draft explains the relevance, offers something useful and proposes an appropriate next step. A person approves first outreach and relationship-sensitive follow-up.

Instantly, HeyReach, Smartlead, Lemlist, Nooks or an existing CRM workflow can support parts of execution. Tool selection follows the channel, the team's responsibilities and the controls we need.

I also connect the work that creates demand: founder content, useful website applications, search, partner conversations, webinars, small events and customer proof. The same insight can inform an article, an assessment and a conversation.

I test a message with real buyers before expanding it. AI can prepare alternatives and point out assumptions. Responses decide what is useful.

Preserve context after the reply

A reply should update the account brief. A meeting should give the owner the original signal, the relevant research and the actual exchange.

If the answer is no, later, wrong person or already a customer, the next action changes. Re-entering the same sequence because a second signal arrived would discard what we just learned.

The output is a conversation with an agreed next step, or a clear decision to pause or stop.

6. EVOLVE: report progress and improve the next cycle

The report should help us choose what to change.

I look at a cohort of target accounts through qualification, engagement, evaluation, customer value and expansion. I preserve the time windows and definitions so comparisons remain meaningful.

I use these views as a starting point:

1. Account coverage and quality: which ICP accounts are mapped, researched and owned, and where the evidence is still weak.
2. Fit × awareness: where accounts sit by tier and evidence stage, including accounts moving backwards or becoming stale.
3. Signal usefulness: which observations preceded useful conversations or buyer-confirmed progress, and which created noise.
4. Response and ownership: open tasks, time to review, conflicting actions and important accounts with no agreed next step.
5. Pipeline progress: opportunities created within the ICP, milestone conversion, stalled decisions, wins and loss reasons.
6. Customer outcomes: time to first value, adoption, renewal, expansion and the segments that need disproportionate support.

An event preceding a deal is an association. It is not proof that the event caused it. I compare like-for-like cohorts and, where feasible, a held-out group before making a stronger claim.

The dashboard example in this article uses demonstration data. It shows the questions to ask, without presenting invented campaign results as evidence.

Review the agent work too

I review incorrect matches, unsupported research, duplicate actions, failed writes and drafts that need substantial correction. A busy workflow can be producing the wrong output very efficiently.

Each agent gets a bounded job, an owner and a review measure. Routine, reversible internal preparation can have more autonomy. External communication requires review. Pricing, commitments and sensitive relationship decisions remain with a person.

Humans set goals, decide and approve. Agents prepare and do the repeatable work. Shared goals and shared context keep them working together.

Close the write-back path

Confirmed account facts go to the CRM. A proposed change to the ICP, message or playbook goes through review. I keep the old version so we can explain what changed and why.

Customer success belongs in this loop. If a segment closes well and struggles to reach value, DECODE needs that evidence. If a customer finds a new use case and expands, the account hypothesis deserves another look.

The review ends with a decision: keep a play, change it, stop it or investigate. Then choose the next constraint.

Start with one play you can inspect

A complete system needs maintenance. Someone owns the model, the data quality, the connections and the exceptions.

If a founder can manage the active accounts with a spreadsheet and a regular review, I would start there. Automation earns its place when the task repeats and the decision rules are clear enough to inspect.

Choose one segment and one useful tool or offer. Run the play manually across a small set of accounts. Record the evidence, the decision, the response and the outcome.

Then automate the preparation, keep the review point and test the next version.

Back to Monday's grader completion. The useful system recognises the existing opportunity, preserves what the visitor volunteered and briefs the person who owns the relationship.

After the conversation, it keeps what the buyer taught us. The next account starts with better context.

Tools and directory coverage

The workflow links verified existing tool pages in the GTM directory. A link does not mean that every tool belongs in one stack or has been promoted to the public shortlist.

Audit checked on 2026-10-22 against the live directory and each matching tool's website. It changes no rating or recommendation. This is an inventory of the names in the workflow, not a recommendation to buy every product.

In the public shortlist (10)

AI Ark · Apollo · Claude · Common Room · Discolike · Gamma · Nooks · Ocean.io · OpenAI · The Swarm

Existing pages outside the public shortlist (38)

These pages exist and are reachable; they are not part of the curated public list.

ActiveCampaign · Apify · Attio · BetterContact · BuiltWith · Champify · ChatGPT · Chili Piper · Clay · Crunchbase · Default · Findymail · Goldcast · HeyReach · HubSpot · Instantly · Lemlist · LinkedIn Sales Navigator · Loom · Make · n8n · Orum · Owler · Perplexity · PhantomBuster · Pipedrive · PredictLeads · RB2B · Salesforce · SendSpark · Smartlead · TheirStack · Trigify · UserGems · Vector · Warmly · Zapier · ZoomInfo

Feature of an existing entry (1)

• Claygent is Clay's research agent, a feature of Clay, not a missing independent vendor.

No dedicated directory entry yet (38)

Ahrefs · Amplitude · beehiiv · Capterra · Claude Code · Codex · Commsor · Crossbeam · Customer.io · Firecrawl · Freckle · G2 · Gmail · HG Insights · influencers.club · Jungler · LinkedIn Events · Lovable · Luma · Mixpanel · PartnerStack · PitchBook · PostHog · RevenueHero · Rodz · Semrush · Sendoso · Similarweb · Slack · Storeleads · Sumble · Supabase · Tally · Tavily · TitanX · TrustRadius · Webflow · WorkSpan

Claude Code (Anthropic) and Codex (OpenAI) are separate products without their own entry; the related parent pages are Claude and OpenAI. Rodz is verified as the LinkedIn and social-signal vendor at rodz.io; Jungler means jungler.ai. Neither has a directory entry.

Notes: the directory holds two rows for Ocean.io (ocean and ocean-io, same website); the workflow links ocean-io. The n8n entry currently shows the display name “N8n road”; its website n8n.io is verified. Make (make.com), Default (default.com) and Vector (vector.co) were checked against their websites before linking.