Docs · Calling

Inbound and outbound calling — routing, caller ID and the browser dialer

Outbound needs a number and working credentials. Inbound needs the number pointed back at the CRM and a rule for who picks up. The browser dialer additionally needs microphone permission, which is the failure people never guess.

Who this is for

Admins configure routing. Every agent has to grant their own browser microphone permission.

Before you begin

Telecom provider connected and at least one voice-capable number.
For Twilio specifically, calling needs more than the Account SID and Auth Token — it also needs API key/secret and a TwiML App SID. A setup missing those reports as partially configured rather than ready.
A browser that can use your microphone, on a secure connection.

Outbound

When you place a call the system picks which of your numbers to call from — matching the lead's area code where it can, and keeping the same number sticky to the same lead. If you only have one number, that's the one it uses.

Inbound

For an inbound call to reach the CRM, the number has to be pointed back at us — that happens automatically when you connect your carrier. Then the CRM decides who it belongs to: a known lead routes to whoever owns that lead; an unknown caller needs a fallback rule, or it has nowhere to go.

This is the part most setups skip, and it stays invisible until the first callback from someone not in your database.

The browser dialer and microphone permission

The dialer runs in your browser, which means your browser has to let it use your microphone. The first time you dial, your browser asks. If you dismiss that prompt — or you previously blocked it — calls will appear to connect while nobody can hear you.

This is browser-level and per-device, so it is not something an admin can fix for you, and it comes back if you switch computers or browsers.

How to check it worked

Call your own mobile from the dialer. Confirm you can hear each other — not just that the call connects.
Call one of your CRM numbers from a phone that is NOT in your lead database, and confirm it goes somewhere sensible rather than nowhere.
Call from a phone that IS a known lead and confirm it routes to the agent who owns that lead.

Common mistakes

Testing outbound only. Inbound is a separate path and fails separately.
Never testing an unknown inbound caller, so the first real one is a live discovery.
Blocking the microphone prompt and then reporting the dialer as broken.
On Twilio, assuming SMS credentials are enough for voice. Voice needs the API key/secret and TwiML App too.

Troubleshooting

Call connects but nobody can hear me	Browser microphone permission was denied or dismissed. Open your browser's site permissions for this site, set Microphone to Allow, and reload. Re-check after switching browser or computer.
Dialer says partially configured	On Twilio, the API key/secret or TwiML App SID is missing — SMS credentials alone don't cover voice. Add the missing credentials in agency settings, then use Fix Dialer on the integrations page.
Inbound calls go nowhere	No fallback rule for callers who aren't a known lead. Set a fallback agent so unknown inbound has an owner.

Local numbers (DIDs) and why a pool beats a single numberDialing a lead from a number with their own area code gets answered more often.Connecting your telecom provider (Twilio, Telnyx or SignalHouse)You bring your own carrier account.Adding agents, permissions and lead routingAdding someone is the easy half.

Where this lives in the app

Open this screenOpens in the app IntegrationsOpens in the app

This is documentation for Virtual Closer. Book a walkthrough or sign in.