On this page
- Current MarketPulse workflow
- Start with one decision and trigger
- Assign owners, targets and handoffs
- Choose tools that support the control
- Manual, automated or branded delivery
- Price setup and recurring operations
- Measure quality and adoption
- Adapt to the client and stack
- Match evidence to the next action
- Control scope, permissions and exceptions
- Define the maintained playbook package
- Test event order as well as individual rules
- Worked example: separate preparation from client action
- Frequently asked questions
Direct answer: Design each signal-to-action playbook around one trigger and one governed next decision. Define the evidence threshold, identity state, owner, SLA, approved action, human approval, exception path, evidence receipt, feedback loop, and stop condition before automating anything.
Current MarketPulse offer: intent-data plans start at $500/mo. See the product, demo, and current plans. Updated October 3, 2026.
Who this is for: Growth strategists, campaign leads, RevOps teams, and agency operators turning intent observations into repeatable client actions.
A signal has no client value until someone knows what to do, why the action is appropriate, how quickly to act, and when not to act. A playbook bridges that gap. It is smaller than a campaign plan and more controlled than a workflow automation.
The best playbooks are legible to a client and executable by a team. They keep evidence separate from interpretation, interpretation separate from approval, and approval separate from outcome. That structure makes automation safer and feedback usable.
Current MarketPulse workflow
BrandWell MarketPulse: intent data starting at $500/mo. Find people researching topics relevant to what you sell, apply saved ICP filters, and review available contact details before taking action.
MarketPulse plans are starting at $500/mo. Verify current package scope and offers on the product page.
| Plan | Topics and refreshes | Monthly exports |
|---|---|---|
| Starter | 1 topic, weekly | 25,000 contacts |
| Growth | 3 topics, daily | 100,000 contacts |
| Scale | 10 topics, daily | Unlimited contacts |
Swipe the table to see all columns.
A pull retrieves available data from the previous 24 hours for one topic. Daily use across all included topics provides 90 Growth pulls or 300 Scale pulls in a 30-day month. Weekly Starter pulls vary by calendar month. Available audience size and contact fields vary, and audiences may overlap. Refreshes stop at the plan limit without overage charges.
- Find and qualify: search the topic catalog, save your ICP, and review the people and companies that match.
- Act on the research: export qualified contacts or prepare an Outreach or Direct Mail workflow. Connected products, channel usage, and fulfillment may cost extra.
- Get help from AIMEE: Growth and Scale include AIMEE for the initial user to research accounts and prepare the next step through connected tools.
Agencies and other service businesses can build client deliverables around their available Intent Scans and exports. Keep each client’s scope, permissions, and service fees clear. A subscription is not a promise of a white-label platform or exclusive access to a market.
Explore MarketPulse and watch the demo or compare plans starting at $500/mo. Any early-access discount is a separate, time-limited offer shown to an eligible recipient.
Start with one decision and trigger
Start with the client decision and work backward to the minimum signal that justifies a next step. Define the intended outcome, eligible account, trigger, threshold, required context, owner, response time, action options, approval, and stop rule. Test the play manually before building automation.
A repeatable playbook uses consistent fields and reason codes, but it should not erase judgment. The team should be able to explain why the signal qualified, which fact remains uncertain, who accepted the action, and what happened next. Fast delivery without that context creates activity, not value.
Choose a small portfolio of plays tied to real client capacity. If sales can review ten evidence cards a week, do not create a system that pushes hundreds of alerts into the CRM.
Assign owners, targets and handoffs
Include intake, qualification, assignment, action, approval, exception handling, evidence capture, and feedback. The signal owner confirms source, freshness, and threshold. An analyst checks identity, enrichment, fit, and exclusions. The action owner accepts or rejects the play. The system records the decision and SLA. A human approves external or irreversible execution.
Set different SLAs for urgent high-confidence events, standard research queues, data-quality incidents, and client review. Define what pauses the clock and what happens when an owner misses it. The handoff should carry the evidence card, action options, deadline, approval requirement, and reason codes.
Document the wider delivery operating model in an intent-data delivery SOP. A playbook is one governed unit inside that system, not a substitute for source management, client onboarding, or incident handling.
Choose tools that support the control
Use a modular stack: source and event collection, identity and enrichment, rules or workflow, a research workspace, client portal or report, CRM and activation connectors, suppression, audit history, and monitoring. Tools must expose errors and allow a human to see why a record moved.
Templates matter as much as software. Maintain a playbook card, signal dictionary, decision table, SLA matrix, rejection codes, escalation form, evidence receipt, change log, and monthly review. A lightweight document plus task system may outperform an elaborate automation until the client definitions stabilize.
Choose tools from demonstrated capabilities, written access terms, supported integrations and actual costs. Verify client separation, data rights and the actions available in the relevant account before promising a service.
Manual, automated or branded delivery
Manual playbooks maximize learning and control, automated playbooks increase speed for stable rules, and white-label playbooks add branded multi-client delivery. Use manual operation for a new signal, uncertain identity, sensitive decision, or small volume. Automate deterministic collection, deduplication, internal routing, reminders, and draft preparation after the rule proves reliable.
A white-label approach is useful when the agency needs consistent branded reports, portals, permissions, and recurring delivery across clients. It does not remove the need for client-specific purposes, thresholds, suppression, approvals, and evidence.
Use a hybrid workflow: automate supported, reversible preparation after testing it; require the designated reviewer for context-dependent or external action. Define approval scope, validity, revocation and what happens when the underlying record changes.
Price setup and recurring operations
Model setup and delivery from the work units rather than using a generic fee. Setup includes discovery, source mapping, data roles, field definitions, trigger logic, action design, integration, QA, training, documentation, and launch support. Recurring delivery includes monitoring, analyst review, client support, exceptions, changes, and reporting.
Estimate monthly volume, review share, analyst minutes, action-owner time, software, connector maintenance and exceptions. Model extra hours or charges for custom systems, multiple teams, changing rules and specialist review. Use documented inputs rather than an unexplained complexity multiplier.
Separate implementation, recurring service, usage boundaries and scoped change requests. Include observed labor, software, support, maintenance and exceptions in a defined cost model. Explain exclusions before quoting a margin.
Measure quality and adoption
Measure time to first usable play, time from trigger to review, SLA attainment, acceptance rate, action completion, rejection reasons, exception rate, client-user adoption, and downstream progression. Also track data defects, duplicate alerts, manual overrides, and playbook revisions.
Use a funnel with visible denominators: observed, eligible, reviewed, accepted, approved, executed, responded, and progressed. Report outcomes as observed or associated unless the evaluation supports attribution. Monitoring an outcome does not establish that the play caused it.
Quality includes whether the evidence was correct, complete enough for the decision, and delivered to the right owner. Adoption includes active reviewers and completed decisions, not portal logins alone. Outcome measures should never hide low acceptance or missed SLAs.
Adapt to the client and stack
Match control to maturity. An early client needs one or two manual plays, a weekly queue, and clear education. A scaling client may use standard fields, internal routing, and client-approved templates. A mature client may support event-driven automation, multi-team assignments, richer evidence, and formal change control.
Technology fit also matters. A weak CRM or unclear owner makes automated routing dangerous. A sophisticated stack still needs simple evidence fields. Service tiers should reflect number of plays, signal complexity, response cadence, integrations, users, analyst capacity, and support rather than prestige labels.
Do not activate every available feature. The best playbook for a client is the smallest one that reliably improves a real decision and produces feedback.
Match evidence to the next action
The selected signal determines the evidence needed, identity sets the allowed personalization, enrichment supports fit, routing assigns accountability, and approvals protect external action. A weak topic observation may justify research. A high-fit company with repeated behavior may justify account prioritization. A possible person still requires confidence, contact validation, and appropriate use.
Write routing rules as if-then decisions with explicit exclusions. For example: if source is current, company fit is high, behavior meets the threshold, identity remains company-level, and no suppression applies, then create an analyst research task. Do not create an individual outreach task.
When the client stack is ready, follow a controlled plan to integrate intent data with the CRM and marketing stack. Every write should carry source, timestamp, evidence, decision status, and owner.
Control scope, permissions and exceptions
Risks include ambiguous scope, unlawful or unauthorized data use, excessive permissions, cross-client leakage, insecure exports, brittle integrations, silent failures, stale rules, automation loops, and client expectations that exceed the evidence.
Use tenant separation, least privilege, secret management, encryption as appropriate, environment controls, audit logs, retention and deletion, suppression synchronization, connector monitoring, incident response, and periodic access review. Record vendor and client responsibilities in writing.
Document who authorizes a message, maintains eligibility and suppression, sends it and handles replies. Obtain qualified review of applicable channel rules for the client and jurisdiction. A workflow diagram is not a legal determination.
Define the maintained playbook package
A recurring white-label service should include a maintained play library, client-specific definitions, signal processing, branded evidence, routing, approvals, SLA monitoring, support, change control, and a monthly learning review. The package should state included plays, topics, sources, users, integrations, review capacity, cadence, responsibilities, and usage boundaries.
AIMEE can help organize approved evidence and draft a proposed route through configured connected tools. Supported actions depend on the actual integration and permissions; preserve the designated review and stop conditions.
MarketPulse supplies topic audiences and ICP filtering starting at $500/mo. A custom playbook, CRM connection, branded client portal, approval queue and agency delivery require their own supported implementation and written scope. They are not automatically included native workflows.
Nine-field PRICED playbook card
- 1. Purpose and client outcome: State the decision this play supports and the bounded improvement it seeks.
- 2. Relevant trigger and threshold: Name the source, event, freshness window, qualifying rule, and exclusions.
- 3. Identity and enrichment state: Record whether evidence supports a company, possible person, validated contact, or qualified stakeholder.
- 4. Control owner and SLA: Assign one accountable owner, response target, pause rules, and escalation path.
- 5. Execution action: List the reversible internal step or proposed external step appropriate to the evidence.
- 6. Decision approval: Name the human who approves identity use, CRM writes, outreach, spend, or client delivery.
- 7. Exception and stop condition: Define conflicts, missing fields, security events, suppression, staleness, and policy cases that halt the play.
- 8. Evidence receipt: Capture observation, interpretation, acceptance, approval, action, timestamps, and reason codes.
- 9. Feedback and revision cadence: Review outcomes and rejection reasons, update thresholds, version the play, and communicate changes.
Copyable agent workflow for Claude, ChatGPT, or AIMEE
Paste the following into Claude, ChatGPT, or AIMEE after supplying only approved client inputs.
ROLE: You are a controlled signal-to-action playbook designer. INPUTS: Trigger, evidence threshold, identity state, enrichment fields, owner, SLA, allowed actions, approvals, exceptions, stops, and client outcome. 1. Produce a nine-field PRICED playbook card. 2. Mark every missing field and do not invent defaults. 3. Draft reversible internal routing and one proposed next action. 4. Separate observed evidence, interpretation, decision, and expected outcome. 5. Flag external outreach, CRM writes, spend, client delivery, and irreversible actions for human approval. 6. STOP on stale data, identity conflict, suppression, security issue, missing owner, missing purpose, or policy exception. 7. A human approves execution and any change to thresholds. OUTPUT: Playbook card, missing-input list, proposed route, approval queue, evidence receipt schema, and maintenance date.
Approval boundary: An agent may research, classify, summarize, draft, and recommend. A human must approve identity use, CRM writes, external outreach, spend, client-facing delivery, legal interpretations, and irreversible actions.
Playbook test worksheet: Run every new play through four scenarios before launch: a clean qualifying record, a near-miss, a suppressed record, and a conflicting-identity record. Confirm which fields populate, who receives the task, what clock starts, what message is drafted, which action waits for approval, and what evidence is written back. A play is not ready if the happy path works but the stop paths are invisible.
Version the playbook like an operating control. Store an owner, effective version, change reason, approved fields, source dependencies, decision rules, action template, and rollback condition. Review whether a threshold change alters client scope or expected labor. Do not let an agent silently learn a new external action from an outcome. Proposed improvements should enter a review queue, with a human deciding whether to test and adopt them.
From pilot play to maintained service control
Promote a playbook through four states. In design, the team writes the decision and stop paths. In shadow mode, it processes records but takes no external action. In assisted mode, it creates tasks and drafts while humans review every decision. In controlled automation, only stable and reversible steps run automatically, with sampling and rollback. Record the entry and exit criteria for each state. Volume alone is not a reason to promote a play.
Test failure deliberately. Disable a connector, withhold a required identity field, introduce a duplicate, create a suppression conflict, assign no owner, and return an ambiguous signal. The system should surface the error, preserve evidence, prevent unsafe action, and route an exception. Record recovery time and whether a reviewer could understand what happened without reading integration code.
Every monthly review should answer: Is the trigger still relevant? Did the source or schema change? Are thresholds producing useful acceptance? Which rejection codes increased? Are clients acting within the SLA? Did any automation exceed its boundary? What should be retired? Store the decision with the playbook version. A recurring service earns trust by maintaining controls, not by accumulating automations.
When an agent proposes a new shortcut, require a test set, expected improvement, possible harm, approval owner, measurement plan, and rollback. Self-improvement without governed adoption is scope drift. The human remains accountable for the service promise and external consequence.
Minimum launch evidence: Before a play can enter assisted mode, collect results from a representative test set and document false positives, false negatives that reviewers can identify, exceptions, decision time, and user comprehension. Confirm that every external action waits for the intended approval and that every stop case leaves an audit record. If users bypass the card because it is confusing, simplify it before adding another connector.
Client adoption check: Observe whether the named owner can accept, reject, or escalate a card without asking the agency to reinterpret it. Review missed SLAs and unused fields. Remove fields that do not support a decision, but never remove provenance, approval, suppression, or stop-state evidence merely to make the workflow look simpler. Train backup owners before automating reminders or escalations.
Retirement rule: Pause a play when its trigger no longer supports the client decision, its acceptance rate falls for an unexplained reason, the destination lacks capacity, or a source or policy change invalidates the control. Archive the final version, open exceptions, and decision record so the team can explain why it stopped.
Test event order as well as individual rules
NIST’s research on state-based testing explains why input order can affect system behavior and fault detection. Applied here as a workflow design principle, test sequences as well as individual fields. This does not establish that a marketing playbook has passed a formal NIST assessment.
- Approve, then suppress: cancel the pending external action and record the changed eligibility.
- Suppress, then receive a new signal: preserve suppression; new evidence is not new permission.
- Accept, then receive the same event again: avoid a duplicate task while preserving the repeat observation.
- Approve, then change the identity: route for review if the approval no longer covers the record.
- Connector fails, then retries: reconcile the destination before repeating a write.
Write the expected state, allowed next step and audit record for each case. These are proposed agency tests, not claims about built-in BrandWell behavior.
Worked example: separate preparation from client action
A fictional monthly queue contains 200 observed events. Eighty meet the stated evidence rule. Reviewers accept 50, approve 30 next steps and execute 24. Acceptance is 50 / 80 = 62.5% of qualifying events, or 50 / 200 = 25% of observations. Execution is 24 / 30 = 80% of approved steps. The other six approved steps require a reason, such as a pause or a changed record.
Assume $250 in software, $600 in analyst work and $150 in maintenance and support. Defined operating cost is $1,000: $20 per accepted event or $41.67 per executed step. These invented inputs are not typical results or a quote for a complete BrandWell service. Accepted events, executed steps, replies and customers are different units; none of these costs is proof of ROI.
A topic-research play in practice
Review a MarketPulse topic and apply the saved ICP to its audience. Record the relevant evidence, source date and company fit in an approved research brief. Ask AIMEE to draft the brief from supplied facts, listing unknowns separately. A reviewer decides whether a supported CRM task or appropriate follow-up is warranted. Keep topic audience membership distinct from visits to your own website and from an expressed purchase request.
Frequently asked questions
What makes a playbook actionable?
A specific trigger, evidence rule, owner, response target, allowed next step, approval and visible stop path.
Should every signal trigger outreach?
No. Some signals support only internal research, and suppression or uncertainty can prevent further action.
Does MarketPulse include a custom client playbook engine?
MarketPulse provides topic audiences and ICP filtering. Custom routing, client portals and approval engines need separately supported implementations.
When can a play become automated?
After observed tests support the intended behavior, including duplicates, changed permissions, identity conflicts and failed connectors. Define monitoring and rollback before increasing its scope.
Add topic evidence to a reviewed workflow: explore MarketPulse and its current plans.
Reviewed and updated October 3, 2026.
Written by
