Two logos connected by an arrow is not an integration. The integration is the payload, and you should look at a real one before you build anything on top of it.
The order that avoids rework
Build the smallest agent that says one correct sentence, and call it from your own phone before anyone else hears it.
Create the webhook, run one real call, and pin the payload. Do not build against documentation alone.
Read what is there: call id, outcome, duration, the record identifier you sent in, where the transcript lives. Confirm what is missing on a call that failed.
Design the disposition set now. Six outcomes everyone applies the same way beats thirty applied inconsistently, and it is the schema for every report you will ever build.
Assume the same event will arrive twice. An idempotency key derived from the call id, checked before any write — not after, and not generated inside the workflow.
Keep one saved payload per outcome type. They are the fixtures for every change you make later.
The integration is easy. The policy about what a call is allowed to overwrite is what takes a meeting, and skipping that meeting is how somebody says the automation broke their data.
Decide before you build
Field by field: a call can correct a phone number, because the call is direct evidence. It should not touch email, address, or fields sales owns.
Stage changes only on a conversation that met the bar. A no-answer is an activity, not a state change — and an over-eager stage change destroys the funnel report you used to justify the project.
The note is four lines: outcome, what the customer said in their words, next step with a date, link to the recording. A transcript dump is the same as writing nothing.
The matching key, decided before launch. A calling campaign creates duplicates faster than anything else you run, because it touches thousands of records in a week.
Write an audit trail on every automated write: what changed, from what, when, and which call caused it.
Stage changes cascade. Map what a change triggers in your CRM before you let an automation make one.
The routing rule is a commercial decision wearing a technical costume. Write it before launch and get it agreed by the people whose compensation depends on it.
Keep it as data, never as conditions in a node
A location table: id, timezone, transfer target, fallback, CRM owner, capacity. The workflow looks the record up.
Adding a location is a row, not a workflow edit. The moment a phone number appears literally inside a node, you have built the version that breaks at ten locations.
Pick one primary rule — geography, origin, product, round robin — then define the tie-breaks: two locations claim it, the nearest is closed, the customer names a branch. That last one always wins.
Every routing rule needs a default that is a real destination and an alert, never a silent drop. Records that route nowhere are invisible and get found in a quarterly audit, if at all.
Version the table. When routing goes wrong in three weeks, the first question is what it said at the time.
A location is a config, not a build
3 min
This is the single idea that separates an operation that reaches forty locations from one that stalls at eight.
One row per location, and everything reads from it
Identity, telephony, people, hours and capacity, activation status. No location-specific value exists anywhere else — not in a node, not in a script, not in a dashboard filter.
Legitimate variables: name and pronunciation, hours, transfer target, products offered. Never variable: the qualification bar, compliance language, the disposition set, the reporting definitions.
The most common multi-location incident is a location running with another location's transfer number. It happens in the copy step, and it is invisible until a customer is transferred to the wrong town.
A readiness gate one named person can pass: every field populated, smoke test end to end, the transfer target confirmed by calling them, suppression list run.
Build the off switch before you need it. Stopping one location at 4pm on a Friday, operable by someone non-technical, from a phone.
When the rule holds, location forty-one is a row. When it does not, it is a project.
The weeks you cannot buy
3 min
This is the part of the project money does not accelerate, and the part most plans forget until it blocks the launch.
Carrier registration
It gates messaging and is measured in weeks. A rejection restarts the clock.
Common causes: business details that do not match what is publicly verifiable, and consent language that does not describe what you actually do.
Voice can launch while it is pending. Messaging cannot. Plan the rollout voice-first, or the whole thing waits on paperwork with an idle team.
Compliance is built, not written
A suppression table every campaign reads before dialing, without exception.
Consent state as a field, with a date and a source. Recording disclosure where your jurisdiction requires it, and a way to prove it was said.
An opt-out honoured everywhere, immediately, across every campaign and channel. Honoured in one and not another is worse than not having the mechanism, because it proves you had it.
Start this on day one of the project, before you build anything. It is the longest lead time in the whole build and it is pure waiting.
Rules vary by jurisdiction and change. This gives you the architecture; the specifics are a call with your counsel, and it is worth making before launch rather than after.
The failure that hurts most is silent: an event arrives, something is unexpected, the workflow errors, and nobody finds out until a weekly report comes up short.
What actually breaks
The list. Campaigns fail in the first hour on dead numbers, wrong timezones and badly parsed names, in ways that look like a broken agent.
The transfer. A ring timeout with no fallback, or a number that was right last year.
Duplicate events, producing two follow-ups to one customer.
The CRM write, fired and never confirmed.
The human on the other end, who did not know the queue existed.
Three kinds of error, three responses
Retry it: timeouts, rate limits, a service briefly down.
Park it for a human: data that matches nothing, a rule with no answer.
Stop everything: credentials rejected, wrong list loaded, a compliance check failing.
The third needs a kill switch a non-technical person can operate. It will be needed on a day you are not available.
Count what lands in the dead-letter path and alert on it. Zero is a suspicious number — it usually means the alert is broken.
Audit what the agent actually said
3 min
Nobody listens to the calls. The dashboard is green, transfers are happening, and three weeks in somebody hears a recording and discovers the agent has been saying something slightly wrong four hundred times a day.
A routine you will actually keep
Twenty calls a week, at random rather than by outcome. Reviewing only the failures teaches you nothing about the ones that worked by accident.
Score against a short fixed sheet: did it identify correctly, apply the bar, capture the data, exit when asked.
Every escalation and every complaint gets read, without sampling.
One reviewer. Rotating reviewers produce scores you cannot compare over time.
The cost of a scripted error is the error times your call volume. That multiplication is the whole argument for reviewing calls nobody asked you to review.
A campaign nobody audits eventually produces something you have to apologise for.
Calls to cash: one id, end to end
3 min
This is the most common single cause of revenue you cannot prove. Everything else in attribution is downstream of it.
Created at first touch→Sent to the agent→Returned on the event→Written to CRM→On the sale
The rules
Generate it once, at first touch, and never regenerate it. Pass it into the call and require it back on the event.
Store it in a CRM field nothing else writes to, and carry it to whatever books the money — even if that means a text field somebody has to add.
Decide the attribution window, and what happens with multiple calls before one opportunity. Write it with a date, because changing it later changes every historical number.
Report unattributed revenue as its own line. Never distribute it proportionally to make the report look complete.
Audit monthly: what percentage of closed records still carry the original id. That percentage is the ceiling on how much revenue you can attribute.
A report that says sixty percent attributed and names the gap is more useful, and more credible, than one claiming a hundred.
Rather not build it yourself?
We already run this across 28 finance branches.
Same system, installed and operated for you — calling, qualifying and handing leads to your team while you focus on closing.
