Intent-Data Service SOPs: Roles, SLAs, QA, and Escalation

Who is this for?

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.

1. Define the SOP architecture and work-unit catalog

The fastest route to repeatable client value is 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. This avoids copying an SOP until ten clients have ten subtly different and unmaintainable versions.

2. Assign roles, SLAs, quality gates, and handoffs

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. This resolves the common conflict in which an agency counts exported records while a client counts only sales-accepted records.

3. Use templates and tools that make evidence portable

The best tools are the ones 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.

BrandWell can support a configured signal-to-action implementation. Its workflow methodology describes market mapping, intent signals, TrafficID, enrichment, qualification, dashboards, and routing, while its custom scoping page describes configurable destinations. Treat those pages as a starting point; confirm coverage, fields, integrations, entitlements, and acceptance criteria for each client in writing.

4. Put manual, automated, and white-label work behind the same acceptance contract

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. The common progression is manual discovery, controlled automation of stable work, and white-label delivery after multi-client governance is proven. Regardless of mode, the same output should pass the same acceptance test.

5. Calculate delivery cost by work unit and exception load

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.

BrandWell agency plans range from $2,500 to $5,000 per month, depending on topic count, term, and available contractually scoped topic exclusivity. The current written quote and Order Form control. This is not a public list price or universal quote; the public pricing page uses custom scoping. Confirm modules, coverage, volume, term, topics, any exclusivity, identity or enrichment, integrations, service obligations, and the final price in a current written quote.

6. Measure time to value, quality, adoption, and outcomes separately

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.

Separate sourced pipeline, influenced pipeline, attributed outcomes, and incremental lift. Google’s explanation of Conversion Lift uses treatment and control groups to estimate incrementality. Many agency programs lack enough volume for that design, so report directional evidence without claiming causation the measurement cannot prove.

7. Keep the SOP core stable and vary configuration by client

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.

8. Preserve the chain from signal source to 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.

9. Operate an exception log and formal change control

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.

The FTC’s security guidance recommends retaining only necessary information, controlling access, protecting data, and preparing for incidents. The NIST Privacy Framework provides a voluntary structure for privacy-risk management. Convert those principles into named controls and evidence rather than adding a generic compliance sentence to the SOP.

Activation policies require their own current check. Google’s policy for covered personalized-ad products says third-party data cannot be used to create targeting audiences; review the official data-use policy before routing. Commercial email also needs a checklist: the FTC’s CAN-SPAM guide says there is no B2B exception and identifies sender, subject, address, opt-out, and monitoring obligations.

10. Add tenant isolation and client-visible evidence for white-label delivery

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.

Treat the new BrandWell intent-data offer as a separate agency-reseller product from the legacy BrandWell SEO writer. Where a current reseller agreement permits it, agency-controlled client billing and retail packaging can sit above BrandWell’s approved wholesale scope and usage. Confirm any complete white-label sales-and-delivery engine, topic exclusivity, and $70 seven-day reseller pilot for branded topic reports in the current written quote or agreement. Availability may depend on market, topic, geography, term, conflicts, and enabled modules; do not sell them as unconditional features.

Apply the same gate to agent-ready automation workflow instructions. If included in the approved configuration, BrandWell can provide instructions designed for Claude or ChatGPT, or for direct browser execution through Moxby, a separate product. Confirm supported actions, data permissions, approval boundaries, and Moxby availability. Let agents prepare research, classify records, assemble reports, or propose next steps; require people to approve sensitive data use, outreach, audience activation, material CRM writes, pricing, and client-facing claims.

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.