AI Softphone
Your best rebuttal, in the rep’s hand while the call is still live.
When a prospect raises the objection your team has heard a hundred times, the rep should not have to remember what works. The trigger phrases your people wrote down and the rebuttals they agreed on are authored in MADDOX and delivered inside the script the phone is already showing them — while the customer is still talking. That is the thing worth crossing the seam, and everything else on this pillar is downstream of it. The AI Softphone is a separate application that places and receives calls; MADDOX is where the context comes from and where the results go. Between them sits an integration API with eleven distinct scopes, so a tenant can issue a key that books appointments without also being able to enumerate an account executive’s calendar. The CRM never dials a phone; the phone never guesses at your data. The rep dials from the record and the call comes back to it, so nobody is retyping what just happened.
In the product
The objection, and what to say next, while they are still on the call.
On the call
What happens while someone is talking
This is the part that is genuinely different. The call is being read as it happens, not filed for review afterwards — and the rebuttals it reaches for are the ones your team wrote in MADDOX. A script delivered to the phone carries its objection list inline: each entry a trigger and the rebuttal your team agreed on for it. Nobody had to guess what good sounds like, because somebody in your business already wrote it down.
Around the call
What decides who gets called, and what happened after
A dialer is only as good as its queue, and a call is only worth making if somebody can tell whether it went well. These three are retrospective on purpose and are ranked below the live path for the same reason: reviewing a call you have already lost is a much smaller thing than changing one you are still on.
The seam
How does the AI Softphone integrate with the CRM?
One page, because integrations are where the honest detail lives and where most vendors get vague. Twenty-five endpoints, eleven scopes, and a deliberate rule about direction: scripts, context and campaigns are read out of MADDOX, and calls, scorecards and appointments are written back into it. Nothing about a call reaches the CRM until the call is over.
The seam
What crosses between the two products, and in which direction
Two applications under one contract only works if the contract is legible. Here is what moves, which way, and when — including the part most vendors leave vague.
Out of MADDOX: everything the phone needs before it rings
Context, scripts and campaign segments are reads. The phone asks who is calling and gets the contact, the company, the buying committee with the answerer flagged, the consent position and the resolved call script — objection rebuttals included — in a single response. It is all pull rather than push, which is why a phone that has been offline comes back current instead of needing a replay.
Into MADDOX: what the call turned out to be
Call results, per-agent rollups, booked appointments and contact corrections are writes. They are what turns a call into a record: an activity on the timeline, numbers on a scorecard, a meeting with an opportunity attached. Each sits behind its own scope, so a key that files call results cannot book a meeting and a key that pushes rollups cannot read a script.
The CRM never dials, and click-to-call is not an exception
Clicking to call in MADDOX posts a dial intent to your tenant’s own registered dial URL with a bearer token. Your softphone decides what to do with it, routes the call to whichever client the agent has open, and pops its own confirmation. MADDOX does not open an audio path, and there is no mode in which it does.
The failure modes are named rather than collapsed into an error. Five outcomes: accepted; no softphone online; no softphone but a web dialer URL to open instead, with the number and context already appended; an agent identity the softphone does not recognise; or a transport failure. A dial click never crashes the page and never silently does nothing, which is the whole reason the outcomes are enumerated instead of thrown.
Nothing about a live call reaches the CRM while it is live
This is the honest boundary and it is better stated than discovered. MADDOX has no live-call channel: the live coaching workspace runs in the phone, and the CRM’s entire participation in a call in progress is the one request that fetches context and the script. Everything else — the transcript, the score, the dispositions — arrives once the call is over. What MADDOX contributes to the live moment is the material it sent before the call started, which is exactly why the objection rebuttals travelling in that payload are the thing worth understanding on this pillar.
Questions
The things people actually ask.
Which VoIP providers or phone systems does this work with?
MADDOX itself never dials — the AI Softphone is a separate application, and the two meet over an integration API with eleven distinct scopes. That is deliberately an open seam rather than a fixed provider list: anything that can hold a call and speak that API can send calls into the record and read context back out. If you have an incumbent PBX you want to keep, that is the conversation to have with us directly rather than a compatibility badge on a page.
Can I make calls inside the CRM?
No, and no page here will suggest otherwise. Calls are placed and received by the AI Softphone, which is a separate application. Click-to-call in MADDOX posts a dial intent to your tenant’s configured dial URL and reports one of five outcomes: the softphone accepted it, no softphone is online, your web softphone is opening instead, the agent identity is not recognized, or the connection failed. A click never crashes the page and never silently does nothing.
Where do the rebuttals come from?
From you. A call script in MADDOX carries an objection list alongside its sections and its required lines, and each entry pairs the trigger with the rebuttal you want used. That list travels with the script in the same payload the phone fetches when the call starts. It is not a generic library and it is not generated: editing it is an edit to your script, made by whoever owns your messaging.
What stops a phone integration reading everything?
Scopes. There are eleven distinct ones, and a key carries only what it was granted. A key that ingests calls cannot enumerate calendars, and a key that books appointments cannot read your pipeline. The assessment scope is deliberately separate from the ingest scope for the same reason: a worker that enriches calls the CRM already owns should not thereby gain the ability to create them.
Does the AI take actions on the call by itself?
No. It listens, scores against the rubric, flags objections and surfaces suggested responses. A person decides what to say and a person says it. Nothing is sent, booked or committed without someone doing it.
What happens to a promised callback?
It becomes scheduled work rather than a note somebody has to remember. Callbacks are scheduled in the contact’s own timezone by construction, which removes the single most common way a promised callback is missed.
See an objection get handled while it is still live.
It is the fastest way to understand the difference between reviewing calls and coaching them.