Pre-submission QA at scale

A pre-submission review pass exists to catch the defects that would otherwise become follow-up questions after you file. That is its whole job. It is not a second draft, not a client-facing quality gesture, and not an opportunity to improve an application that is already sound.

Framed that way, the pass has an obvious economic shape. Every defect it catches saves a round trip — a query, a client conversation, a correction, a wait. Every minute it spends on a file with no defects is pure cost. Good QA at volume is therefore mostly about routing: getting the expensive attention onto the files that need it and off the ones that do not.

This is written for teams running a QA step across many concurrent files — agencies, platforms, MSOs, in-house compliance functions. If you file occasionally, the split between completeness and judgement is still worth borrowing; the staffing arguments will not apply to you.

Completeness and judgement are different jobs#

The most common QA design mistake is one pass that does everything. A reviewer opens a file and simultaneously checks that the pharmacy agreement is attached, that it is signed, that it is current, that the entity names match, that the described clinical model is coherent, and that nothing on the client's live website contradicts what the application says.

Those are not the same activity. The first four are mechanical: objective, bounded, either true or false, and checkable by a junior person or by software. The last two are judgement: they require pattern recognition built over many files and they cannot be reduced to a rule.

Merging them degrades both. The mechanical checks get skimmed because they are boring next to the interesting work. The judgement work gets rushed because the mechanical checks ate the clock. And you end up paying senior review rates to notice that a PDF is unsigned.

Split the pass. Completeness first, and a file that fails it does not proceed — it goes back to collection, which is where the defect belongs. Judgement second, on files that are already known to be whole. The reviewer doing judgement work should never be the person discovering a document is missing.

Checklists rot unless you prune them#

Every QA function converges on a checklist, and every checklist decays the same way. An incident happens, an item is added. Another incident, another item. Nothing is ever removed, because removing an item feels like inviting the failure back.

Two years in, the list has sixty entries, roughly a dozen of which have caught anything in living memory. Reviewers stop performing it and start ticking it, which is worse than having no checklist at all, because now the ticks are evidence of a check that did not occur.

The discipline that prevents this is boring and effective: each item has to justify its place. If an item has not caught a defect in a long run of files, it either becomes automatic — a validation rule that runs without a human — or it comes off the list. An item that never fires and cannot be automated is a superstition.

Keep the human checklist short enough that a reviewer can hold it in their head between files. Everything else belongs in software, where a check that never fires costs nothing and a check that fires once a year still runs reliably.

A second reviewer earns its cost only where the first was unsure#

Reviewing everything twice is the intuitive answer to quality at volume, and it is usually the wrong one. On a straightforward file the second reviewer almost always agrees with the first, and you have spent double for a confirmation.

The return on a second reviewer is concentrated in a narrow band: files where the first reviewer was genuinely uncertain, unusual categories or business models, and anything where the client's own answers contradicted each other. Those are identifiable in advance if you let the first reviewer say so.

So make uncertainty a first-class output of the first pass. Not a comment buried in a document — a structured flag that routes the file. A reviewer who can mark "I am not confident about the advertising answers here" and have that mean something operationally will use it. A reviewer who fears that flagging looks like weakness will quietly guess instead, which is the failure you were trying to prevent.

Add a small random sample of unflagged files on top. Not because those files are likely to be wrong, but because sampling is how you find out whether the flagging is calibrated. If the sample keeps turning up defects, your first pass has a problem the flags are not surfacing.

When QA becomes the queue#

At some point the review step becomes the visible bottleneck. Files pile up in front of it, everybody can see the pile, and the obvious remedy is another reviewer.

Before hiring, look at what QA is rejecting. If a meaningful share of rejections are missing documents, half-answered questions, illegible uploads or contradictions the client could have resolved themselves, your QA step is not a quality function. It is an expensive second intake, staffed by your most experienced people.

Those defects cost several times more at the review stage than at the door, which is the argument made at length in document collection is the real bottleneck. The fix is to push the top few rejection causes upstream into validation that refuses the defect when it is created, not when it is discovered.

Do that and the queue often clears without any change in staffing, because the review pass stops handling work that was never review work. If the queue persists afterwards, the volume is real and the honest answer is capacity.

Batch the pass, do not interleave it#

QA benefits from the same batching logic as the rest of the operation. A reviewer running the judgement pass on eight files in a sitting is faster and more consistent than one who reviews a file, answers a client email, reviews another, joins a call.

The comparison is the mechanism. Reading eight descriptions of clinical governance in a row makes the odd one visible immediately. Reading one a day makes each seem plausible in isolation, because there is nothing to measure it against.

This has an organisational consequence people resist: the person who owns the client relationship should probably not be the person doing their QA pass. Familiarity with a client is useful for communication and actively unhelpful for review, because you end up reading what you know rather than what is on the page.

Record disagreements, not just outcomes#

Most teams record the result of a QA pass — passed, corrected, returned. Almost none record what the disagreement was about when two reviewers saw a file differently.

Those disagreements are the most valuable training data you have. They mark the exact points where your standard is ambiguous, which is where your inconsistency across the book comes from. A short structured note on each — what was in dispute, what was decided, why — turns a series of arguments into a house standard.

Over time that record does something a checklist cannot: it tells new reviewers how judgement calls have actually been made here, in cases, rather than as principles. The same logic applies to how intake questions are worded, which is why designing a certification intake pipeline treats the form as a data model rather than a questionnaire.

QA at volume is four disciplines, not more reviewers#

A QA function that works at volume has four properties: the completeness pass is separate and cheap, the judgement pass runs on whole files only, uncertainty routes work rather than hiding in it, and rejection causes flow back upstream instead of recurring.

Building that on documents and email is possible and exhausting, because every part of it depends on state that has to stay current. The VeriScripts platform holds it directly — stage-based review queues, structured completeness rules that run before a human sees the file, reviewer flags that route, and a record of what was decided. For a reader who needs one application prepared properly rather than a review function designed, our done-for-you service is the simpler answer.