Account templates
A template is the shape of a client that is already set up: how many tracked numbers each channel wants, how long a call has to run to count as a conversion, whether conversions are pushed to the ad platforms, and which timezone the reports are measured in. Applying it to a new client saves configuring all of that by hand for the fortieth time.
This page is for agencies. Templates are managed on the Templates screen, which is partner-level — a login that sits on one client account will be told, correctly, that its role cannot manage them.
A template seeds a client. It does not govern one. Applying is a one-time act: editing the template afterwards changes nothing on the clients it has already been applied to, and there is no reconciliation loop that would. That is deliberate. A pool sized for one client's real call volume and a threshold tuned to how long their genuine enquiries run are both better than the template, and an "improvement" that silently rewrote live routing for forty businesses would be an outage with a long fuse.
What a template carries
| Carried | Not carried |
|---|---|
| How many numbers each channel's pool wants, and whether each is a static number, a session pool or the fallback | The numbers themselves. Counts only — see below |
| Pool settings: how long a number is held for a visitor, the safety factor, and whether a click-ID join is preferred over a session pool | Your tag taxonomy, report packs or alert rules. Those are not part of a template today, whatever you may have read on an older version of our site |
| Conversion settings: the qualifying call length, whether conversions are pushed to ad platforms, and the consent posture | Call routing. A call flow is authored per client on the Call flows screen — or copied from another client by cloning, which is not a template |
| The timezone | Anything about billing, users or logins |
Two fields are stored with a template and not applied by it: the default attribution model and the CSV import defaults. The schema carries them so that a template authored today stays valid, but the reporting and import layers still read their own settings, so setting them on a template changes nothing yet.
The eight built-in templates
Seven verticals — home improvement, legal, local services, healthcare, dental, automotive and B2B software — plus a minimal one for a single number and no pooling.
The list on the Templates screen is read from the product rather than typed into the page, so it is always the real set: if a fifth appears there, it exists.
They differ in the things that actually matter per vertical: how long a qualifying call is, whether keyword-level precision is worth paying for, how long a number should be held for one visitor, and which attribution model tells the truth about that buying process. A kitchen enquiry involves measurements and pricing, so a thirty-second call is a wrong number and counting it as a conversion teaches Google to buy more wrong numbers. An emergency plumber's booking takes under a minute, so the same threshold would discard real conversions. The B2B template holds a number for a whole day rather than an hour, because a B2B buyer reads a page on Tuesday, forwards it to two colleagues and one of them calls on Friday — and a number recycled before that call attributes it to whoever the pool handed it to next, which is worse than no attribution at all. It is also the one template that uses a non-geographic 03 number rather than a local one, since a national supplier with an 01242 number is telling prospects something it did not mean to. Built-ins are not database rows — they ship in the code, so they cannot fall out of step with what validates them, and a correction reaches every agency automatically.
Capturing a template from a client you have already set up
Configure one client properly, then start the next one from the same shape. This is the route to take when you want that shape available for several clients to come; if what you want is this client again, with its routing, cloning a client does that in one action and is described on the Client accounts page.
Capture is not a clone, and the difference matters. A phone number belongs to exactly one account and is never copied. Duplicating a number into a second client would produce a configuration that looks like it works and silently attributes one business's calls to another — so capture records the number of numbers each pool wants, never the numbers. Applying the template to the next client therefore tells you how many numbers to buy; it cannot hand you any.
Nothing else is copied by a template either: no calls, no reports, no users, no plan, no billing, and no call flow. So a template alone will not make one client's setup appear whole on another, and we would rather you heard that here than discovered it afterwards.
Cloning a client is what covers the call flow, and it covers nothing else on that list. It reproduces the same pool, conversion and timezone settings a capture would, and it also copies the source client's live flow with every phone number in it rewritten to the new client's own and every opening-hours timezone rewritten too — then saves it as a draft that is not published and cannot route a call, because the greetings and prompts inside it are copied word for word and still name the client they came from. What cloning does not copy is the rest of this paragraph's list plus your alert rules, webhooks, ad platform and CRM connections and API keys, and it tells you how many of each the source has. The full account of cloning is on the Client accounts page.
Capture also reports what it could not express, rather than dropping it quietly. The case that actually happens is a campaign-scoped pool — a pool keyed to one campaign name rather than to a channel. That is a legitimate and cheaper setup, and a template cannot describe it yet, because the template would have to carry a campaign name per client. So the result names the pool keys it skipped, and a template that will not reproduce part of the client it came from says so instead of looking complete.
One website per client is read. Templating uses a client's first website. If a client has three, the plan says so rather than configuring one and leaving the other two inconsistent in a way nobody notices until two reports disagree.
Plan first, then apply
Two steps, and the split is not ceremony. The preview is a read that changes nothing. It shows every setting that would change, from what to what; every pool, what the client has and what the template wants; and the recurring monthly cost of the numbers the template would add.
Applying then writes the settings. It requires you to confirm the monthly cost the preview showed, and it refuses if that figure has moved since you looked — which means something changed in between, and applying anyway would commit money against a number nobody approved.
Applying buys no numbers. It writes configuration and then tells you how many numbers are still needed. Until those numbers exist the pools are empty, so there is nothing for the tag to swap into the client's pages: every visitor sees the real number, and the calls that follow still connect but arrive with no channel against them.
The reason it works this way is that a setting is reversible with one edit and a phone number is not. A number bills every month, and releasing it starts a 90-day quarantine — so that a recycled number cannot attribute a stranger's call to the wrong client — during which it is still billed and cannot be used. Over-provisioning is expensive for a quarter, not until tomorrow. So numbers are bought deliberately, on the Numbers screen, where each one's price is shown.
Where the plan cannot work out a cost it says unknown rather than zero. If you give it a price per number it multiplies; if you do not, it averages what the client already pays and labels the result an estimate; with nothing to average from, it reports nothing. That is on purpose — "£0.00 a month" printed beside 240 new numbers reads as authoritative and is wrong in the direction that costs money.
Planning across several clients at once gives you one combined figure, which is the number worth having: forty plans each reading £18 a month do not communicate £720 a month. If any one of those clients has no price to work from, the combined figure is reported as unknown rather than as a total with eight clients quietly missing from it.
Applying to a client that is already running
Allowed, and worth thinking about first. Settings are merged, never written over the top: a template that sets three fields cannot blank the rest. And extra numbers are reported, never released — a client with more numbers than the template asks for has usually been scaled up for real traffic, and releasing those would break live attribution and start the 90-day clock on numbers you are still being billed for.
Numbers in quarantine do not count towards a pool. They are billed and cannot be assigned, so counting them as capacity would leave a pool short and exhausting in production — which degrades attribution silently rather than erroring.
Drift: how far a client has moved from its template
A report, never a correction. Because a template seeds rather than governs, most differences are somebody's deliberate tuning and correcting them would undo real work. What the report is for is the periodic review — "which of my forty clients is configured in a way I would not choose today" — and for spotting the one that changed by accident. Those two look identical to a machine, which is exactly why this classifies rather than acts.
Three states, and they are not the same fact
| State | What it means |
|---|---|
| Never applied | This client has no pool or conversion settings at all, so no template has been applied to it. Everything "differs", and that is not drift — it is a client waiting to be set up. |
| Applied, matching | Configured, and nothing differs from the template as it stands today. |
| Applied, drifted | Configured, and something differs. Usually deliberate. Occasionally not, and that is the one you are looking for. |
A client with no website yet is left out of the report entirely rather than listed as differing on every field, because there is nothing there to configure.
The honest limit on "never applied". Proofbell records no "template applied" event, so that state means "this client has never had pool or conversion settings", not "this particular template was never used on it". A client you configured entirely by hand reads as applied, and one set up from a different template reads as drifted from this one. The screen says the same thing under the table.
Three severities, rated by what the difference does
Not by how many fields differ. A pool one number short and a qualifying threshold set to zero are both "one field differs", and treating them alike would make the report useless.
- Attention — it silently corrupts measurement or costs money. A qualifying threshold of zero counts every wrong number and immediate hang-up as a conversion, which actively trains bidding toward worthless clicks. Conversion pushing switched off, a click-ID join disabled, a mismatched timezone and an empty pool are all here too.
- Review — legitimate tuning worth a periodic look: a pool that has grown, a different qualifying length.
- Info — cosmetic, or reasonably client-specific, such as an extra channel one client runs and the others do not.
Clients are ordered by what needs attention rather than by how many differences they have, because a client with six harmless extra pools should not sit above one whose conversion pushing has been quietly off since setup.
Who can do what
| Action | Needs |
|---|---|
| See the templates, and the drift report | Reading accounts, at agency level |
| Preview a plan, apply one, capture a template, check a definition | Managing accounts, at agency level |
Both are agency-level permissions. A login whose access sits on one client account is told its role cannot manage templates — that is the configuration working as somebody chose, not a fault, and everything else in the dashboard keeps working normally for them.
What is not built yet
- Applying to many clients in one go. You can plan across many and see the combined cost; applying is one client at a time, after its own plan has been read.
- Editing a template. There is no editor and no route that saves a definition you have written. A template is created by capturing a working client. The screen will check a definition against the schema and tell you what it would cost on an empty client, which is useful for seeing why one was refused, but it cannot save it.
- Enforcement. Editing a template never updates the clients it was applied to, and drift is never corrected automatically. That is a decision rather than a gap — see the note at the top.
- A record of which template was applied to which client, and when. Nothing stores it, which is why the drift report derives "never applied" from whether a client has any settings at all.
- Templating a client's second and third websites. The first is used and the plan says so.
- Campaign-scoped pools. Capture names them and skips them; see above.