Evaluate a Service Provider’s Process, Not Its Tools

Buying a research service is not the same decision as buying the software its staff use. A service can look sophisticated in a tool demonstration while delivering poorly sourced records, inconsistent review and difficult corrections. Evaluate the process that will produce your deliverable, including the handoffs between people.

Start with one representative work item and follow it from request to correction. Ask the provider to demonstrate its process using synthetic or otherwise authorized material. You do not need access to its entire internal system, and a polished tool stack is not a substitute for an inspectable result.

Define a service outcome that can be reviewed

Suppose the proposed service researches business accounts for an operations team. A reviewable outcome might be a short account note containing a verified organization identity, two relevant observations, source references and explicit unknowns. “High-quality leads” is too vague to evaluate because the provider and buyer can silently mean different things.

Agree which mistakes require correction, which findings can legitimately remain unknown and who accepts the delivery. Separate research scope from contact activity. Permission to research an account does not authorize the provider to message its employees or add them to a campaign.

The W3C PROV overview describes provenance in terms of entities, activities and responsible people. That distinction is useful here: inspect the output, how it was produced and who reviewed it. The following scorecard is an editorial example, not a W3C certification.

A fictional process-quality review

Buyer Rowan evaluates the invented service Cedar Desk using six synthetic account cases on 16 November 2026. This is a diagnostic exercise, not a statistically representative audit. The completed review records the following findings.

1. Request intake, acceptable: Provider coordinator Nia restates the requested operating entity, geography and research purpose. Case S-3 deliberately contains a parent company and a local subsidiary. The provider asks which entity matters rather than guessing. Evidence: fictional intake record IN-6.

2. Source handling, conditional: Five cases include a source reference beside each observation. S-5 includes a distributor directory whose reuse conditions have not been established for client delivery. Nia excludes that material pending permission review. Evidence: fictional source log SL-6. Condition: no redistribution until the source-use question is resolved.

3. Quality review, defect found: A second reviewer checks all six cases against the agreed acceptance criteria. S-2 attaches an expansion announcement to the wrong similarly named business. The review catches the error before delivery. Evidence: fictional review record QA-6. Required improvement: add an explicit entity-anchor check before an observation is attached.

4. Access, acceptable for the exercise: Work uses the approved synthetic pack and a restricted delivery folder. No personal inbox, production CRM or contact credentials are requested. Evidence: fictional access schedule AS-1. Any later live-system access requires its own scoped approval.

5. Correction handling, acceptable with a condition: Nia replaces the incorrect S-2 observation, marks the original version superseded and explains the reason. The corrected packet identifies its version and reviewer. Condition: apply the same correction notice to all recipients of an affected real delivery, using the agreed communication process.

6. Handoff, incomplete: The final packet names the provider's delivery owner but not the buyer's acceptance owner. Rowan is assigned that role before further evaluation. Delivery is not automatically acceptance.

The review outcome is “continue a bounded service evaluation after the entity check and acceptance ownership are documented.” It is not “six good records prove the provider is reliable.” In fact, discovering and correcting the deliberately testable identity problem is part of the evidence about the process.

Ask for correction mechanics, not perfection promises

A provider that promises zero mistakes gives you little operational information. Ask how it recognizes an error, distinguishes an error from a changed request, identifies affected deliveries and communicates a corrected version. Request one synthetic example that follows the entire correction path.

Also ask what happens when the normal reviewer is unavailable. A process dependent on one unnamed expert may not survive absence or increased workload. The answer need not be a large team; it needs clear responsibility and an honest capacity limit.

Reject the wrong kind of proof

A counterexample is a provider offering a live CRM login to demonstrate “transparency.” If the evaluation only needs sample outputs and review records, that access adds risk without answering the process question. Ask for an appropriately redacted demonstration instead. Do not request customer records as evidence of competence.

Finally, compare service terms with the observed process. If source verification, correction or second review was shown only as a special demonstration, establish whether it is included in the proposed service. The buying decision should rest on the deliverable and responsibilities you will actually receive, not the tools displayed during a sales call.

Continue with Prepare a Sales Demo Around One Confirmed Workflow or Build a Small Reference Library for Evidence-Based Selling.