How billing works
A plumber pays for a booked job, not for a visit: one charge when a real outcome happens, nothing when it does not. This page defines the unit precisely.
A price on this page is charged only for a verified action. The gateway at frontlatch.com/mcp answers, and its do tool has one wired path for a job: a business that has claimed its listing and switched an action on for email-confirm routing gets a pending, logged attempt and an emailed job card the owner accepts or declines. (do can also create a sign-up on a site whose owner switched that on and registered their own endpoint, after the user confirmed in chat; that is not a job and is not what this page prices: a sign-up the owner’s endpoint confirms is counted as a verified action but sends no usage event, a decision of 10 Oct 2026 to revisit when live billing is switched on. Where Frontlatch fills the site’s own form instead, a page saying the account was created is reported as unverified and is never billed.) Until a business confirms a job, no action is verified and nothing bills.
The confirm step is built and runs against the same database as the console: an emailed job card with Accept and Decline buttons, a signed receipt and a verified entry in the owner’s log. It runs only once a business confirms a real attempt happened. Nothing is charged until an owner has confirmed a real completed action.
The unit: a verified completed action
Three words, each doing work.
- Verified
- The business owner has seen this action, approved it, and set the terms: the hours it may run, how many an agent may create in a day, which fields an agent may fill, and where they get notified. Until that has happened the action exists only in test mode, and there is no path around it.
- Completed
- A real outcome happened at the far end, a booked job, a submitted quote, an appointment made. Not an attempt. Not a page view. Not an agent reading the catalogue and deciding against it.
- Action
- One entry in the site’s Action Graph, with its inputs, its declared rules and its stated consequences. Not a session, not a conversation, not a lead.
Duplicates do not count. Attempts do not count. A failed action does not count, and neither does an action an agent started and abandoned.
Which lines in the ledger are ever charged
- An attemptNot billedAn agent reads the catalogue, or starts a form, and no real outcome happens at the far end. Free, and arguably the most useful line in the report.
- A duplicateNot billedThe same outcome logged twice, a retry, a double submit, two agents sent by the same person. Counted once, where it was first logged, never twice.
- A verified completed actionBilledOne real outcome, on an action the owner verified: a booked job, a submitted quote, an appointment made. Logged, replayable, and the only kind of line with a charge behind it.
The half that is built: what "verified" means in code
The billable unit begins with a gate, and the gate exists. It lives in the schema package rather than in a service, deliberately, so the rule and the data shape it checks ship and version together, a service cannot end up gating on a stale idea of what verified meant.
It refuses everything that is not a positive, fully-evidenced yes. It never trusts a status string; it re-derives permission from the confirmation record every single time. It takes an untyped value, so a cast at a call site cannot satisfy it. And every property read on the permission path goes through an own-property check, because an ordinary lookup can find inherited values, which could otherwise grant live execution to an empty object.
For an action to pass, all of this must be true at once: there is a confirmation; it names who confirmed and when; it points at a retrievable audit record; it authorises at least one field; it caps the volume per day as a real positive integer; it names at least one notification channel; and the disclosure the owner acknowledged still matches what the action does today, field for field, including the summary sentence compared byte for byte.
The gate checks the confirmation record, not the attempt. The hours, the daily cap and the permitted fields are recorded and checked for presence, but not enforced, because enforcing them needs the hosted runtime: a clock, a per-identity counter and the proposed payload. Until then, a clean result from the gate means "the owner consented to this action", not "this attempt is within bounds".
How a completed action is counted, deduplicated and replayed
Every verified action is counted once, attributed, receipted and open to dispute. Where a build status matters, it lives on the roadmap.
| Concern | How it works |
|---|---|
| Counting | One record per completed action, attributed to the agent identity where the agent offers one, and to the business it ran against. |
| Duplicates | The same outcome created twice, a retry, a double submit, two agents sent by the same person, is one billable action, not two. |
| Replay | Every executed action logged so it can be replayed. An argument about whether a booking happened is settled by the record rather than by opinion. |
| Dispute | An owner who says an action did not really happen can reverse the charge, within a fixed window after confirming. |
| Notification | The owner is told every time an action fires and asked to confirm it happened, on the channel they nominated when they approved it. An authorisation with no notification channel is refused by the gate today. |
Why attribution is settled by the record
Per-action pricing has one obvious failure mode and it is worth naming rather than discovering: a dispute about whether an action really happened, or whether it was already going to happen anyway. That risk is one we have written down ourselves, and the answer designed against it has three parts.
First, the action was approved in advance, with the approval stored as data rather than as a tick in a settings screen. What the owner agreed to is retrievable, including the exact sentence they read.
Second, the agent is identified where it offers identification. The Web Bot Auth headers are the current mechanism, and note carefully what today’s code does with them: the tracker detects those headers and does not verify the signature. The claim available right now is "this request presented a signed agent identity", not "this is a verified agent". Verifying the signature is work that belongs with an executing layer, where it would actually matter, and it is not done.
Third, every execution is logged and replayable. Not summarised, replayable. The point is that a disagreement between a business and us has an answer that neither of us writes on the day.
What is never billable
- The scan. It is free, and the fix list that comes with it is the whole list, nothing is held back for a paid tier.
- The tracker. Free forever. There is no account and nothing to buy at the end of it.
- An attempt. An agent that tried and could not finish costs nothing, and it is arguably the most useful thing in the report.
- A duplicate of an outcome already counted.
- Anything on an action the owner has not verified, because that cannot run at all.
The price
The model, in full, lives at /pricing: a flat monthly fee as the always-on spine, then a flat fee per verified completed action for trades, property and legal. Health pays no per-action fee right now, the monthly carries it until there is real volume. Never a percentage of what the job is worth.
The charge is meant to sit under what a business already pays for a lead in its own trade, and it only ever applies to an outcome that happened.
If the model does not work, Frontlatch stops it rather than quietly repricing it. The conditions for stopping are written down and dated before launch, and they are read against measured numbers.