Every call on the board, every voicemail a task
Four Make scenarios connect a cloud phone system to a CRM: every call becomes a row on a calls board, a voicemail becomes a routed follow-up task, an unknown caller becomes a lead, and an inbound text is forwarded to a person.
Where this applies
Sales and support teams on a cloud phone system who want calls, voicemails and texts reflected in the CRM.
- call events logged, no errors
- 2,783
- voicemails turned into tasks
- 127
- scenarios, two proven live
- 4
The problem
A sales team lives on the phone, but what happens on the phone is invisible to the CRM: nobody can see how many calls a lead has had, a voicemail is a message in someone's inbox, and a caller the CRM has never met leaves no trace.
The phone system emits events for each of these. The job is to turn them into records a manager can see, and into tasks someone will act on.
What we built
Calls as events
A webhook scenario receives every call event except hang-up from the phone system and writes a row to a calls board with an attempt at linking the lead. It is the workhorse of the set and has handled thousands of events.
A voicemail becomes a task
When a voicemail arrives, a scenario finds the rep, matches the caller's phone number to a lead, and routes a follow-up task to a department chosen by the name of the phone line it came in on, with a due date.
An unknown caller becomes a lead
A caller whose number does not match any lead is created as a new lead in a call-leads group, after a phone lookup, so no inbound call is lost to the pipeline.
A text reaches a person
An inbound SMS to the business number is forwarded by SMS to a staff mobile through the SMS provider's webhook, so replies are not stranded on a number nobody watches.
Numbers matched after normalising
Each scenario normalises the phone number to the format its board stores (stripping the country code or a leading zero) before matching, because a number can arrive in either form.
The outcome
Across the four scenarios: 2,910 runs and 6,508 operations in Make's counters, with no errors. The call log has 2,783 runs and the voicemail scenario 127.
The unknown-caller and inbound-text scenarios are built and have not yet fired.
Where it stops
There is no de-duplication by call id, and because every non-hang-up event passes, one call can create several rows. Phone normalisation is written separately in each scenario and fixed to one country, and the call log's lead match may not match how numbers are stored, so a logged call is not always linked to its lead. The voicemail due date is built from a line field rather than the voicemail's time, and its department mapping and fallback assignee are fixed. Create steps in the voicemail scenario ignore failures.
Built with
- Make.com
- monday.com
- Aircall
- Twilio
- Webhooks
Patterns used
- Event to row
- Phone match with normalising
- Route by line name
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no