Setting up and customizing the call card in Bitrix24

Call card in Bitrix24: where customer data is lost

The call card in Bitrix24 is the junction point between telephony and the deal: the number, call recording, responsible person, and result all land here.

When this junction is configured on the principle of “as long as the call is displayed,” the loss of call data begins at the very first step — and it is noticed not by an engineer but by a manager: the funnel does not match the real number of inquiries.

The first break point is number matching. The customer is recorded in one format, the station outputs the number in another, several contacts are attached to one number, city prefixes are added — and the call remains unlinked.

Neither a lead nor a callback task appears in the system: missed inquiries simply do not exist in reporting.

The second is unfilled deal fields. After the conversation, the manager manually sets the stage, source, comment, and amount, and in a high-volume flow does this partially: some fields are empty, some are entered later and inaccurately.

At the same time, the call recording sits separately from the card, so when a customer is handed over to another manager, the context cannot be read.

The third is manual transfer and duplicates. Data is copied into third-party tables, a repeat call creates a second card, and the responsible person differs for the lead and the deal.

Thus the gap between telephony and the deal turns into a distorted picture of inquiries: some of them are not counted, the source is attributed incorrectly, and conversion by channel is inflated. Let’s look at how this is closed through configuration.

Measurable effect: processing speed and field completeness

The metrics in this section are meaningless to compare without a baseline, so before configuration we take measurements from the current funnel: the median time from call arrival to deal creation, the share of cards with empty required fields, and the number of actions the operator performs manually after the conversation.

Measurements are taken using standard reports and an export of the Bitrix24 call log, and are repeated two to four weeks after implementation — otherwise growth looks like a feeling rather than a fact.

Inquiry processing speed changes due to distribution on the telephony side: the deal is created at the moment of answer, and the responsible person and source are set by a rule, not by the operator.

The wait for manual card creation disappears, and the time to first touch in the system drops from tens of minutes to single digits.

Data completeness in the deal rests on required fields tied to the conversation outcome: the result, refusal reason, and source label are transferred from the call card to the deal automatically.

The share of deals with a complete set of fields grows to 90–100% where previously half of the cards remained with an empty source and an unfilled result.

The removal of manual operations is visible in the number of touches: copying the number, searching for the customer in the database, and manually linking the recording to the deal are replaced by rules.

Quality control of the department’s work shifts from total listening to selective filtering — we check calls with long pauses or without a result, and review coverage grows with the same headcount.

Standard scenario, module customization, or external integration

The call card in Bitrix24 is the point where the call recording, link to the deal, responsible person, and reminders converge.

Standard fields and routing are not always enough, but before writing a custom module, we check what exactly is missing: additional fields, post-conversation logic, or exchange with an external system.

The three approaches differ in how deeply the change goes into the platform and what will happen to it during an update.

How we choose an approach

The order is usually this: first we try to cover the task with standard settings, then we add fields and scenarios inside the platform, and only move exchange with an external system outside.

A rule that changes every month is cheaper to keep outside the module — edits do not require code updates. Where response speed in the interface itself matters, we keep the logic inside.

In practice, a combination more often works: we customize the card, and hand over recording storage and conversation analysis to an external service so that platform updates pass without rewriting.

How a call scenario is configured: implementation stages

Implementation stages are built from the process, not from settings: until it is fixed what kinds of calls occur and what needs to be seen for each, the call card in Bitrix24 turns into a set of fields without logic. Below is the sequence of work after which the scenario can be put into operation.

1. Process analysis. We determine which inquiries go through telephony, who handles them, and where information is lost: a missed call, transfer to an extension, repeat inquiry. The result is a map of scenarios with participant roles.

2. Scenario design. We define the card composition: channel, responsible person, source, call recording, result. Some fields are pulled from telephony, some are filled in manually according to the regulation — we fix exactly what and by whom.

3. Field and rights configuration. We create fields and distribute access by roles and departments: an employee sees their own calls, a manager sees the whole department, and related units see calls without recordings. We separately check reports and exports so that rights cannot be bypassed outside the card.

4. Automation. We attach rules and robots: creating a task after the conversation, a reminder for a missed call, substituting data into the deal or contact, notifying the manager based on specified criteria.

5. Scenario testing. We run typical and edge cases on a test line: incoming, missed, transfer, unknown number, dropped connection. We check that fields are filled, rules trigger, and accesses do not conflict.

6. Handover to operation. We provide the scenario diagram, the list of fields and rights, instructions for the administrator and employees, and the change regulation. For the first weeks we provide support and correct what practice reveals.

Handover package: diagram, access rights, regulations

The call card scenario lives longer than the project: new lines and funnels appear, the department composition changes, and channels are connected.

So that each such edit does not turn into a request to us, the handover package is assembled so that the answer to the question “why the call was not linked to the deal” can be found in the document. Here is what remains with the customer after the work in Bitrix24 is delivered.

• Integration diagram — which services participate in call processing, where the source of truth for the customer is, in what order data enters the card, and what links it to the deal and the responsible person.
• Access rules — a role matrix: an operator sees their own calls, a department manager sees their department, an administrator sees settings and history. It separately notes which fields can be edited and which are locked so that the logic does not diverge.
• Operator work regulation — what to do with a missed call, at what moment the conversation result is recorded, which fields are mandatory before closing the card, and where to escalate a discrepancy.
• Configuration documentation — a map of card fields, automation conditions, and the procedure for adding a new line or funnel so that an edit can be made without analyzing the entire configuration.
• Employee instructions — one to two pages, with screens and typical situations: how to answer a call, how to fill out the card, and what not to do.
• Change log and rollback points — what and when changed in the settings and how to restore the previous logic if calls stopped being distributed after an edit.
• Checklist of checks — a set of scenarios (incoming, missed, transfer, repeat call) against which the scenario is run after any changes, not only on the handover day.

Case study: cut manual operations and inquiry losses in half

A sales department of several dozen people worked with telephony in Bitrix24, but the call card remained a formality: the conversation result was written from memory, some recordings were not linked to the deal, and the manager set the next step manually and not always.

In a sample of several thousand calls per month, almost half of the inquiries remained without a recorded result — there was nothing with which to hand the customer over to a colleague or analyze a disputed deal.

We changed the mechanics of the card, not discipline through orders.

The conversation result became mandatory upon closing, the inquiry type supplies its own set of fields, the number and responsible person are determined automatically by the line, and the recording goes into the deal together with the transcript.

Saving the card creates a task for the next step with a date, so duplicate entry between telephony and the deal disappeared.

What this delivered in numbers

Filling discipline stopped depending on the shift and workload: the card cannot be closed without a result, so there are no more empty records in the manager’s report.

Inquiry losses fell by half — every call either turns into a deal or remains in the history with a refusal reason.

How does the standard scenario differ from process customization?

The standard call card scenario covers the basic set: the number is pulled from telephony, the call recording is linked to it, a lead or deal is created, and the responsible person receives a notification.

Fields, blocks, and their display order are configured directly in the card, and post-call logic is assembled with standard robots and triggers. This is enough when the sales process is typical: one funnel, one department, a fixed set of data for qualification.

Process customization is needed when the logic runs into configuration limitations: custom fields with calculations according to internal rules, different data sets for different directions, separate rights to listen to recordings, automatic creation of a request in an external system based on the conversation result.

The sign is simple — the process is described by “if ..., then ...” conditions, and these conditions cannot be expressed with standard tools.

The timeline for customization depends on the number of such conditions and the depth of connections with accounting systems.

Setting up fields and rights takes days; custom logic and data exchange take weeks, together with a survey, assembly on a test portal, transfer, and testing on real calls.

The risks of customization are predictable: platform updates can affect non-standard code, and without documentation support turns into archaeology.

We remove this by not modifying the core — we extend through standard connection points, keep changes in a separate layer, run regression after each update, and hand over the logic diagram together with accesses. Then the scenario survives updates and remains manageable.

Frequently asked questions about integrations, rights, and updates

Before work starts, the customer’s doubts are usually of one kind: will customization break the already configured telephony, how to separate access between departments, what will happen after the next system update. Below are the questions asked most often, with substantive answers.

The call card is an add-on over the standard call mechanism: linking to entities, custom fields, rights, and event reactions.

We integrate into the same standard extension points rather than rewriting the core, so call behavior remains the same and the customization survives updates.

How to separate rights so that a manager does not see too much?

Rights are inherited from roles and tied to entities. We assemble an access matrix: who opens the card in full, who sees only their own calls, who has access to call recordings. We check each role on live users, not only in settings.

What will happen after a system update?

The customization does not modify the core, so an update does not erase the changes. Before the update, we run a check on a copy: we see that fields, rights, and call links work as before.

If the update changes an adjacent module, we adapt the customization before rolling out to the production system.

Will call history and call recordings be preserved?

Data remains in the standard storage; the customization only displays and links it. We configure retention periods and the cleanup procedure so that history is available for as long as required by the regulation. Before migration, we make a backup and check restoration so that rollback is predictable.

What is included in support after handover?

We monitor the processing of call events, respond to changes on the telephony side, and check operation after system updates. Plus consultations on extending the logic — when new departments or scenarios are added.

Let’s discuss your task: we’ll come back with an estimate and plan

To keep the review substantive, it is enough to send the call processing scenario: which card fields are filled automatically, which the operator enters manually, and what should go into the accounting system after the conversation.

Add a screenshot of the current card, an example export, and a description of roles — who sees the recording, who changes fields, who closes the deal.

The task discussion is one businesslike conversation: we analyze the call flow, check access rights and links between entities, and see at which step data is lost.

Then we come back with an estimate and implementation plan — what we do in the first stage and what moves to the second.

As a result, you receive:

• a point-by-point scope of work: which card blocks and fields we configure, which scenarios we automate, and which links to the accounting system we establish;
• the order of stages: test environment preparation, configuration, testing on real calls, and rollout to the production portal;
• a result handover scheme — configurations, filling regulation, and instructions for operators and administrators;
• requirements for accesses and roles that are needed from you to start;
• acceptance criteria: how we verify that the card is filled correctly and data reaches accounting;
• a list of customizations that are reasonable to postpone to the next stage.

Describe the task in free form — we will come back with an estimate, timeline, and work order.