Bitrix24 Setup and Implementation

Companies often start using Bitrix24 in a fairly simple way: add employees, connect email, create several deal stages, and import their customer database. Technically, the CRM is already up and running. In practice, a few months later there may be dozens of unnecessary fields, managers use statuses differently, some information is still kept in Excel or private messages, and the head of sales still has to ask the team what is happening with a particular customer.

This is why our Bitrix24 implementation does not begin with configuring the interface. First, we need to understand where inquiries come from, when a lead or deal should be created, which stages it goes through, who is responsible for the next step, what information employees actually need, and which actions the system can perform automatically.

Only then do we configure deal pipelines, stages, CRM cards, roles, automation rules, triggers, notifications, and integrations. The result is a Bitrix24 environment that supports the company’s day-to-day operations rather than becoming another system employees have to maintain manually.

Rate: from RUB 2,200 / hour

The basic CRM model in Bitrix24 is built around several connected entities. A contact represents an individual, a company represents an organization, and a deal contains information about a sale or another commercial process. Depending on the chosen CRM model, incoming inquiries can first be handled as leads or immediately converted into contacts, companies, and deals.

We define this logic before configuring the pipelines. For one business, every website inquiry may genuinely represent a potential deal. Another company may need to qualify the request first, determine the business area, region, product, or customer type, and only then assign it to a sales manager.

CRM cards are configured separately. There is little value in showing an employee dozens of fields simply because Bitrix24 provides them. A card should contain the information needed at that particular stage: lead source, product, deal value, company details, responsible employee, documents, deadlines, or other business-specific data.

A single universal pipeline does not work for every company. Selling a new service, working with an existing customer, and participating in a tender may involve completely different stages and employees.

Bitrix24 allows these processes to be separated into different deal pipelines. Each pipeline can have its own stages and automation. For example, the same CRM can contain separate pipelines for new sales, existing customers, and partner sales without mixing all of them into one board.

Stages should also correspond to real events. A stage called “In Progress” tells a manager very little about what is actually happening. “Initial Information Received,” “Proposal Sent,” “Contract Under Review,” or “Awaiting Payment” describes the deal much more accurately and allows specific actions to be linked to each stage.

A significant part of Bitrix24 automation is built around automation rules and triggers.

An automation rule performs an action when specified conditions are met: it can create a task, send a notification or email, generate a document, change the responsible employee, or start another process. A trigger works differently: it monitors an event and can move a CRM item to the appropriate stage. Such an event may be an incoming call, a field change, a customer action, or a payment.

In practice, these mechanisms can be combined into fairly complex scenarios. A deal reaches the contract preparation stage, and the legal department automatically receives a task. Once the document is ready, the sales manager gets a notification. The customer pays the invoice, the deal moves to the next stage, and another task is created. If an action is not completed within the specified time, the manager is notified.

Conditions, execution times, and sequences can be configured for automation. Bitrix24 also supports variables and constants, while complex scenarios can be tested and reviewed through execution logs. More sophisticated logic can be implemented with the business process designer.

We do not try to automate everything. Good automation removes repetitive work. Bad automation creates dozens of tasks and notifications that employees stop paying attention to within a week.

Discuss Your Bitrix24 Project

Not every company process is a sale. Contract approval, procurement, claims processing, equipment allocation, or partner requests often fit poorly into the standard “deal” entity.

Bitrix24 Smart Processes can be used for these scenarios. A company can essentially create its own entity inside the platform and define its fields, cards, stages, Kanban board, pipelines, permissions, automation rules, and triggers. Smart Processes can operate inside the CRM or become separate automated workflows for different departments.

For example, a deal can remain in the sales CRM until the contract is signed, while the subsequent delivery or project execution is moved into a separate process with its own stages, employees, documents, and deadlines. This avoids extending the sales pipeline with stages that no longer have anything to do with the sales manager’s work.

Smart Processes are one of the tools that allow Bitrix24 to be adapted quite extensively without developing a separate CRM from scratch.

CRM and tasks are closely connected in Bitrix24. A deal can automatically create a task, assign an employee, add participants, set a deadline, and use the task status in further automation.

We try to build the system so that a sales manager does not have to constantly remember what to do next. If a customer needs to be called two days after receiving a proposal, the CRM can create the activity automatically. If a lawyer or accountant needs to become involved at a certain stage, the relevant task appears without the sales manager having to send a separate message.

At the same time, the portal should not become a machine for generating hundreds of meaningless tasks. We determine where a CRM activity or notification is sufficient and where a proper task with an assignee and deadline is actually necessary.

Bitrix24 permissions can be configured according to user roles and CRM entities. A sales manager can work only with their own deals, a department head can access the team’s data, and a sales director can work across all pipelines. Permissions may also differ between individual sales pipelines.

Separate access settings are available for documents, CRM forms, and other tools. This means that the simple approach of “an employee either has CRM access or does not” is rarely sufficient for a proper implementation.

We configure permissions according to the company structure and actual employee responsibilities. A sales manager does not necessarily need the ability to modify automation settings or delete deals. A department head, on the other hand, may need access to several teams without having administrator rights across the entire Bitrix24 portal.

Users with multiple roles require particular attention. Overlapping permissions may give an employee more access than originally intended, so permissions should be checked using test accounts before the system goes live.

A website inquiry should not end up as another email in a shared sales inbox. Forms can be connected to Bitrix24 so that an inquiry immediately enters the CRM, retains the required data, and starts the appropriate processing scenario.

Depending on the CRM structure, the system can create a lead or immediately create a contact, company, and deal. Additional parameters can also be transferred, such as the form type, source page, product of interest, or other information required to route the inquiry correctly.

Bitrix24 provides its own CRM forms with separate permissions for viewing, creating, and editing them. However, companies do not have to use only built-in forms. If the website already has custom forms, their data can also be sent directly to the CRM.

The important part is not simply transferring the form data. What happens next matters more: who receives the inquiry, how the responsible employee is selected, how quickly the customer must be contacted, and what happens if no action is taken. These rules should be part of the overall CRM implementation.

Discuss Your Bitrix24 Project

A history of customer communication is valuable when it is connected to the customer record and the relevant deal. This is why CRM implementation should cover not only sales pipelines but also the communication channels used by the sales team.

Depending on the company’s infrastructure, email, telephony, and other communication channels can be connected to Bitrix24. Calls and emails become part of the interaction history, while events from these channels can also be used in CRM automation.

As a result, a new sales manager, department head, or colleague joining a deal can see the context of previous communication instead of trying to reconstruct it from another employee’s personal mailbox.

Documents can be generated using data already stored in the CRM. Bitrix24 supports templates that can use information from CRM cards to create invoices, certificates, delivery notes, and other documents.

Document permissions can also be configured separately. Access to templates, viewing, and editing can be restricted according to user roles. For example, changes to a contract template can be limited to an administrator or department head, while sales managers are only allowed to generate documents from the approved version.

This is particularly useful for processes where the same type of document is created dozens of times and differs mainly in customer details, deal value, dates, and other information already stored in the CRM.

Most companies already use software that cannot simply be replaced by a CRM. Accounting may run in 1C, inquiries arrive through the website, some data may be stored in an internal system, while telephony, payment services, delivery platforms, or industry-specific software are also part of the infrastructure.

During implementation, we determine which data needs to move between these systems and Bitrix24. The important question is not simply whether integration is technically possible, but which system should be the primary source for each type of information.

For example, a deal and the sales manager’s activity may be managed in Bitrix24, while actual payment information comes from 1C. The CRM receives the payment status and starts the next workflow. In another architecture, some information may move in the opposite direction, from Bitrix24 to an external system.

APIs and webhooks can be used for custom integrations. This means the scope of a project is not limited to the ready-made applications available in the Bitrix24 marketplace.

A dashboard can contain dozens of charts, but they are useless if sales managers do not maintain their deals correctly. This is why we configure analytics after the CRM entities, stages, and mandatory actions have been defined.

A manager usually needs more than the final sales figure. It is often more useful to understand how many inquiries were received, how many were qualified, how many proposals were sent, where deals remain stuck, and at which stages opportunities are most frequently lost.

The relevant metrics depend on the business. A company with a long sales cycle needs one set of indicators, while a business processing a large volume of short sales needs another. There is no universal list of five “essential CRM reports” that works equally well for every company.

Discuss Your Bitrix24 Project

Quite often, we are not dealing with a new Bitrix24 portal but with a system the company has already been using for several years. This is a separate type of project.

We start by examining the CRM structure: pipelines and stages, custom fields, cards, roles, automation, and integrations. We determine which elements employees actually use and which ones remain from previous implementation attempts. Automation rules and triggers deserve particular attention. In older portals, the same process may have been rebuilt several times, leaving behind rules whose original purpose is no longer clear to anyone.

An audit does not necessarily mean rebuilding everything. We keep the parts that work and gradually improve the problematic areas. For employees, this is usually much easier than suddenly receiving a completely different CRM and having to learn their workflows again.

The first stage is understanding the processes. We need to see where inquiries come from, who works with them, which stages a deal passes through, which documents are involved, which systems are already in use, and where manual work or data loss currently occurs.

We then design the CRM structure: the lead model, deal pipelines, stages, cards, and required fields. After that, we configure roles and permissions, automation, tasks, and the necessary integrations.

The next stage is testing with realistic scenarios. We run a deal from beginning to end: create an inquiry, check its assignment, move it through the stages, verify automation rules, tasks, documents, and data exchange with external systems. Complex automation is tested separately so that an error in a single condition does not first appear while employees are already working with real customers.

After launch, the system can be refined based on actual usage. The first few weeks often reveal where employees need a shorter workflow, which field turned out to be unnecessary, and which manual operation should be automated next.

Our rate starts at RUB 2,200 per hour. This format works well for audits, individual configuration tasks, pipeline improvements, automation, and smaller integrations.

For a full implementation, we first define the scope of work and estimate the project as a whole. The cost depends less on the number of employees than on the complexity of the processes: the number of pipelines, roles, automated scenarios, integrations, and the amount of custom development required.

A small sales department may need one pipeline, several roles, and basic automation. A larger project may involve several sales pipelines, Smart Processes, 1C, a website, telephony, and custom integrations operating simultaneously. Pricing both projects with the same standard “implementation package” would make little sense.

We do not believe that every requirement should be implemented inside Bitrix24 at any cost.

As long as the company’s processes can be reasonably handled with deals, Smart Processes, business processes, and integrations, developing the existing platform is usually the practical choice. But when most of the project turns into workarounds, a large amount of business logic has to live outside the platform, completely separate interfaces are required for different types of users, or Bitrix24 is effectively being used only as a database, it makes sense to consider an alternative.

In these cases, BFD can design a separate CRM using Laravel and other web technologies. This means we can compare both approaches when evaluating the project rather than trying to force every requirement into a single platform.

Tell us how your sales process works today and what you want to move into the CRM. We will review the workflow, examine your existing Bitrix24 environment if you already use one, and propose a practical scope of work without unnecessary configuration or automation for its own sake.

Discuss Your Bitrix24 Project