Designing a certification intake pipeline

An intake form for certification work is a data model wearing a questionnaire as a costume. If you design it as a questionnaire — a list of things to ask, in the order someone thought of them — it will work for a handful of files and then quietly become the reason your operation cannot grow.

The difference shows up in a specific way. A questionnaire produces a document: a set of answers attached to one application, useful once. A data model produces facts: discrete, typed, validated pieces of information about a business, each stored in one place, reusable across the application, the renewal, and every future question anyone asks about that client.

This is written for operators building intake for many clients: agencies, telehealth platforms, MSOs, compliance teams handling a portfolio. A single business gathering its own information for its own filing does not need any of this; a shared document will do.

Start from the facts, not the form#

Before writing a single question, list what you need to know about a client. Legal entity and trading names. Ownership and control. Where they operate and under what licences. What they sell, and in what categories. Who provides clinical oversight. Which pharmacy or supplier relationships exist. Which domains, checkout flows and customer-facing policies belong to them.

Each of those is a fact with a type, a source, and a lifespan. Some are stable for years. Some change quarterly. Some are single values, some are lists, and the lists are where intake usually falls apart, because a form designed for one medical director handles three badly.

Design the store first: what each fact is called, what shape it has, what makes it valid, and how long you trust it. Then design the form as an interface to that store. The form can change freely afterwards — reordered, split, translated, replaced by an API — without touching what you know about the client.

That separation is what makes the intake reusable at renewal. If your answers live as a document, next year's renewal starts from a blank page. If they live as facts with timestamps, it starts from a diff.

One fact, one field#

The most common defect in a home-grown intake is asking the same thing more than once in slightly different words, usually because different sections were written at different times.

The consequence is not just client irritation. It is two answers that disagree, no rule about which wins, and a reconciliation job that lands on whichever reviewer notices. At volume that is a steady drip of avoidable work, and worse, it is invisible in aggregate — nobody logs "spent eleven minutes deciding which business address was real".

Every fact gets exactly one authoritative field. If two parts of the process need it, they read the same field. If a later step needs a differently-shaped version of the same fact, derive it rather than re-asking. Derivation is deterministic; re-asking is a coin flip.

This also gives you a clean answer to the update question. When a client tells you in March that their medical director changed, there is one place to record it, and everything downstream that references it is now correct.

Branch, do not bloat#

The pressure on any intake is to cover every case, which turns into a form that asks everybody everything. That is how you get a client selling a single product category answering fourteen questions about a service they do not offer.

Conditional structure fixes this, and it is cheap once the data model exists. Ask the small set of questions that establish the shape of the business first — what they sell, how it is fulfilled, whether clinicians are involved, whether a pharmacy is involved — and let those answers determine which sections appear.

Two rules keep branching from becoming its own mess:

• Branch on facts you have already validated, never on free text. A branch that depends on how a client described themselves in a paragraph will misfire, and the misfires are silent.
• Make the branch visible. A client should be able to see that a section was skipped and why. Otherwise the first person to review the file cannot tell the difference between "not applicable" and "not answered", which are very different states.

The second distinction matters more than it sounds. Most intake systems collapse them into an empty field, and every empty field then has to be individually investigated.

Validate where the answer is created#

A validation rule that runs during review is a rejection. The same rule attached to the field is a correction. The rule is identical; the cost differs by an order of magnitude, because at the field the client is present, focused, and has the source material open.

Validate structure at the field: formats, required combinations, dates that must be in the future, entity names that must match across documents. Validate coherence at section boundaries, where you can compare answers to each other — a business that says it does not involve clinicians but names a medical director has told you two incompatible things, and the moment to raise that is immediately.

Leave judgement for humans and leave it until later. The point of front-loaded validation is not to eliminate review. It is to make sure review is spent on questions that require experience rather than on catching an unsigned PDF, which is the split argued in pre-submission QA at scale.

Half-finished is the normal state#

An intake that only exists on submit is an intake that loses work. Clients start these forms, hit a question they need a colleague to answer, and close the tab.

Persist every answer as it is given. Make the saved state resumable from a link without a password ritual that guarantees nobody comes back. And represent partial completion honestly on both sides: the client sees which sections remain, your team sees a file whose status names the outstanding items rather than saying "intake incomplete".

That last point is the one that changes throughput. "Waiting on client" is not actionable. "Waiting on client: pharmacy relationship section and two licence uploads" tells an operator exactly what to chase and lets the chase be automatic, which is the mechanism described in document collection is the real bottleneck.

Expect several people to contribute to one intake, too. The person who knows the corporate structure is rarely the person who knows the fulfilment arrangements. Group questions so a section can be handed to a colleague without handing over the whole form.

Version what you asked#

Intake designs change. You add a question because a file went sideways without it, you reword one that kept being misread, you split a compound question that produced useless answers.

Once that happens, a stored answer is ambiguous unless you know which version of the question produced it. "No" to a question you rewrote six months ago may not mean what "no" means today.

Stamp every submission with the intake version, and keep the old versions readable. It costs almost nothing at build time and it is the difference between an audit trail that answers questions and one that merely proves something was collected.

Forms are one interface, not the only one#

For direct clients, a form is the right interface. For partners sending you volume — a platform onboarding its merchants, an acquirer routing applicants — a form is a tax you are charging them to retype data they already hold.

If the intake is a data model, the second interface is nearly free: the same fields, the same validation, accepted programmatically instead of typed. The trade-offs between the two are worth thinking about before you have committed to one, which is covered in API intake versus forms for partner submissions.

Every step downstream inherits the intake's quality#

A good intake pipeline is unglamorous engineering: named facts, one field each, conditional structure, validation at the point of entry, resumable partials, versioned questions. It is also the single highest-leverage thing an operator can build, because every downstream step inherits its quality.

If you would rather not build it, that intake is what the VeriScripts platform already is — structured client intake, branching by business model, field-level validation, per-item document requests and an API for partners who send volume. And if you need one application prepared rather than a pipeline designed, our done-for-you service handles the whole file at a published price.