Running LegitScript applications at volume changes the job

Filing a single LegitScript Healthcare Certification application is a project. It has a start, a middle and an end, and one competent person can hold the whole thing in their head. Filing thirty concurrently is not thirty projects. It is an operating model, and the practices that made the single filing go well are usually the ones that fail first.

This is written for the second case: agencies, telehealth platforms, management services organisations and in-house compliance teams who are responsible for a book of applications rather than their own. If you are getting your own business certified, the mechanics are different enough that most of what follows will not apply.

What actually consumes the calendar#

The instinct is to treat certification as a queue problem — more files in, more reviewers needed. That misreads where the time goes.

Treat review time as outside your control. Nothing you do after submission compresses it, so it is not where your effort belongs. Plan the book on the assumption that the clock after filing is somebody else's, and spend your attention on the part that is genuinely yours: gathering evidence, reconciling what the client says against what their website actually shows, and resolving the gaps before the file goes anywhere.

On a well-run file, that pre-submission work is the majority of the elapsed time. On a badly run one, it is still the majority — it just happens after submission instead, as a sequence of follow-up questions, each with a round trip to the client attached. The rework loop is the same work, done later, at worse odds.

So the throughput question is not "how many applications can we review". It is "how quickly can we get each file complete", and that is a different problem with a different bottleneck.

The first thing that breaks is state, not capacity#

Ask an operator running a dozen concurrent files what each one is waiting on. If the answer involves opening an inbox, the system has already failed — it just has not produced a visible failure yet.

State is the first casualty of volume because it is the thing nobody budgets for. At three files, "what is this waiting on" is answerable from memory. At eight, it is answerable by scrolling. At fifteen, it is not reliably answerable at all, and the symptom is not a dropped file but a slow one: something sat for nine days waiting on a document nobody re-asked for.

The fix is unglamorous. Every file needs an explicit, current status that means one specific thing, and the set of statuses needs to be small enough that people use it honestly. A status vocabulary with thirty entries gets used as free text. One with a dozen gets used as a state machine.

What matters is that the status answers the operational question — who owes the next action, us or them — rather than describing a phase. "In progress" tells you nothing. "Waiting on client: pharmacy agreement" tells you who to chase and what to chase them for.

Batch by stage, not by client#

The natural way to organise the work is by client: Alice takes these six accounts, Bob takes those six. It is easy to explain, easy to staff, and it is usually wrong.

Certification review is repetitive across files and varied within them. A single application asks about clinical governance, pharmacy relationships, website disclosures, payment flows, licensure and advertising. Those are six different kinds of judgement. A reviewer working client-by-client switches between all six, several times a day, and never gets particularly good at any of them.

A reviewer working stage-by-stage reads eight privacy policies in a row. By the third, they are not reading — they are scanning for the four things that are routinely wrong. They move faster and more consistently, because the comparison is right in front of them. That grouping is also what makes a checklist worth maintaining rather than worth ignoring, which is the mechanic behind pre-submission QA at scale.

Client ownership still matters. Somebody has to be the person the client talks to, who knows their history and can answer a question without looking it up. That role does not have to be the same person who does the review work, and at volume it should not be.

Intake is the real constraint#

Here is the uncomfortable arithmetic. If your review capacity is thirty files a month and your intake process delivers complete files at the rate of twelve, your capacity is twelve. Hiring another reviewer changes nothing.

Almost every operator who thinks they have a review bottleneck has an intake bottleneck. The tell is reviewer idle time that does not look like idle time — people busy chasing documents, re-explaining what a "compounding pharmacy agreement" is, and reformatting what came back. That is the case for treating document collection as the real bottleneck rather than as administrative overhead attached to the interesting work.

Decoupling helps more than anything else you can do:

• Ask for everything once, structured. A single intake that collects every document and every answer up front beats five rounds of "and also". Clients respond to one big ask better than to a drip.
• Validate at the door. A missing field caught during intake costs a client thirty seconds. Caught three weeks later, it costs a round trip and a stalled file.
• Make the ask legible. "Upload your pharmacy agreement" gets a better hit rate than "provide documentation of your dispensing relationships", because the client knows what file to look for.
• Let clients work in parallel. Nothing about client A's document gathering needs to wait for client B's review to finish. If your process serialises them, that is a tooling artefact, not a constraint.

Those four points are the outline of a pipeline rather than a set of habits, and the staged version of it — what each stage owns, what it must produce before a file may leave it — is worked through in designing a certification intake pipeline.

What volume buys you, if you record it#

The compounding advantage of running many applications is pattern recognition. You learn which of your own answers tend to attract follow-up questions and which do not. You learn which parts of a file are worth a second pass before it goes out, and which discrepancies your clients keep producing regardless of how the intake is worded. You learn, from your own history rather than from guidance, that a refund policy or a disclosure page is usually the place to spend the last hour before filing.

None of that accrues from memory. It accrues from records — decisions, follow-up questions and outcomes, stored somewhere you can query later. An operator with two hundred filings behind them and no record of what happened in them knows roughly as much as one with twenty.

This is the argument for treating certification work as a data problem rather than a document problem. The documents are the output. The useful asset is the history of what worked.

Where the ceiling actually is#

In our experience, teams running this on spreadsheets, shared drives and email start to see quality degrade somewhere between eight and twelve concurrent files per operator. Not because the work is hard, but because the overhead of reconstructing state consumes the capacity that would otherwise do the work. Your own number will differ with the mix of clients and the discipline of the team; what does not differ is the shape of the curve, which is flat and then abruptly is not.

Past that point you are choosing between three things: hire proportionally, cap your book, or change the system so state is held explicitly rather than reconstructed. The first two are expensive in different ways, and both of them are usually chosen by default, because the third only looks affordable once somebody has counted the hours currently spent working out where things stand.

If you would rather not build that system, the VeriScripts platform is the one our own compliance team files on — client portals, structured intake, a review workflow organised by stage, and a submission step that fills the application from case data rather than from re-typing. And if this is not your problem at all, because you need one application filed rather than a hundred managed, our done-for-you service does exactly that at a published price.