The decision between buying data enrichment services as a managed engagement and running enrichment through your own API or platform comes down to one question: who owns the workflow after the first delivery? If you need a one-time cleanup and nobody on your team will touch enrichment again for a year, managed delivery is reasonable. If enrichment feeds an ongoing motion, prospecting, CRM hygiene, segmentation, signal-driven outreach, then buying a file every quarter means renegotiating your own operating cadence with a vendor's project calendar. The rest of this article gives you a way to compare the two honestly, including a statement of work template and acceptance math you can reuse in any evaluation.
Three purchasing models, three different obligations
Managed enrichment services are a real and distinct category. Vendors such as Blackbaud sell enrichment as a service engagement rather than as software you operate (Blackbaud). You send records, the vendor's team runs its process, and you receive a file back. The obligation you buy is a deliverable.
An enrichment API inverts that. You buy per-call access to matching and data retrieval, and your engineers own everything around it: queuing, retries, field mapping, dedupe, error handling, and delivery into the CRM. The obligation you buy is uptime and response quality per request.
A workflow platform sits between the two. You still own the objective and the acceptance rules, but the platform runs the orchestration: discovering records, enriching them across multiple providers in a waterfall, verifying fields, and streaming structured results into the systems where your team already works. AstroFabric supports this third approach through agent-driven data workflows. Your team defines the objective, the agents do the operational work, and the output lands in your own infrastructure.
None of these removes your responsibility for the data. Even a fully managed engagement still requires you to define what a good record looks like, because the vendor cannot know your CRM's field semantics or your suppression rules.
The statement of work template
A failure pattern worth planning for in managed engagements is not bad data. It is an SOW that never defined what "done" means, so the first delivery becomes a negotiation instead of an acceptance check. Here is a worksheet covering the sections that matter. This is a buyer policy framework, not legal advice; have counsel review actual contract language.
| SOW section | What to specify | Common gap if omitted |
|---|---|---|
| Inputs | Exact file schema, row count, unique key per row, PII handling rules | Vendor dedupes or reformats your keys, breaking your ability to rejoin results |
| Outputs | Field list, formats, join key preserved, delivery method and location | You receive a file you cannot merge back into the CRM without manual mapping |
| Acceptance criteria | Field-level rules for what counts as an accepted record, and the evidence required | Every disputed row becomes a judgment call after the invoice arrives |
| Unresolved rows | Whether unresolved rows are returned, flagged with reason codes, and excluded from billing | You pay full price for rows the vendor could not resolve |
| Provenance | Source category, retrieval timestamp, and verification method per field | You cannot audit freshness or explain a field's origin later |
| Delete or return | Deletion or return of your submitted data within a stated window, with written confirmation, and no reuse for other clients | Your customer records persist in a vendor environment indefinitely |
| Timeline and revisions | Delivery date, one revision cycle for rows failing acceptance, dispute window | Rework has no defined path and stalls |
The provenance section deserves emphasis. The W3C PROV-O model describes provenance in terms of entities, activities, and the agents responsible for them (W3C PROV-O). You do not need a standards-compliant implementation; you need the practical equivalent: for each enriched field, what produced it, when, and from what kind of source. A simple field ledger inspired by that structure, one row per field per record with source category and timestamp, is enough to audit a delivery. See data provenance for how this applies inside a continuous workflow.
Worked example: acceptance math on an illustrative pilot
Illustrative example with invented numbers; do not treat any figure as a market rate or a real vendor bid.
Suppose you pilot a managed engagement with 5,000 company contact rows. Your acceptance criteria: an accepted record has a verified business email, current employer confirmed within the last 90 days, and a per-field provenance timestamp. The vendor proposes an illustrative $0.40 per accepted record, unresolved rows unbilled.
The delivery comes back: 4,600 rows returned with data, 400 returned unresolved with reason codes. You run acceptance checks and 3,910 of the 4,600 pass. The remaining 690 fail, mostly on missing employer confirmation dates.
- Billed: 3,910 accepted × $0.40 = $1,564
- Unbilled: 690 failed + 400 unresolved = 1,090 rows
- Effective acceptance rate: 3,910 ÷ 5,000 = 78.2%
Now compare a per-submitted-row proposal at an illustrative $0.30: 5,000 × $0.30 = $1,500. Slightly cheaper on paper, but you would have paid for 1,090 rows that never met your bar, an effective $1,500 ÷ 3,910 = $0.384 per accepted record before any separately negotiated rework or service credits. The submitted-row offer is cheaper for the same accepted output in this example. Either pricing model can include acceptance rules and remedies; compare those terms, the operating work and total cost before choosing. That is one of the highest-leverage moves in an enrichment purchase: specify what counts as an accepted record before you compare proposals.
Tradeoffs and failure handling
Managed delivery trades control for convenience. Strengths: no tooling to operate, a single accountable party, useful for infrequent projects. Weaknesses: latency between deliveries, records that age in a file before anyone loads them, and change requests that reopen the SOW. The failure mode to plan for is drift: a quarterly refresh means records in your CRM can go up to three months without re-verification between cycles. For recurring managed work, agree a refresh cadence and a change process that fit the use case. A managed service can support ongoing work when its contracted delivery meets those needs.
An API trades convenience for control. You can enrich in real time, but you now maintain integration code, provider fallbacks, and monitoring. The failure mode is silent degradation: a provider's match rate slips and nobody notices until pipeline quality drops. Handle it with the same acceptance checks you would impose on a vendor, run continuously against your own calls.
A platform trades some low-level control for orchestration you do not have to build. The failure mode is misconfigured objectives: if your definition of a qualified record is vague, agents will faithfully produce records against a vague standard. Handle it the same way as the SOW: write field-level acceptance rules first, then point the workflow at them. This model tends to fit teams running continuous prospecting motions, because the data infrastructure behind prospecting has to refresh and verify records on the cadence of the pipeline, not the cadence of a contract. Whatever model you choose, you keep ownership of definitions, suppression rules, and maintenance of the target schema.
Conditional recommendations
- Choose managed delivery when the work is one-time, your team has no capacity to operate tooling, and a quarterly-or-slower refresh cadence is acceptable.
- Choose an API when you have engineering ownership, need enrichment embedded in your own product or internal systems, and can monitor quality yourself.
- Choose a workflow platform when enrichment is continuous, results must land in your CRM and operational tools automatically, and you want to change matching logic without renegotiating a contract. See data enrichment for the underlying concepts that apply across all three.
FAQs
What should count as an accepted record? A record that passes field-level rules you wrote before the pilot: required fields present, verification method stated, evidence fresh within your window, provenance attached. Everything else is unresolved, and your SOW should define whether unresolved rows are billed, returned, or reworked.
Is a managed service better than running a platform? Neither wins in the abstract. Managed delivery fits infrequent, bounded projects. A platform or API fits continuous motions where records must stay fresh inside your own systems and logic changes weekly, not per contract cycle.
What happens to my data after the engagement ends? Whatever you negotiated. A sensible buyer policy: deletion or return within a stated window, written confirmation, and no reuse of your records for other clients. Treat this as procurement hygiene and have counsel review the actual terms.
Next step
Write your acceptance criteria before you talk to anyone. Then, if your enrichment need is continuous rather than one-time, start with AstroFabric and run those same criteria as the objective for an agent-driven workflow that delivers verified records into your own systems.
Sources
Every playbook on this blog ships as a runnable mission.
Open a workspace and the playbook library is waiting - describe the outcome and the agents carry it end to end, on your plan's monthly credits.