Telephony
Telephony describes the intended CRM model for an already working external connection: an incoming call is answered, routed to an employee or queue by CRM rules, and linked to the client and the deal. In that case, calls become part of the work on an inquiry, with an owner and an entry in the log.
The connection is set up in the integrations hub (the CRM → Integrations section, telephony connector). Direct links /telephony, /telephony/trunks, and /telephony/routing redirect to the corresponding hub sections, while /telephony/softphone opens chat. The call log is separate at /telephony/cdr.
Current UI limitation. The telephony card exposes provider and pipeline settings, but the wizard does not show a queue or direct-user selector. The server therefore rejects a routed save without a target; pipeline settings do not replace that control. Until the target field exists, do not present a connected provider, incoming routing, queue, fallback, or CDR as the result of this wizard: the scenario remains source-blocked and planned.
The sections below describe the intended routing policy for an already working external connection. They are not steps that the current wizard can complete: do not save a configuration from them or present the described outcome as available until the wizard has a queue or user target.
Intended configuration for an already working connection
An administrator sets up telephony. For a first launch, three things are usually enough:
- provider — which phone service you are connecting;
- intake token — the secret the portal uses to accept incoming calls from the provider;
- default pipeline — where inquiries from calls land.
In that intended configuration, advanced parameters (request signature verification and detailed routing rules) stay hidden until needed. Do not try to set up or test this through the current wizard: it cannot save routing without a target.
Intended wizard and SIP model
The intended model includes a personal line without CRM, a personal line with CRM, or a shared queue, followed by SIP settings and a pipeline choice. None of these are available steps in the current wizard: it shows no scenario, SIP step, or queue/user target. Do not enter or copy credentials from this model until the product provides the corresponding fields.
Routing incoming calls
Routing decides who an incoming call rings. The rules take the CRM context into account, instead of just "ringing everyone at once":
- The owner first. If the client or the deal has an owner, the call goes to them first.
- Queue. You can set a list of queue employees the call is distributed across.
- In parallel or in turns. A call can ring everyone at once or cycle through employees one by one with a ring timeout.
- Availability. You can take into account who is currently online and how many active calls an employee has, so you don't overload one person.
- Fallback. If no one answers, the call goes to fallback employees or follows an escalation rule, so the client's call isn't lost.
Set up routing to match the real process: for sales it is often "the owner first, then the queue"; for support it is even distribution across the available operators.
Which strategy to choose
| Process | Strategy | Why |
|---|---|---|
| Sales with assigned clients | Owner first, then the queue | The client reaches the person already handling the deal; the queue is only a fallback |
| Support with no assignment | Queue based on availability | Calls are distributed evenly among the available operators |
| High urgency (for example, a VIP line) | Parallel call to the whole queue | Whoever picks up first answers — minimal wait time |
| Small team | In turns with a ring timeout | Doesn't overload several people at once, but the client doesn't wait too long |
In every case, set up a fallback — without one, a client call that is not answered under the main rule may not reach the right owner or work queue.
Call log
Every call you answer or make is recorded. The call log is a separate read-only page where you can see:
- the direction (incoming or outgoing) and the status (ringing, answered, missed, completed, failed);
- the number that was called from and to, and the duration;
The current CDR screen does not show an owner, linked deal, recording, filters, or a way to open them. A log row on its own cannot locate a CRM record or prove that a recording exists.
Missed and failed calls are highlighted — so a manager immediately sees which calls need a callback, instead of digging for them in the general list. Use the log as a working control tool: a missed client call is a potentially lost lead.
The log loads 50 records at a time and uses cursors: Next and Back become available only when there is a page to open. If a saved cursor is stale, the portal resets the list to the first page; a temporary error offers Retry. An empty log, missing telephony read access, and a temporarily unavailable source are different states; an empty list does not prove that no calls occurred. The log has no player, recording, filters, or CRM-context link. If the context is already known from another permitted workflow, open it separately and check there whether a recording exists.
Good practices
- Assign the pipeline and the owner so the call reaches the person who actually handles the client.
- Set up a fallback and a queue so an incoming call doesn't go unanswered.
- Regularly review missed and failed calls in the log.
- Don't show real phone numbers, intake tokens, or signing secrets in screenshots.
Common mistakes
- Connecting telephony without a default pipeline and owner — call inquiries hang with no owner.
- Not setting up a fallback — the client's call is lost if the main employee is unavailable.
- Not checking the missed-calls log — clients don't get a callback.
- Overloading one employee by ignoring the active-call limit and availability.
Related pages