Intent-Data Service SOPs: Acceptance, SLA Clocks and Exceptions

Current MarketPulse research 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.

MarketPulse standard monthly plans

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.

Check actual service ownership

This guide is for agency operations leaders, delivery managers, RevOps consultants, and service owners who need to deliver intent data consistently across multiple clients. It covers the complete operating system: roles, staffing, service levels, quality assurance, integrations, capacity, escalation, evidence, and white-label governance. It is not a universal SLA benchmark or a promise that automation can replace accountable human review.

Define versioned work units

Use a catalog of small work units with one common schema. A new operator should be able to execute a unit without relying on tribal knowledge, while a reviewer should be able to reconstruct what happened from the evidence.

Use this work-unit template:

• Purpose and trigger: why the unit exists and exactly what starts it.
• Required inputs: fields, permissions, configuration, and upstream acceptance state.
• Accountable owner: one role responsible for the result, even when others contribute.
• Procedure: ordered actions, decision branches, and prohibited shortcuts.
• Output: the record, report, status, or decision passed downstream.
• Acceptance test: the conditions that make the output usable rather than merely complete.
• SLA: clock start, target, stop condition, and escalation threshold.
• Evidence: source ID, timestamps, rule version, reviewer, and disposition.
• Exception path: classification, containment, notification, correction, and closure.
• Version: approval history and effective configuration.

Create units for topic intake, signal classification, company matching, optional contact resolution, enrichment, fit and freshness checks, suppression, QA, routing, client approval, activation, outcome capture, billing inputs, and offboarding. Keep the procedure stable. Store each client’s ICP, topic set, geographic limits, confidence thresholds, required fields, allowed destinations, approvers, retention period, and report branding in a configuration manifest. Keep shared procedures and client-specific changes traceable.

Assign roles and service-level clocks

An intent-data delivery workflow needs named owners across the entire path, not just a data analyst. At minimum, define an agency service owner, platform operator, QA reviewer, CRM or automation owner, privacy and security owner, client approver, and revenue follow-up owner. A RACI can show who is responsible, accountable, consulted, and informed, but every work unit still needs exactly one accountable role.

A practical chain runs from signal intake through identity, enrichment, qualification, QA, routing, activation, outcome capture, and exception handling. Put a quality gate before each irreversible or high-impact step. Weak account matches, sensitive uses, new messaging, audience activation, material spend, and destructive CRM changes should require human approval.

Do not write an SLA as “deliver within one business day.” Define when its clock starts, which dependencies pause it, what accepted delivery means, and who receives an escalation. A high-confidence first-party pricing-page alert may justify a short response target. A weekly off-site topic report has a different source cadence and risk profile. Set service levels from source cadence, client capacity, operational risk, and contracted scope – not a generic internet benchmark.

Use a handoff receipt for every destination. Record the source record ID, completed stage, acceptance state, timestamp, destination, next owner, rejection reason, and retry status. An export and a sales-accepted record are different states; report each explicitly.

Choose tools for the actual gap

Choose tools that preserve provenance, state, ownership, and evidence as work crosses systems. A glossy portal is not an operating system if the agency cannot explain where a signal came from or why a record was routed.

Build the resource stack around these artifacts:

1. A field dictionary with observation unit and permitted values
2. A client topic and ICP configuration manifest
3. A source and provenance taxonomy
4. A match-confidence and contactability rubric
5. A routing and approval matrix
6. A QA sample sheet for accepted and rejected records
7. A suppression, deletion, and access ledger
8. An integration runbook with retry and rollback steps
9. A branded portal or report template
10. An outcome ledger, exception log, and change record

Choose integrations only after the acceptance contract is clear. A CRM connector should preserve source, recency, confidence, client, status, and rule version, not simply create a lead. An automation should expose failures and retries. A report should distinguish account signals, separately resolved contacts, and downstream outcomes.

MarketPulse supplies topic research and available match details. TrafficID separately supports own-site visitor review. AIMEE can organize supplied context through configured tools. Custom scoring, client reports, portals, routing and destination integrations require separately verified implementation, rights, scope and fees.

Compare three delivery modes

Manual delivery is appropriate for ambiguous classification, early samples, and exception discovery. It lets an experienced analyst see why a topic is noisy or a match is uncertain. Its limits are labor, consistency, and dependence on tacit judgment.

Automation is appropriate after definitions, inputs, rules, tests, and exception routes are stable. It can normalize, enrich, score, route, notify, and assemble reports at higher volume. Its danger is silent repetition: one flawed rule can distribute the same error across every client. Log the input, rule version, output, confidence, exception, and approver for each automated action.

White-label delivery adds client-facing branding, portals, entitlements, usage, support, and tenant controls. It does not reduce the underlying evidence or privacy standard. It increases the need for isolated credentials, client-scoped suppressions, configurable approvals, and reliable offboarding.

Compare the three modes on time to value, labor, repeatability, control, error visibility, client access, margin, security, and change management. Test manual discovery, controlled automation and separately implemented client delivery against actual needs and acceptance rules. Regardless of mode, the same output should pass the same acceptance test.

Count handling and exception costs

Model setup cost from discovery, topic design, configuration, field mapping, integrations, migration, initial QA, training, documentation, and contingency. Model recurring cost from platform scope and usage, matching and enrichment, analyst minutes, automation, reporting, support, account management, security, compliance, and ongoing calibration.

Use activity-based costing. For each work unit, multiply expected volume by handling time and loaded labor, then add technology and overhead. Track exception volume separately. A low-cost automated path can become unprofitable if ambiguous matches, failed syncs, missing fields, or client revisions require repeated manual intervention.

Useful unit economics include cost per processed signal, reviewed account, accepted account, usable contact, successful handoff, sales-accepted output, and resolved exception. Also track setup payback and gross margin by client. Do not bury onboarding overruns inside recurring margin.

Measure four distinct layers

A complete scorecard has four layers. First, measure time from configuration approval to the first accepted output and from each signal to its accepted destination. Second, measure quality: match acceptance, duplicate rate, freshness, required-field completion, suppression compliance, routing success, rework, and SLA breaches. Third, measure adoption: report views, queue acceptance, disposition completion, follow-up speed, and play usage. Fourth, measure business outcomes: responses, meetings, qualified opportunities, pipeline, wins, retention, and expansion.

Keep denominators. “More accepted accounts” means little without total processed volume and rejection reasons. Sample rejected records so a highly restrictive rule cannot appear accurate while eliminating useful coverage. Record how many routed records received a disposition; otherwise the service cannot distinguish low quality from low client adoption.

Keep associated pipeline and causal impact distinct. Use a suitable comparison where feasible, with documented assignment, observation window, overlap, exclusions and uncertainty. If the design cannot support a causal conclusion, report descriptive outcomes and missing feedback.

Version client configuration separately

Client maturity should change the delivery mode, not weaken the control system. An early-stage client may need a reviewed weekly report, a small account queue, and manual approval. A mature revenue organization may support near-real-time CRM routing, automated enrichment, account plays, and structured outcome feedback.

Vary source mix, topic breadth, ICP filters, geography, required fields, confidence thresholds, cadence, destinations, approval rules, retention, and service package. Preserve the work-unit schema, data minimization, tenant isolation, QA, evidence, suppression, exception handling, and change control.

Attach a versioned configuration manifest to the client service order. Re-run acceptance tests when the stack, use case, geography, source, fields, threshold, activation, or approval chain changes. A package upgrade should not silently change the meaning of an accepted record. If a client cannot operate an activation safely, keep delivery at the report or account-prioritization layer until readiness improves.

Preserve source and outcome evidence

Every delivered record should retain source type, observation unit, event or collection time, recency band, match method, match confidence, normalized entity, fit, contactability, suppression and permission state, chosen action, handoff receipt, and downstream disposition. Do not overwrite the original observation when a score changes.

Account-level intent and person-level identity are separate evidence states. A company associated with topic research is not proof that a particular employee generated the activity. A separately resolved contact can be appropriate for an approved workflow, but the SOP must not retroactively label that person as the original researcher.

Use separate QA samples for company matching, contact resolution, enrichment freshness, and destination acceptance. Test both precision and recall where a truth set permits it. Preserve rejected and unmatched records with safe retention so operators can diagnose drift without repeatedly processing the same bad inputs.

The operational chain should read: source observation → normalized company → match confidence → fit and freshness → optional contact gate → permitted activation → successful handoff → client disposition → revenue evidence. That lineage makes an intent-data delivery SOP defensible and improvable.

Close exceptions with verified tests

Define exception classes such as data quality, match ambiguity, security, privacy, consent or suppression, platform policy, integration, volume, SLA, client access, unsupported claim, and billing. For each, record severity, owner, containment, client-notification rule, root cause, correction, retest, closure evidence, and recurrence status.

Version and approve changes to topics, match logic, confidence thresholds, fields, destinations, retention, messaging, and permissions. Test them in a client-safe environment, document the expected effect, and keep a rollback path. Emergency changes still need an after-action review.

Assign actual access, necessary fields, retention, incident ownership, correction, suppression and deletion controls. Retain evidence of implementation and testing rather than treating a framework or supplier contract as certification.

Verify the actual source, destination, purpose, recipient, jurisdiction, account and channel requirements before action. A data receipt does not establish upload or contact eligibility. Hold unresolved checks and obtain qualified advice where needed.

Scope separate client delivery controls

A recurring white-label SOP must specify per-client data boundaries, credentials, branding, entitlements, approval roles, usage records, reports, suppressions, billing inputs, support, incident communications, termination, export, and deletion. The agency owns the service experience but cannot contract away responsibility for its claims or outreach.

Review an available MarketPulse topic, saved ICP and actual preceding-24-hour matches for the approved research purpose. Keep uncertain company context visible. AIMEE can organize supplied context through configured tools; named owners approve actual exports, messages, audience uploads and CRM writes.

AIMEE can prepare a review brief through configured connected tools. Keep proposed actions separate from actual approvals and destination acknowledgements. Confirm the implementation and permissions before execution.

Treat intent, identity, and match signals as probabilistic evidence – not proof of identity, need, authority, consent, or purchase intent. Before deployment, require human, product, pricing, privacy, security, compliance, legal, and platform-policy review of the configured offer and workflow.

The durable SOP is not the longest document. It is the smallest complete operating contract that makes work executable, evidence portable, exceptions visible, and accountability unmistakable across every client.