Configure

Bring your own phone numbers

Keep the phone numbers your customers already know — including several toll-free lines — and have a Quincer AI persona answer them. Calls route by the number the caller actually dialed, so each line can map to its own persona even when they all share one connection to us.

How routing works

When a call reaches us we resolve it to a persona by the dialed number (DNIS). If a call is forwarded to us, the number the caller dialed is preserved (Twilio sends it as ForwardedFrom; SIP trunks pass a Diversion header) and we route on that first, falling back to the number the call actually arrived on. That means you can forward five different 1-800 numbers into a single connection and still send each one to a different persona — just register each number below.

Two ways to connect

Option A — Forward your numbers

Easiest, works with any carrier or PBX. In your phone provider, forward each number you want answered to the Quincer number we provision for you (or to a Twilio/Telnyx number on your own account). The original dialed number rides along, so we route each forwarded line to the right persona.

1. Register each of your numbers in the dashboard (see below).
2. In your carrier/PBX, forward those numbers to your Quincer number.
3. Call each number and confirm the right persona answers.

Option B — Bring your own carrier (SIP trunk)

For teams who own their telephony (Avaya, Cisco, Mitel, or any SIP trunk): point an outbound trunk at Twilio or Telnyx as a bring-your-own-carrier termination. The call arrives with your real number as the dialed number, so it routes directly. Add your trunk identifier when you register the number so calls are attributed to the right trunk.

Option C — Connect a SIP trunk straight to Quincer

If you would rather not put a third-party carrier in the middle, you can point a SIP trunk from your PBX or SBC directly at us. We configure the connection on our side and send you the details to dial into. This is the right option when you sit behind a PBX (Avaya, Cisco, Mitel, Genesys, and similar) and want calls handed to your AI without leaving your own carrier contract.

Go to Settings → Voice and fill in Connect a SIP trunk. We ask for:

• A name for the trunk — usually the site or PBX, e.g. Toronto HQ — Avaya.
• Your SIP signalling IPs — the public addresses your PBX or SBC sends SIP from. We allow only these, and each address is matched exactly, so list them individually rather than as a range.
• The numbers to route to us — in full international format, one per line. These are the numbers your AI will answer.
• Transport — UDP, TCP, or TLS. We recommend TLS on port 5061.
• How we should authenticate you — an IP allowlist if your signalling addresses are static, or digest authentication (username and password) if they are not.

Submitting the form opens a support ticket you can track on the Support page. We reply with the hostname to send SIP to, the port, and your credentials. Once you point the trunk at that hostname, register each number in Phone numbers as normal so it maps to the persona you want.

Register a number

Open Phone numbers in the dashboard and fill in the Map a number form shown below. Phone number is the number your customers dial, in E.164 format; the optional Label is just a name for your list (e.g. Main support line). Persona picks who answers — leave it on Widget default persona to inherit the widget’s default. Carrier is how the call reaches us (Twilio or Telnyx), and the optional Carrier trunk ID is your BYO-carrier or SIP trunk identifier, for clean cost attribution. Click Add number, then forward the number (Option A) or trunk it (Option B).

Check that it's working

Three tools on each row of the Numbers for … list help you confirm a number is set up correctly — so a customer's call isn't the first time you find out something's off. In the row below, the line under the number is the Last call received status, and the Check voice and Check SMS buttons (next to Disable and the delete icon) each run a live configuration check whose result expands inline beneath the row:

• Check voice — for numbers on your own Twilio account, this reads the number's live configuration and verifies its inbound-voice webhook points at Quincer over HTTP POST, that the number is voice-capable, and that it exists in the connected account. It also checks that the Twilio account is active (not suspended or on a trial) and whether Twilio has actually received any calls to the number recently — so if a caller hears “the call cannot be completed as dialed” but Twilio has logged no calls, you'll know the call isn't reaching Twilio at all (a number-provisioning or account problem, not your webhook). If something's wrong it tells you exactly what to change.
• Last call received — each number shows when Quincer last received a call to it and whether we connected it or rejected it (and why — e.g. out of voice minutes, or voice not configured). If it says “No calls received yet” and you expect calls, your carrier almost certainly isn't pointed at Quincer — run Check voice.

Check SMS — will texts actually reach this number?

Check SMS is the same idea for texting, and it exists because the obvious test proves the wrong half: sending a test text exercises outbound only. It says nothing about whether a customer's reply reaches Quincer — that's the inbound webhook, and it's exactly where SMS breaks silently. The check is read-only: it reads what your carrier account itself reports, sends no message, changes nothing, and costs nothing. Each result panel is labelled SMS setup or Voice setup so you always know which check you're looking at.

For a Twilio number it verifies, in your own account:

• The number is SMS-capable — a voice-only number drops texts with no error anyone sees.
• The SMS webhook points at Quincer over HTTP POST — inbound texts are only accepted over POST.
• Nothing is quietly overriding the number. If the number belongs to a Twilio Messaging Service, or routes through a TwiML Application, that object's webhook is used instead of the number's own — the number can look perfectly configured while its setting is never consulted. The check names which one is in charge and where the URL actually needs to be set.
• The account can deliver at all — a suspended account sends and receives nothing, and a trial account can only text verified numbers.
• Whether the carrier has logged any inbound texts — if someone has texted the number and the carrier saw nothing, the message never reached the carrier, which is upstream of every setting above.
• Recent outbound failures, with the carrier's own error code named — for example A2P 10DLC registration missing (30034), carrier spam filtering (30007), or a recipient who replied STOP (21610), each with what to do about it.

For a Telnyx number the same button checks the messaging-profile chain instead: Telnyx routes inbound texts through a messaging profile, not the number itself, so the check verifies a profile is assigned and enabled, that its webhook is the Quincer URL (including the required ?carrier=telnyx parameter), and that the profile is on webhook API version 2 — a v1 profile delivers every message in a shape we can't read, so texts arrive and go nowhere. And on a direct SIP trunk number the check answers plainly: a raw SIP trunk carries voice only, so texts to it can't be received or sent — use a Twilio or Telnyx number for SMS.

Use your own Twilio / Telnyx account (voice + SMS)

To answer both calls and texts on a number you own, connect your carrier account and point its webhooks at Quincer. Unlike call-forwarding (which can't carry SMS), this runs voice and SMS on your own number end-to-end. In Integrations → Telephony → Connect your carrier account, the dashboard shows the exact values for the provider you pick; in short:

In the card above, each carrier shows a Connected badge once its credentials are saved (Twilio takes an Account SID + Auth Token; Telnyx an API key + public key). The Setup instructions link opens a dialog with the exact Voice and Messaging webhook URLs for the provider you picked, and Send a test SMS fires one real text from the registered number so you know sending works before going live. Then:

1. In your carrier console, set the number's Voice webhook to https://phone.quincer.com/carriers/<twilio|telnyx>/inbound.
2. Set the number's Messaging / inbound-SMS webhook to https://<your-app-domain>/api/sms/inbound?carrier=<twilio|telnyx>. This is a different host from the Voice URL above — calls go to the voice gateway, texts come to the app. Reusing the voice host here is the most common way inbound texting is set up wrongly, and it fails silently.
3. Paste your credentials into Connect your carrier account (Twilio: Account SID + Auth Token; Telnyx: API key + public key) — we use them to send replies from your number and to verify your webhooks.
4. Register the number under Map a number and pick its persona.
5. For US SMS, complete A2P 10DLC brand/campaign registration in your carrier account first, or texts won't deliver.

Set carrier keys once for the whole organization

If you run several brands on the same carrier account, you don't have to paste the keys into every brand. Set them once under Settings → Telephony carrier keys (owner/admin only), and every brand that hasn't connected its own account inherits them automatically. Keys are stored encrypted and never shown again once saved — the card shows only whether a key is configured.

Each brand then chooses, per provider, in Integrations → Telephony:

• Use the organization's predefined key (the default when one exists) — the brand inherits the organization key. The provider shows an Inherited badge.
• Uncheck it to enter a key just for this brand — a per-brand override that takes precedence over the organization key. The provider shows a Connected badge. Re-checking the box removes the brand's own key so it inherits again.

Resolution order for every call and text is: the brand's own key → the organization's predefined key → Quincer's shared account. A provider is only ever used when both of its fields are set at the same level, so a half-entered key is rejected rather than silently ignored.

How SMS replies work

A persona answers texts with the same knowledge and workflows it uses on calls and chat. The number's mapped persona replies (or the widget default); the thread appears under Inbox. Two-way SMS is gated by the “Text things to callers” toggle on the Telephony settings. Replies are sent from the number that was texted. Incoming texts are always free; outbound texts (replies + booking links) draw from your voice plan's included SMS.

How SMS conversations open and close

SMS is more transactional than chat, so threads don’t linger “live” all day. An SMS conversation auto-closes after 2 hours of inactivity; a WhatsApp conversation stays open for 24 hours. A closed thread simply drops out of the live inbox — the next inbound text starts a fresh conversation, and you can always re-open the old one to follow up.

• Each (customer ↔ business-number) pair is its own thread. If a customer texts two of your numbers, those are two separate conversations — and a reply always goes back out the same number the customer texted. Assign a different persona per number on the Phone numbers page (see Register a number).
• The sender’s phone number is the caller identity. An inbound SMS shows the texter’s number in the inbox (in E.164 format), not “Anonymous Visitor”, so operators can tell threads apart at a glance.
• Operators can reply to a text. Open the conversation in Inbox → Live (see Live chat), click Take over, and type — your reply is delivered to the customer as a text message from the number they reached you on.
• Re-open a closed thread to follow up later. A customer texts overnight, the AI handles it and the thread closes; in the morning a teammate opens it on the Inbox page and clicks Re-open & reply to respond. This works for closed SMS and WhatsApp threads. See Live chat.

Transfer a call to a human

When a caller asks to speak to a person — or presses 0 — the AI warm-transfers the live call to a real human and bridges the two together. No app required for the human; their phone simply rings.

The transfer is screened: the AI first asks the caller for their name (and email), then announces it to your teammate before connecting — “You have a call from {name}. Press 1 to accept, or hang up to decline.” Only an accepted call is bridged.

On a persona’s page, the Phone handoff — transfer calls to control (below) sets the target. The dropdown lists your teammates — each shown with their phone number, or greyed out with “no phone set” if they haven’t added one on Organization → People. Pick a teammate to ring their phone, or leave it on A phone number (below) and type a number directly into the field it reveals. Leave both blank to only notify the team (no live transfer).

Showing the caller’s number to the person you transfer to

By default, a transferred call arrives showing your Quincer number. That is the number your carrier knows you own, so it always connects — but it means a call centre or CRM cannot look the customer up automatically, and the agent ends up asking for a phone number the caller already gave the assistant.

On a persona’s page, tick “Show the caller’s number to the person you transfer to” and the transfer arrives showing the caller’s own number instead, so your screen-pop works.

Two things it will not do. If the caller withheld their number, or the call didn’t come in over the phone, the transfer falls back to your Quincer number and still connects — you get no screen-pop for that call rather than a failed one. And it only ever presents a number that genuinely called your line; there is no way to make it display an arbitrary number.

1. To route to a teammate, set that person’s phone number on Organization → People. The persona dropdown shows who has a number set.

See what your AI texted (SMS activity log)

Whenever your AI texts a caller — a booking link, an install guide, a document — the attempt is recorded. Open the conversation under Inbox and, if any texts were sent, an SMS activity panel shows each one with its status, so you always know whether a promised text actually went out.

• Submitted to carrier — we handed the text to Twilio/Telnyx successfully. If the caller still didn't receive it, check the message in your carrier console (delivery is downstream of us).
• Failed — the carrier rejected it; the reason is shown (e.g. an unregistered A2P sender, or a number that can't receive texts). Fix the cause and the next send goes through.
• Composed — the text was written but we couldn't confirm submission. Usually transient; rare.

Who called (caller identity)

Inbound phone and voice conversations show the caller's number instead of “Anonymous visitor” — and their name and email as soon as your AI collects them on the call. The caller's number is searchable in the conversation list, so a returning caller is easy to find. (Web chat still identifies visitors via sign-in / Google One Tap as before.)

Troubleshooting

• "This number isn't in service." The dialed number isn't registered (or is disabled). Add it on the Phone numbers page and make sure it's enabled.
• The wrong persona answers a forwarded number. Your carrier may not be passing the original dialed number. Confirm forwarding preserves it, or have your SIP trunk send a Diversion header (or a custom X-Original-Number header) carrying the dialed number. As a fallback, forward each number to its own dedicated Quincer number 1:1.
• Need direct numbers instead of forwarding? We can also provision Twilio/Telnyx numbers for you — those answer with no extra setup.