Scripts
Written where the rest of your process lives.
Call scripts are built in MADDOX, alongside the journeys and the playbooks they belong to, and the softphone reads them. A script is more than its words: it carries ordered sections, lines individually marked as must-say or optional with a hint for the rep beneath them, branches that follow the conversation, compliance statements that have to be read, and a list of objections paired with the rebuttal your team wants used for each. All of it travels to the phone together, and the softphone repository is never modified to add a script.
How it works
Authored once, consumed live
The direction of that arrow is what keeps two systems from disagreeing about what a rep should say.
You write it in MADDOX
Scripts are ordinary CRM objects, edited by the people who own the messaging rather than by whoever has access to deploy the phone application. Authoring is open to telephony administrators and to campaign authors, so a sequence author can write the script for their own step without filing a ticket. Every part of the document is shape-checked on save, so a malformed script cannot reach a live call.
Your objection handling travels with it
The section a prospect will care about most is Objections and Rebuttals: each row is the trigger and the answer you want given to it. That list is emitted in both projections — the personalised delivery the phone requests when a call starts, and the template-only library copy the phone caches ahead of time — so the rebuttal is present whether the rep is online or working from the cache. Alongside it travels the compliance list: statements marked as a mandatory read, a consent line, or a recording disclosure.
The rep is tracked through it
Required lines are marked as required and ticked off as they are said. Branches offer the next thing to say based on the disposition the call actually reached. Scripts can also be A/B tested: two variants are weighted, one is chosen per delivery, and each delivery is counted against the variant that produced it, so “which opening works” becomes a number rather than an opinion. Nothing is forced, and nothing is silently skipped.
In the product
The script card, mid-call.
The mechanism
How a script is chosen, and what a rep is actually handed
Two questions decide whether a script is any use on a live call: which one turns up, and what comes with it. Both are answered before the phone rings.
Resolution is a priority order, not a search
Three sources can supply a script and they are tried in a fixed order. The sequence step wins first: if the step names a published script, that is the one. If it names none but carries freeform text, a single-section script is synthesised from that text for this call only. Failing a step entirely, the campaign’s own linked script is used. Failing that, the library is asked for a script matching the call type, preferring the one marked as the shipped default.
Nothing resolves to a guess and nothing throws. When no source matches, the script key on the payload is null — a state the phone can render as “no script for this call” rather than as an empty card that looks like a loading failure. That distinction is the same one this pillar makes everywhere: an absence somebody can act on beats a blank.
Your objection handling is the part worth the trouble
Alongside the sections and lines, a script carries a list of objections — each one a trigger and the rebuttal your team agreed on for it — and that list is emitted in both projections of the script. It is the one thing on this page that no generic call-coaching tool can offer you, because it is not generated: somebody in your business wrote it, and the phone hands it to the rep at the moment the objection lands. Live coaching covers what that looks like on the screen; this page is about where it is written and how it gets there.
Two projections, and the reason they differ
The same document is emitted two ways. The delivery projection is personalised: it runs the render pass once, applies variant selection, records that delivery, and returns both the raw template and the interpolated version, so a consumer can show the finished sentence and still know what the underlying template said. The library projection is the opposite — template only, merge tokens left standing, no personalisation and no delivery recorded — because it exists to be cached by a phone that will interpolate it itself, possibly hours later.
Keeping them separate is what stops a cached copy quietly counting as a delivery. If the library sync also recorded deliveries, a nightly cache refresh across a team would look exactly like everybody making calls, and the A/B numbers underneath would be meaningless.
Adherence is a contract the script carries, or explicitly does not
A script can define how it should be graded: a prompt and a schema, both stored on the script itself. Where neither is set, the payload reports no contract at all rather than an empty one — so “this script is not graded” and “this script scored nothing” can never be confused by whatever reads it. That matters most for the transient freeform scripts, which by construction have no contract and should not be made to look as though they failed one.
A script cannot reach a live call malformed
The structured document is the source of truth, and it is shape-checked on write: every section needs a type, every line needs text, and the objection, compliance, branch and variable lists must each be well formed. Authoring is open to telephony administrators and to campaign authors, so a sequence author can write the script for their own step without waiting on anybody — which only works safely because the validation sits on the write path rather than in the editor.
Who it is for
For whoever owns what the team actually says
Usually a sales leader or an enablement lead, and almost never the person who can deploy the phone software.
- Enablement leads rolling out a new opening across a team.
- Managers who want to know whether the script is being used.
- New reps who need the next sentence more than they need a training video.
Related
Questions
The things people actually ask.
Does changing a script require a release?
No. Scripts are CRM data. The phone reads the current one, so publishing a new opening is an edit in MADDOX rather than a deployment of the softphone.
Are reps forced through the script?
No. Required lines are tracked so it is visible whether they were said, and branches offer the next thing to say. A conversation that goes somewhere unexpected is a conversation, not an error state.
Can the phone edit a script?
No. Scripts are authored in MADDOX and read by the phone. Keeping that arrow pointing one way is what stops the two systems disagreeing about the current version.
How is a script graded afterwards?
Each script can carry its own adherence contract — a prompt and a schema describing what a good delivery of this particular script looks like. A script with neither reports no contract at all rather than an empty one, so “we do not grade this script” and “this script scored nothing” can never be confused. Where variants are running, adherence scores are recorded against the variant that was delivered.
Change your opening line this afternoon.
If that needs a software release, the script does not live in the right place.