How we work
Four steps, in this order, every time. Nothing gets built until step two produces a workflow map you recognise as your own process. This page is the version we would want to read before signing something.
Timings below are typical for a first workflow. A wider program runs the same four steps per workflow, not one long phase.
01
Week 1
We watch the actual queue, with the people who run it. Not a requirements workshop, not a survey, screen shares with coordinators and billers while they do the job. The documented process and the real process are never the same document, and the gap between them is where the automation opportunity lives.
What we need from you
What you get
A written account of how the work is really done, including the variations between people. Several clients have said this document alone was worth the week.
02
Weeks 2 to 3
Every step gets hours attached to it, so the decision about what to automate first is arithmetic rather than opinion. This is also where we standardize: if two people handle the same payor differently and only one gets approved first time, we settle that before any of it is encoded. Automating an unstandardized process just industrialises whichever version happened to get written down.
What we need from you
What you get
A costed workflow map, a recommended first target chosen on volume and stability rather than on how loudly it is complained about, and a written baseline. The baseline matters twelve months later when someone asks whether this was worth it.
03
Weeks 4 to 10
One workflow, in production, in weeks. It runs alongside the manual process first, so you can compare outputs before anything depends on it. The people who built it stay on the call. There is no handoff to an implementation team you have not met. No twelve-month program before anything works.
What we need from you
What you get
A working automation handling real volume, with logging you can inspect and an escalation path for the exceptions it declines to touch.
04
Ongoing
Documentation, logging and escalation paths your team owns. Rules live in configuration rather than code, so a payor policy change is an edit your staff can make, not a release you have to buy. If we disappeared, the system would keep running. That is the actual test, and we would rather you apply it early.
What we need from you
What you get
Runbooks, configuration documentation and a named contact for breakage. Payor portals change on nobody’s schedule but their own, so breakage is a certainty to plan for rather than a failure to be surprised by.
Commercials
Three shapes cover almost everything. We will tell you which one fits after step one, and we have talked people out of the larger one more than once.
Fit
A teardown sometimes ends with a recommendation not to hire anyone. Four situations where that is the honest answer.
The process is about to change anyway
A system migration or payor contract change inside the next two quarters means you would be automating something that is about to stop existing. Wait.
The volume does not justify it
Some workflows are genuinely annoying and genuinely small. If the arithmetic in step two does not clear, we will show you the arithmetic rather than the proposal.
Your vendor should be fixing it
Sometimes the workaround exists because a system you already pay for is underconfigured. Automating around it makes the underlying problem permanent.
Nobody internal can own it
If no one will hold the workflow after handover, it will quietly stop being trusted within a year. That is a staffing decision to make before the build, not after.
Step zero
Before step one there is a teardown: thirty minutes on your workload, and a one-page map of what is automatable ranked by hours recovered per week. Yours to keep either way.