A multi-brand B2B retailer takes a large share of its orders by phone. Its call tracking knew where each call came from, and its phone system knew who answered. We connected the two with a low-cost automation that tags every answered call, across all six of its brands, with the name of the rep who took it.
4,000 calls processed · 1 error · ~390 automation operations a day · 6 brands covered
For a lot of B2B sellers, the website isn’t where the sale closes. A buyer finds a product online, has a question about lead times, volume pricing or delivery, and picks up the phone. That call is often the most valuable moment in the whole journey.
This retailer had done the hard part of measuring it. Every brand’s website used call tracking, so each inbound call was tied to the campaign, ad or search that produced it. Leadership could see which channels drove calls, and how many.
What they couldn’t see was what happened next. Once a call reached the sales floor, the trail went cold. There was no reliable way to say which rep answered a given call, and that left two practical problems unsolved:
Before this project, answering either question wasn’t possible at all. The data simply didn’t exist in one place.
The information they needed already existed. It was just split across two systems that had never been introduced to each other.
On paper, that sounds like a simple join. In practice, three things made it hard:
Matching on “the line that rang” would have quietly credited the wrong rep on a meaningful share of calls. For commission questions in particular, a report that’s confidently wrong is worse than no report at all.
Rather than build a data warehouse or a new reporting tool, we built a small, two-scenario pipeline on Make.com. It uses CallRail webhooks, Zoom Phone’s call history and call routing data, and a Make data store to hold calls until they can be matched. It covers all six brands from a single setup.
The moment a tracked call comes in, CallRail sends a webhook to Make. The call is written to a queue in the data store with the details needed later: caller number, time and tracking source. Nothing is matched yet; the goal at this stage is simply to never miss a call.
Every four hours, a second scenario works through the queue. For each call, it looks up Zoom Phone’s call history for the same caller number within a 30-minute window. The caller’s number is the one thing both systems reliably record, and the time window absorbs clock differences without letting unrelated calls slip in.
A matching call in Zoom isn’t enough on its own, because of ring groups. So for each match, the automation reads the call’s routing path in Zoom Phone, the record of every extension it rang and who actually picked up. That’s what identifies the rep who answered, not just the line that rang first.
The rep’s name is written back onto the call in CallRail as a tag. Calls that can’t be matched, such as ones that were never answered, are retried on later runs and then exit cleanly after 24 hours. Nothing sits in the queue forever, and nobody has to clean it up by hand.
The build itself took only a few hours. The hard part was finding the approach.
The tempting fix for two systems with no shared ID is a cleverer join: fuzzy matching, more fields, more rules. That usually makes the logic harder to trust, not easier. The answer here was a stricter rule instead:
Join systems on what they reliably share, and give every record a clean exit.
Caller number and a tight time window are reliable in both systems. The routing path settles who actually picked up. And a 24-hour exit means every record ends in one of two states, matched or expired, so the data store stays clean without anyone babysitting it. Once that rule was clear, the implementation was straightforward.
That principle is also why the automation is cheap to run. It does a small, predictable amount of work on a schedule instead of polling constantly, which keeps it to roughly 390 operations a day.
Most reporting gaps don’t come from missing data. They come from tools that each hold half the answer. Marketing knows the source; operations knows the outcome; nobody owns the join.
You don’t always need a warehouse, a CDP or a new platform to close that gap. Sometimes a small, well-designed automation that joins two systems on what they reliably share, and gives every record a clean exit, is enough. It costs little to run, it’s easy to explain, and the answer shows up where people already look.
Built with: CallRail · Zoom Phone API · Make.com · Webhooks · REST APIs
Can CallRail and Zoom Phone be integrated directly?
They don’t share a call ID, so there’s no simple one-to-one link between their records. In this project we matched calls on caller number within a time window, then used Zoom’s call routing data to identify who answered.
Why tag the rep in CallRail instead of building a dashboard?
Because the team already lived in CallRail’s reports. Putting the rep’s name there meant the answer showed up in a tool they trusted, with nothing new to adopt.
Does this work for calls that ring several reps?
Yes. That’s the reason for reading the routing path. It shows who actually picked up, not just which line rang first.
How long does something like this take to build?
Here, a few hours once the matching approach was clear. Most of the work is figuring out what the two systems reliably share; the automation itself is small.
Is Make.com reliable enough for this?
For this volume, yes: about 390 operations a day with one error in four months. Queuing calls first and matching on a schedule keeps it predictable and inexpensive.
If your call tracking, CRM or phone system each hold half the story, let’s talk about whether they can be connected.
Client identity anonymized.
