Reference · 12 August 2026

White Glove, end to end

From the click that buys it to a working product. Replaces part 3 of the 11 August tech-stack document — that one was a list of jobs; this is the whole road, including the half that happens after the first booking.

Ken's question: "How much of that has to be done by a human? What are those factors? … I can't say what the prices are without knowing this."

Every line below was read out of the code on 12 August. Where nothing could be verified, it says so rather than filling in a number. The headline has not changed: the hours are still unmeasured. What changed is that the list is now longer, and four of the new items make the number bigger.

What changed since 11 August

Net: the system got better, the estimate got worse — because four things came into view that were not on the 11 August list.

The road, stage by stage

"Who can do it" is the column that decides cost. A step a VA can do and a step that needs the person with the server password price completely differently.

After the first booking — the half that was missing

This is where the product either works or doesn't, and none of it has run end to end for a paying customer.

The four things that make this bigger

1A new client's CRM is built empty — and the rebuild is not on the board

GHL_CLIENT_SNAPSHOT_ID is unset, so a new sub-account is created bare: no workflows, no pipelines, no custom fields. All six accelerants ship with an empty snapshot id too, so the bolt-on loader correctly resolves to "nothing to do."

Both are technically working as designed. The consequence is not: every workflow, pipeline and field a client needs is built by hand, in the GoHighLevel screen, for every client we sell.

And it cannot be automated later either

GoHighLevel has no workflow API at all — not to create one, not even to read one. Funnels, websites and pages are read-only. This is not a build we have not got to; it is a build no agent can ever do.

It is also not one of the six steps the build board counts. The board shows "Accelerant templates applied ✅" when the loader ran and found nothing to load. The most expensive manual job in the process is invisible on the page built to count manual jobs.

The single biggest cost lever we have

Build the base snapshot once, by hand, in the screen. Every future client then gets it in seconds. That one job converts an unbounded per-client cost into a one-off — and it is currently recorded on the board only as a question that was answered, not as the lever it is.

2Three by-hand steps need a developer, not a VA

This is the staffing answer, and it changes the rate rather than the hours.

Step	Why it is not VA work
Point the number at Josh	NUMBER_TO_INSPECTOR is a hard-coded map in the code. There is no env override. A new client's number means a commit, a merge to main, and a deploy.
Issue the portal login	INSPECTOR_PASSCODES is a server environment variable — SSH, edit, pm2 restart.
Any change to Josh's brain	bot.py does not auto-deploy. Copied to the server by hand, then pm2 restart austin-voice.

The GHL build above is the other side of it: not developer work, but not unskilled work either — somebody who knows GoHighLevel well, doing the same build repeatedly. Two different rates, and neither is the one usually assumed when people say "white glove setup".

3The after-booking half has never been proved

Written in the code itself: "the whole chain after a booking — does the stage fire, does an email go, does the link arrive, does a card actually charge — has never been run end to end."

It is blocked on a step only the client can do: connect their own Stripe inside their own GoHighLevel. Nobody has. Until one does, we do not know how long that step takes, how much hand-holding it needs, or what breaks after it.

For pricing this counts twice. It is unmeasured labour, and it is the stage that gets our clients paid — the thing Ted does by hand today, and the clearest single thing this product does for him.

4The board that counts the work currently shows nothing

The build board lists accounts whose status is exactly submitted. In the live store today, none is.

Account	Status	On the board?
gc — Chad	draft	no
qhi — Ted	active	no
three test records	draft	no

So the board reads zero accounts, zero steps, zero hours — while two clients are live. Two separate reasons, both worth knowing:

• active is treated as finished everywhere else. The function used by Josh's brain — and by the go-live gate inside the same file — accepts both submitted and active. The list filter is stricter than the gate two functions below it. One-line fix, left as a decision rather than a tidy-up because it changes what Ken sees on a page he reads.
• Neither real client came through this pipeline. Chad and Ted were set up before any of it existed. Nothing about their setup was ever timed, and it cannot be reconstructed now.

That second point is why this cannot be closed from a desk: the first real measurement can only be the next client.

What is genuinely automatic now

Four stages, and they are real — so nobody should double-count them as labour:

1. Enrolment and payment, including the acknowledgment record with version, timestamp and IP.
2. Their own CRM sub-account, created on submit, with the guard that stops a re-submitted form creating a second one.
3. The accelerant ledger — what was applied, what failed, what still needs sending. Failures retry; successes are never re-sent, because loading a snapshot twice sends every one of that client's customers two of every email.
4. Josh's brain. The moment the form is submitted, their prices, hours, service area and services are what he says on every call. No hand-off, no config file, no deploy.

The last one is the one people underestimate. The thing that used to be the whole job — teaching the receptionist the business — is now free and instant.

The number still missing, and the cheapest way to get it

There are two numbers hiding under "how long does a client take", and mixing them up is what has kept this open.

What could not be verified from here

• What we pay per hour, for any of the three kinds of person above.
• How long a GHL base build takes. Nobody has done one on this pipeline, so any figure would be invented.
• How long a port actually takes. The procedure is written; no port has been run start to finish and timed.
• Telnyx's two open answers — does the TeXML app attachment block a port-out, and whose name are the numbers in. Both are live rejection codes.
• Whether the support alert email fan-out is switched on. There is no server-side email sender in this repo at all; the alert posts to a webhook that has to be configured. If it is not set, tickets reach Beth's phone and nobody's inbox.