Setting up Bitrix24 for a car dealership: where leads get lost
A lead reaches a dealership through Bitrix24 via at least four channels: a website form, a phone call, a showroom visit, and a service request.
While they live apart — a manager's email, a notepad at reception, the sales department's phone — the dealership's handling of inquiries falls apart into disconnected pieces, and neither the head nor marketing has a picture of the day as a whole.
Website leads are most often lost at the junction between the form and the client card: the email goes to a shared inbox, the manager sorts it out manually between calls, and some inquiries never reach the card at all.
The response time to a lead stretches from minutes to hours, and evening and weekend inquiries wait until morning — by then the client has already called the neighboring dealerships and booked a test drive somewhere else.
A separate gap is call tracking at the dealership. A call to the general number isn't logged, isn't linked to a client, and doesn't make it into a report, so no one calls back a missed call at lunch or after closing: it simply isn't visible.
The same logic applies to service — a repair request and a test-drive booking go into the same queue, and an urgent client waits while the manager finishes with a sale.
The cost of the gap comes down to two figures: the share of inquiries with no response in the first minutes and the number of calls with no recording.
At a dealership, this is a tangible part of the monthly flow — and it doesn't go to competitors, it goes nowhere, because no one even knows about it.
Below we break down how this is closed by setting up Bitrix24 for a car dealership: channel routing, response-time control, and handling missed calls.
The effect of implementation: response time, booking conversion, service workload
We measure the effect by three metrics inside the portal: the time to the manager's first response, the share of leads that reach a test-drive booking, and the occupancy of service bays.
All three are taken from the activity log and stage history — without manual exports or reconciling spreadsheets.
The speed of the first response rests on distributing inquiries according to the shift schedule and a timer that raises the card in the queue while the client waits. A form lead, a missed call, and a messenger message land in a single feed.
If no response goes out, the department head sees it before the client leaves for a neighboring dealer.
The dealership's single sales funnel starts with initial interest, not with a signed contract: the stages lead from the first touch through trim selection and a test drive to the deal, and then to a repeat service visit.
Required fields prevent moving a deal further with empty data about the car and the source — channel analytics stay accurate.
Automatic test-drive booking is assembled from free calendar slots and a link to a specific car: the client picks the time themselves, and confirmation and reminder go out without a manager.
Service workshop workload is calculated by occupied slots — the dispatcher stops being a bottleneck, and scheduled-maintenance reminders bring clients back.
In this scheme, the Bitrix24 portal is not a card repository but a source of numbers: robots, rules, and auto-tasks work on data that is already in the system.
Bitrix24 deployment options: cloud or your own server
The hosting scheme is chosen before setup begins: it determines which customizations of funnels, robots, and exchange with the accounting system are possible and which will have to be worked around.
For a car dealership this is fundamental — leads come from the website, from listing platforms, and from telephony, while deals, inventory, and service history live in the accounting system.
As long as these flows don't converge in a single card, the dealership manager handles the client manually and loses leads at the junction of channels.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud portal | One or two dealerships, standard brand funnels, scheduled exchange with the accounting system | The core can't be modified — only apps, business processes, and robots; some scenarios hit the limits of exchange and background jobs |
| On-premise version on your own server | Several dealerships, custom lead-distribution rules, deep customization of cards, print forms, and reporting | The customer installs updates: changes must be checked for compatibility with the current product branch, and the server, backups, and fault tolerance remain on the owner's side |
| Hybrid scheme | Internal processes and accounting on-premise, external channels and the client portal in the cloud | Two environments must be synchronized by a separate exchange: the number of failure points grows and discrepancies are harder to sort out |
In practice, the scheme is chosen by the number of customizations and data-storage requirements, not by habit. If the funnels are close to standard, the cloud portal launches faster and requires no administration.
When custom algorithms for distributing leads between dealerships and strict control over data are needed, the on-premise version on your own server is chosen.
We lock this choice into the implementation plan before the first setup — after that, funnels, robots, and exchange with the accounting system are assembled without redoing the foundation.
How implementation proceeds: from process audit to regulations
The order of stages here is not a formality. If you start with robots and integrations before the funnel scheme is locked in, automation begins duplicating inquiries and handing them to the wrong managers — and everything has to be redone at once.
That's why the work goes from audit to regulations, and each next stage builds on the result of the previous one.
- Sales process audit — we break down all inquiry channels: website, telephony, messengers, aggregators, listing platforms. We look at where a lead stalls, how long it hangs without a response, and what gets lost when it's passed between departments.
- Funnel and access-rights scheme — we break deals down by direction: new, trade-in, credit, service. We set up stages for the real sales cycle and roles so that a manager sees only their own clients.
- Integration setup — we connect telephony, forms, messengers, and accounting systems so that the deal card is filled with data without manual entry or repeat calls to the client.
- Robots and scenarios — we set responsible-person assignment, reminders, automatic stage changes, and test-drive tasks. We check the rules for conflicts between departments and for stalled deals.
- Testing on real leads — we run the live flow of inquiries through the configured scheme and check the distribution, robot triggers, and completeness of data in the cards.
- Regulations and handover — we lock in documentation on funnels and rights, train employees, and leave behind an environment that evolves without us.
This sequence delivers a manageable result: by launch, every lead has a route, a responsible person, and a response deadline.
Handover: configuration, access, regulations, instructions
The portal can't be considered delivered if it "just works in our demo." The dealer is left with a set of artifacts that a new administrator or manager can act on without us: documented funnels, an access matrix, lead-distribution rules, and the procedure for exchange with external systems.
- Funnel map. Sales and service stages, required fields at each transition, conditions for automatic deal closure — with an explanation of the logic, not just interface screenshots.
- Access rights and portal roles. Role matrix: head, sales department manager, service, administrator. What each role sees, where the visibility boundary for deals and the client base lies, who can change stages.
- Lead-distribution rules. By what attribute an inquiry goes to a particular manager — source, model, dealership, shift schedule. It separately describes what happens when the responsible person is inactive: forwarding and notifying the head.
- Regulation for handling inquiries. First-response deadlines, mandatory touches, reasons for refusal, the procedure for closing a deal. The same rules are embedded in robots and control reports, so the document and the configuration don't diverge.
- Integration documentation. Which channel, what data is transferred, what happens when an external system is unavailable: queue, retry, notification. It indicates where to view the exchange log.
- Portal administrator guide. Add a user, change a funnel stage, fix a robot, export a report, act during an exchange failure. Designed for an employee without a technical background.
- Guides for employees. Short role-specific scenarios: accept a lead, log a call, pass a client to service, mark the result of a visit.
- Acceptance procedure. A list of control inquiries for each source, which are run together with your team before signing — so the handover is not words but a verified result.
Case study: a dealership with three showrooms and a service center
Before implementation, a dealership with three showrooms and a service workshop handled inquiries haphazardly: website leads fell into a shared inbox, calls were logged in a notepad, messenger conversations lived on managers' phones, and listing platforms gave out contacts in a daily export. Shift handovers were verbal, so some inquiries simply never reached the responsible person.
What it was like before a unified environment was assembled
A two-week measurement produced an unpleasant picture: the average response time to an inquiry was about four hours, and on evening shifts it stretched to the next morning.
The share of lost leads held at a quarter of the total flow — the client had time to go to a neighboring dealer while their request was being moved from one spreadsheet to another.
The head couldn't say how many inquiries a particular showroom had brought in: there was no way to reconcile data from five sources manually.
What we changed and what it became
We assembled a unified portal on Bitrix24: the three showrooms were split into separate directions of one funnel with their own responsible people, and service was connected as a separate branch.
Inquiries from all sources now land in a shared feed automatically, duplicates are merged by phone number, and a robot assigns a task to the manager and escalates it to the head if there's no response for fifteen minutes.
The first-response time dropped from four hours to twelve minutes, and the share of lost leads fell from 27% to 2%.
The conversion of an inquiry into a test-drive booking grew by one and a half times, and each showroom's workload is visible in a single report without manual reconciliation.
What to do if the portal is already implemented and some tasks remain unsolved?
An audit of a configured portal starts not with reviewing settings but with facts: how deals actually move through stages, how many fields managers fill in by hand, which cards are bypassed through third-party spreadsheets.
The discrepancy between the intended scheme and what happens in practice clearly shows where the process logic broke.
We fix most tasks right on the live configuration. Fixing funnels means reassembling stages and eliminating duplicates, required fields at the moment of transition, rights by department and role, and reconfiguring robots and reminders.
All of this is changed in settings and scenarios without stopping the portal: inquiries continue to be accepted, managers keep working, and changes take effect stage by stage.
A rebuild is needed where the error is in the data model itself.
If a lead, an order, a test drive, and a service request all live in one deal at the same time, reporting won't add up, and cosmetic changes to stages won't help — that's when we separate the entities and the links between them.
We migrate data without stopping operations in parallel: the new environment is stood up alongside the old one, the exchange is configured, volumes and amounts are reconciled, the switchover takes a short window, and the old environment remains for rollback until the period is closed.
You can figure out which case you have in a single review: we look at funnels, fields, rights, integrations, and reports and compare them with how the sales department actually works.
Then we come back with a plan — what we change on the live portal and what requires a scheme rebuild.
Questions about integrations, access rights, and exchange with the accounting system
Before starting to set up Bitrix24 for a car dealership, the same set of doubts usually surfaces: how will the exchange with the accounting system go, will the deal history be lost, and what will managers be able to change themselves. Below are short answers on each, so you understand the scope of work before it begins.
How do you set up the exchange of stock and orders with the accounting system?
The exchange runs on a schedule: stock by warehouse and item is pulled into the catalog, and orders from deals go back.
At the start, we map the reference data — items, warehouses, counterparties — and fix a rule for conflicts: when there's a discrepancy, the accounting system takes priority, and discrepancies are collected into a report for the manager. This way, the stock in the card doesn't diverge from the real warehouse.
What does connecting telephony give you?
Calls are linked to the client card, recordings and missed calls go into the deal record, and extension numbers are distributed by department. The manager sees the call history next to the conversation, and the head sees how many calls were answered and how many were missed.
How do you separate managers' rights?
Rights are configured by department and role: a manager sees only their own deals and contacts, the head sees the department's funnel, and the dealer's administrator sees the entire structure.
We separately lock down exports and stage editing, so the database doesn't leave with a departing employee.
Will we be able to change funnels ourselves without a developer?
Yes. We hand over funnels, stages, required fields, and robots as settings with a clear instruction — adding a stage or a new auto-reminder doesn't require a developer. We agree in advance which changes are safe and which break the exchange and require our support.
How do you migrate deal history from the previous system?
We migrate deals, contacts, and conversations from the export, preserving dates, amounts, and responsible people. Before loading, we agree on what to migrate: closed deals from past years or only active ones.
After migration, we reconcile control totals by the number of deals and amounts, so reporting doesn't get skewed.
Let's discuss your scheme: what to clarify before work starts
To come back with an estimate and a work plan rather than generalities, we gather the inputs on your sales and service scheme during a call.
Below is the minimum of source data for an estimate: without it, the implementation stages are built on assumptions that later break the deadlines.
- Inquiry channels. Where clients come from: website, phone, listing platforms, messengers, repeat service visits — and how many funnels each flow should serve.
- Distribution and control. How inquiries currently reach managers, by what attribute they're divided between sales and service, and at which step they're most often lost.
- Related systems. What must exchange data with the portal: warehouse, telephony, the accounting loop, the catalog of cars and parts — and in which direction the exchange goes.
- Current data. Where the client base and deal history live now, in what form to migrate them, and what of the old data isn't needed at all.
- Roles and access. Who works in the portal — salespeople, service, management, external contractors — and what rights each group needs.
- Approval procedure. Who on your side approves the scheme of funnels, robots, and rights, so changes aren't rolled out retroactively.
After the call, we send a plan of implementation stages and the scope of work on the portal with the points where your approval is required.
Describe the task in whatever form is convenient — we'll come back with an estimate, a launch sequence, and a breakdown into phases, so you get the first working result before the entire scope is finished.