Turnkey low-code automation setup on Bitrix24

Bitrix24 setup: where processes break in practice

Process automation starts not with setting up stages but with analyzing where a request stops moving.

A typical failure looks mundane: an inquiry comes from a form, email, or messenger, lands in a card, and then the manager handles it manually, moving data between fields and changing status from memory.

The first bottleneck in request processing is the absence of a single queue.

While requests are distributed on a first-come, first-served basis, some remain without an owner during vacation or sick leave, and losing requests between stages becomes a matter of days, not a rare exception. Later, the only way to reconstruct at which step a request stopped is from the correspondence.

Second — manual operations in the sales department: reminders in messengers, copying data into third-party spreadsheets, re-entering the same client when moving between pipelines.

Deal statuses do not reflect reality: the report shows the deal as "in progress," although the client has already declined or, conversely, has been waiting for an invoice since last week.

Bitrix24 setup closes this at the level of rules rather than employee discipline: required fields at a stage, automatic transfer of a request when there is no owner, tasks and notifications instead of manual reminders, a single card instead of chat correspondence.

Below we examine which bottlenecks are removed by the system's out-of-the-box tools and where customization for a specific process is needed — taking into account roles, access rights, and how your deal accounting is structured.

Measurable effect: time, volume, and failure class

The effect of automation is calculated before the start: we capture baseline values from the request log and deal history over several weeks — otherwise any "it got faster" remains a feeling, not a result.

Then each Bitrix24 setup is checked against the same sample: before and after. Below are the metrics by which acceptance proceeds without disputes.

Request processing speed

• Time to first response: from the appearance of a request to the owner's reaction. After setting up robots and distribution rules, the metric stops depending on who is on shift.
• Share of requests distributed automatically — without manual forwarding between departments and without requests being lost on an "unowned" desk.
• Time to pass an individual stage: how long a request sits at a specific step. The bottleneck is visible by stage, not by the overall deadline at the end of the month.

Transparency of deal stages

• Share of deals with completed required fields at each stage: the stage moves only when conditions are met, not by agreement.
• Share of tasks with an overdue date: timers escalate before the client reminds you.
• Eliminated failure class "forgot to respond" — a request does not remain without an owner: a task is created automatically, and a reminder is sent on schedule.

During acceptance, we compare these indicators with the baseline — the discrepancy is visible from the log, not from impressions.

Bitrix24 setup options: comparison of approaches

Before changing anything, let's distinguish three forks: a ready-made template, an assembly for a specific process, and targeted customization of an existing environment.

The choice depends not on company size, but on how many places in the process have a step order that differs from the typical one — that is exactly where the template starts to get in the way and manual workarounds appear.

Ready-made platform templates

Industry templates cover typical scenarios: sales pipeline, request processing, contract approval. They are deployed quickly, and the platform vendor provides support.

The limitation is that the process is adjusted to the template, not the other way around: with parallel approval or a return to a previous stage, edits are inevitable, and each update then requires checking.

Assembly for a specific process

The environment is assembled from platform entities — smart processes, robots and business processes at stages, role-based rights, and exchange with the accounting system. The logic mirrors your regulations exactly, including branches and returns.

The cost is longer design and acceptance at the start, and the assembly must be documented; otherwise the next edit will run into verbal agreements.

Implementation stages: from process analysis to handover

Implementation proceeds in waves: first we analyze how work is currently structured, then we assemble a scheme, transfer it to a separate environment, and only then enable it on real requests.

The order is critical — setup without process analysis locks into the system the same workaround routes that existed in correspondence and spreadsheets, only now they are harder to notice.

Process analysis and scheme

1. Process and role analysis. Interviews with the people executing each area, a map of current routes: where a request sits longest, which approvals happen in messengers, who actually makes the decision. The output is a list of bottlenecks and a list of roles with real rights, not job titles from the staffing schedule.
2. Automation scheme. Entities and their relationships: deals, smart processes, tasks, contracts; stages with transition conditions, required fields, robots, and triggers. We approve the scheme before setup — an edit on paper takes minutes, while an edit in the working system breaks already collected statistics.
3. Setup. Pipelines, smart processes, approval business processes, department rights, exchange with the accounting system and email. We check each element on test data with different roles.

Pilot operation and handover

• Pilot operation. Part of the flow follows the new scheme while the previous route remains operational — this way the switch does not block the department if something behaves differently than on test data.
• Corrections based on actual results. We compare the log with real requests: stuck tasks, duplicates, rights errors, lost notifications. We bring it to a state where no request remains without an owner.
• Handover to support. Regulations, instructions for users and the administrator, description of connections and failure points, training on live examples. After handover, you retain a working system and a team that understands how it is built.

What you retain: configurations, schemes, regulations

Automation work does not end with launching a scenario — it continues when processes change, new employees arrive, and someone accidentally edits settings.

Therefore, at the output you receive not a set of enabled robots, but a working system configuration that can be developed without us.

Documentation and regulations

• Process schemes: where the scenario starts, what conditions it checks, at which stage it closes, and where it passes the result.
• Map of fields and reference data: which data is required, where it comes from, what goes into reports and exports.
• Instructions for employees: one page per role — what to do in the standard scenario, what to do in case of a failure, whom to contact.
• Change regulations: who approves a process edit, on which copy it is checked, and how it is rolled back.

Access and role rights

• Access policies by role: who sees deals, tasks, and documents in full, and who sees only their own.
• Rights matrix for settings: administrators, department heads, and external contractors receive different levels.
• Task distribution rules: queues, owners, response deadlines, and escalation conditions.

All of this consists of active configurations, not a description of "how it should be." We hand them over together with access, so from then on you change processes on your own or return to us only for further development.

Case study: removed manual approvals in the sales department

A sales department of 14 people worked without a single approval regulation: every request for a discount or individual terms went by email and messengers.

We moved approvals and request distribution into a single environment on Bitrix24 and removed manual steps — below are the before-and-after metrics.

What it was before

A discount request went to the department head, then to legal and financial control — each confirmed with a reply in correspondence. The average cycle from client request to response was 6–8 hours; on peak days it stretched to two days because key participants were traveling.

Over the quarter, losses were recorded: requests were closed without a response, and some clients left without waiting for terms. The manager spent more than an hour a day reviewing correspondence and sending reminders.

What it became after

Approval was built into the deal card: the route is based on the amount and type of terms — up to the threshold the manager decides, above it legal and financial control are connected.

Each step has a timer and escalation during idle time, and the approval history remains in the deal. New requests are distributed among managers by rules — region, industry, current workload.

Response time to the client decreased from 6 hours to 40 minutes on average, the share of requests approved on time grew to 96%, and requests lost in correspondence were zero for the quarter. The manager's time on approvals fell by approximately 70% and went into work on large deals.

How does a ready-made template differ from assembly for a process?

A ready-made template covers a typical scenario: deals through standard stages, leads, invoices, and role-based rights out of the box.

If the regulations match this logic, implementation comes down to setting up reference data and notifications — assembly for the process adds nothing here.

The divergence begins where the regulations have roles and exceptions that the template lacks: an approver from an adjacent department, parallel approval by two managers, a deal with partial shipment or deferred payment.

The template itself does not break — instead, the regulations start being adjusted to fit it, and part of the work leaves the system.

This increases the cost of supporting workaround schemes: agreements in chats, "memory" fields, duplicate cards, manual reminders. Each workaround is invisible in reports, falls apart when the owner changes, and requires manual reconciliation with every change. One rule described in the system is almost always cheaper than ongoing support of a workaround.

The calculation is simple: the frequency of the exception is multiplied by the number of participants and the time of the manual operation.

If an exception repeats regularly and more than two people pass through it, it is more profitable to describe it as a rule, not an instruction.

We first analyze the regulations and exceptions, then look at what the typical Bitrix24 scenario covers: where settings are enough, where a business process or robot is needed, and where it is enough to change the work order itself.

The "template or customization" map is fixed before the start — so as not to waste effort setting up something that already works.

Common technical questions before project start

Before project start, the same technical doubts almost always surface: what to do with accumulated deal history, whether the existing environment will break, how to separate rights, and whether the department will continue working during changes. We answer briefly — we will go over the details based on your configuration.

The environment is already set up — will everything have to be redone?

First we take a map of pipelines, robots, business processes, and rights — marking what works and should not be touched. Customizations are done in a targeted way on top of the existing setup: current scenarios continue to work until the new one is tested in a test environment.

How should access rights be separated by role?

We build rights from roles, not individual employees: role → set of operations → visibility of sections and fields. A new employee gets access when added to the role, without manual editing. The change log shows who changed the status, amount, or owner.

Will the department be able to work during implementation?

We roll out changes in portions; each is tested in a test environment and has a rollback point, so the department's work does not stop. Timelines depend on scope: standard invoice approval takes weeks; a migration with several pipelines is planned in stages.

Let's discuss the task: we will analyze the process and come back with a plan

To keep the conversation on point rather than turning into a gathering of clarifications, it helps to bring a brief description of how the process works now. Below is a set of inputs that will let us assemble the picture faster and come back with an estimate and work plan.

• A diagram of the process as it runs today: stages, manual operations between systems, where delays and duplicate data entry appear.
• A list of roles and rights: who creates a request, who approves, who sees cost and closing documents, and where restrictions by department are needed.
• Examples of exceptions: amount above the threshold, client outside a contract, repeat request, partial shipment — what does not fit a linear scenario.
• The set of process participants and their availability: who makes decisions, who approves stages, who is responsible for data in the accounting system.
• The expected result in measurable form: which operations should run without manual intervention, which documents should be generated automatically, and where human control is needed.
• Conditions for starting: access to the portal and accounting system, a test environment for checking scenarios, and target launch dates.

After the analysis, we come back with an estimate and work plan: stages, the scope of work at each, what will be required from your side and at what point. If some inputs are missing, that is fine — we will reconstruct them on a call and clarify as the project proceeds.