Use case
What a Relevance AI plus Make front office actually covers across locations
A Relevance AI plus Make build for a multi-location front office reliably takes capture, routing and CRM writeback off the desk. It does not replace phone staff, and no primary source says it does. Here is the work split, the arithmetic on your own call volume, and what still needs a person.
What the two tools actually do
Make's Relevance integration connects a Relevance agent to the rest of your stack, Slack and Google Sheets included. Make's app documentation says you need an active Relevance account and an API key, then you create the connection inside Make.
Relevance is the agent side. Its integration marketplace lists 158+ tools and platforms, and its guides cover research, outreach, lead scoring, CRM enrichment and meeting prep. So the agent decides, and Make moves the data.
The split that makes it work
| Work | Owner | Why |
|---|---|---|
| Capture name, site, service, time window, source | Agent | One schema for every location |
| Route by site code to queue, calendar, owner | Agent | Deterministic, no judgement needed |
| Write back to the CRM and dedupe | Agent | Relevance guides cover CRM enrichment |
| Price pushback, upset caller, medical nuance | Human | Cost of a wrong answer is high |
| Anything the agent cannot confirm | Human | Silence is worse than a transfer |
I built the closed-CRM bridge version of this for a multi-site housing operator: 25 GoHighLevel locations, 14,000+ leads in the back office, about 11,000 mirrored into Supabase for dedup, a 72-hour auto-close with a 24-hour lookback. The part that ate the time was not the agent. It was the 201 responses that come back with no data in them.
The arithmetic, on your numbers
Count your own inputs, not mine. Sites, times intake calls a day, times minutes of typing per call. Four sites at 25 calls and four minutes each is 400 minutes a day of structured typing. If the agent takes the capture and routing half and you keep the rest, you free roughly 200 minutes a day. That is a number to test in one location, not a promise to buy for all of them.
Limitations
- I have not run this exact Relevance plus Make pairing end to end. The steps above come from the vendor documentation.
- No primary source documents this stack replacing phone staff. Treat "replaces a hire" as a sales line, not a finding.
- Voice is the hard part. Structured intake from a form or chat is a different problem from a live caller who interrupts.
- Cost compounds per location. Agent task pricing and Make operations both scale with call volume.
- Multi-site means multi-config. Every location adds a calendar, a number and an owner who wants an exception.
My take
Build it for capture and routing, staff it for exceptions, and watch one location for two weeks before the rollout. My guess is that the second location is where most of these builds quietly break, because the config stops being shared. More on systems that survive a second location on the blog.
Questions people ask
Can one agent cover several locations, or do I need one per site?
One agent with a site code on every record is the cleaner shape: the location field decides the queue, the calendar and the owner. Relevance's marketplace lists 158+ integrations, so the same agent can write into each site's tools. What multiplies per location is configuration, not agents.
What do I need before I can connect Relevance to Make?
Make's app documentation says the Relevance app requires an active Relevance account and an API key from that account, and that you then create the connection inside Make. Everything after that is normal Make scenario work.
Does this let me skip hiring another front-desk person?
Nothing I found says so. The documented capability is connecting an agent to your other business apps and automating structured work. Capture, routing and writeback move; exceptions, escalation and an annoyed caller still need a person.
Have a process like this leaking time or leads?Thirty minutes, no deck, and you leave with a plan.
Book a call