Setting up hiring in Bitrix24: where the recruitment funnel falls apart
A typical DIY recruitment setup looks like this: an application arrives at the vacancy email, is duplicated to the manager's messenger and the department's general chat — and lives there.
There is no single "candidate" entity, so the same person is created twice, and some applications never even reach review. These are the lost applications: not a rejection, but the absence of a decision.
Statuses are tracked in spreadsheets, where updates depend on whether the recruiter remembered. Manual recruitment rests on memory and chats: no deadline for the first response, no escalation rule, no visible list of those who have been waiting for a response for a second day. A strong candidate goes to whoever responded earlier — and this is learned after the fact.
Context falls apart between stages. The resume sits in email, the interviewer's notes in direct messages, the meeting agreement in the calendar, and the offer terms in someone else's spreadsheet.
When a vacancy is handed over to another specialist, the history isn't restored, and the candidate has to be re-interviewed. Candidate tracking turns into file tracking.
Setting up hiring in Bitrix24 removes this fork: an application becomes a card in the candidate recruitment funnel, the stage changes by rule, not by memory, and both the manager and the recruiter can see the deadlines at each step. We break down how this is assembled and where mistakes most often happen during migration.
What hiring automation delivers: measurable effect
The effect of hiring automation is measured by three variables that don't depend on feelings: how many days a vacancy takes to reach an offer, what share of applications receive a response, and how many manual actions each selection stage requires. Setting up hiring in Bitrix24 changes exactly these, not "convenience overall."
Time to close a vacancy
The clock starts not from publication of the ad, but from the moment the recruitment request entered the system: this shows the real time, including approvals.
Each stage transition is recorded automatically, so it's immediately clear where the vacancy is idle — with the approver, with the recruiter, or between interviews.
The main loss goes away: the candidate no longer sits in email while the responsible person is busy with another task. Time to close is reduced by days.
Unified candidate registry
Applications, emails, resumes, and feedback are put into a single card linked to the vacancy and selection stage. A candidate from a past search isn't lost: for a new vacancy, they are found by skills, not by digging through the correspondence archive.
Duplicates are merged, so the "call later" folder stops being a black hole. The share of applications with a response grows: the notification goes out at its stage, without manual reminders.
Fewer manual actions per stage
Previously, one selection stage required an email, a reminder, forwarding a resume, and a mark in the spreadsheet. Now a stage change itself creates a task for the responsible person, the email goes out from a template, and the history remains in the candidate card.
The recruiter spends time talking to the person, not maintaining the registry. As a result, one specialist handles more vacancies without losing selection quality.
Ways to run recruitment: comparison of operating modes
The recruitment scheme is chosen by three criteria: how many vacancies are open at the same time, how many roles participate in evaluation, and whether access to applicant data needs to be separated.
This determines whether recruitment will live in a shared funnel or require a separate entity with its own stages. Below are the options we configure and their limitations.
| Variant | When it fits | Limitations |
|---|---|---|
| Funnel in CRM | up to 10–15 vacancies, recruitment handled by one recruiter | mixed with sales, reports have to be separated manually |
| Recruitment smart process | several areas, its own stages and fields per vacancy | requires setting up rights and discipline around the field reference list |
| Recruitment board | visual control of stages is important | stores status but not evaluation history — needs to be linked to the card |
| Ready-made scenarios | standard hiring without non-standard approvals | logic is hard to modify, updates break customizations |
| Hybrid scheme | recruitment and sales in one environment, different rights | more expensive to set up: separation of entities and synchronization of reference lists |
Pure schemes are rare in practice: recruitment and sales almost always coexist in one environment. The hybrid option addresses this better than the rest — deals and candidates live in different entities, and reporting is collected for both flows.
We handle transitions between options without losing history: candidate cards are transferred, stages and responsible persons are preserved.
Implementation stages: from process audit to handover
The audit comes before setup: if you first install robots and don't break down the participants' roles, the system cements the current order along with its bottlenecks. That's why the stages proceed sequentially, with checks on live data.
- Recruitment process audit. We collect the actual picture: where applications come from, who makes a decision at which step, how long a candidate waits for a response, and where resumes are lost. The result is a map of stages and a list of operations taken off people's hands.
- Business process design. We describe the funnel in Bitrix24 and the candidate card: stages, required fields, role rights, conditions for transition and return from rejection. We agree on the scheme before setup — changing it in a live system is more expensive.
- Robot setup. Automatic actions by stage: email to the candidate, task for the recruiter, reminder about a stalled stage, auto-transition by condition, documents by template. There we also connect channels so an application reaches the card without manual transfer.
- Testing on live data. We run each branch with real candidates: hire, rejection, return, repeat inquiry, duplicate. We check that robots trigger by condition, notifications aren't duplicated, and history isn't lost.
- Training and regulations. We show the team how to work in the new stages and what to do in case of failure, and leave a short role-based guide.
- Handover to support. We hand over documentation and access, and record the change procedure: how to add a stage, disable a robot, whom to contact in case of an incident.
What you have after the project is completed
After the project is delivered, you're left not with a set of settings in the interface, but with a set of artifacts that the team uses to work and develop hiring without us.
Everything is documented and handed over along with access — the configuration in Bitrix24 can be opened months later and you can understand why a stage is set up the way it is.
- Recruitment process scheme — funnel stages from application to offer, conditions for transitions between them, and automatic actions at each step.
- Configured recruitment business processes — vacancy approval, stage-by-stage evaluation, feedback collection, moving a candidate to rejection with a required reason.
- Role rights — access matrix: what the recruiter, manager, and interviewer can see, who can change stages and delete cards.
- Regulations for the recruiter — procedure for managing a candidate, response deadlines at each stage, rules for filling fields, and permissible rejection reasons.
- Instructions — step-by-step guides for typical actions: create a vacancy, schedule an interview, export a report, designed for a new employee without training.
- Templates and cards — fields for key candidate data, email and auto-reply texts, unified vacancy numbering.
- Support procedure — where settings are stored, how to safely change stages, what to do if automation fails, and where to request modifications.
We hand over everything along with a walkthrough: we run scenarios with your recruiter and administrator, adjust the wording of the regulations, and answer questions along the way.
Case study: recruitment in a retail chain before and after setup
A retail chain with several dozen locations hired salespeople and cashiers continuously: applications came to job boards, email, and messengers, and were manually consolidated into one spreadsheet once a week.
Candidates waited two to three days for a response and often went to those who responded faster, while the location manager learned about a shift shortage exactly at the moment it occurred.
We built a unified recruitment environment in Bitrix24: a vacancy is a card in the funnel with stages from application to start, each stage has its own owner and standard deadline.
Robots respond to the candidate with a template within the first minutes, move the card through stages, and escalate the task if a stage remains overdue.
The overdue report shows not "how many people are in progress," but which vacancies have exceeded the deadline and at which step they got stuck.
The recruitment automation case study produced the following dynamics in metrics before and after:
- Candidate response time: 2–3 days → 4–6 hours; share of applications with a response within the first 24 hours — from 34% to 91%.
- Time from application to first shift: 24 days → 11.
- Share of vacancies with overdue closing deadlines: 41% → 13%.
- Stages without an assigned owner: 6 out of 11 → none.
Rules live as separate entities, so a new store is connected by copying the template, and stages and robots are transferred between portals without manual reconfiguration.
The effect isn't in response speed as such: recruitment timelines became manageable — the bottleneck is visible in the summary report on the same day and is closed before a shift remains understaffed.
How does a CRM funnel differ from a recruitment smart process?
The first question when setting up hiring is which entity to build the scheme on. A CRM funnel is stages inside the standard lead or deal: it's assembled quickly, but lives in a shared space with sales.
A smart process in Bitrix24 is a separate entity with its own funnel, fields, rights, and automations that doesn't intersect with sales.
The difference shows up in reporting and access. When hiring and sales run in one funnel, analytics get mixed, and the recruiter sees extra data.
A smart process separates the flows: a funnel can be built for each area or grade and restrict recruiters' access only to candidate cards.
Practical rule: for one candidate flow, a CRM funnel is enough. Multiple areas, high-volume recruitment, external contractors, isolation of personal data — a smart process is needed. It's more expensive at the setup stage, but it doesn't need to be redone as the flow grows.
If the portal is already deployed, nothing needs to be broken. The smart process is deployed in parallel: deals, tasks, and processes of other departments continue to work, and the new scheme connects to them selectively.
When hiring is already run in CRM, we migrate the scheme: cards are transferred in batches, stages and fields are mapped one-to-one, links and open tasks are preserved — candidate history isn't interrupted. Automations and rights on the new entity are configured from scratch; old rules aren't transferred.
Technical concerns before the project starts
Transferring the candidate database, integration with the job site, role rights, and impact on current portal processes are four questions that come up in the very first discussion. Below is how each of them is addressed in practice.
How do we transfer candidates from the current system?
We export resumes, stage history, recruiter comments, and attachments and map them one-to-one to the stages of the new funnel.
The transfer is done on a copy of the portal, after which we compare the number of cards at each stage: discrepancies are visible before going live, not after.
What about integrating the job site with the portal?
We configure the application form and resume parsing so that the candidate lands in the right stage of the right funnel together with the source and campaign tags. Repeat applications are filtered by phone and email address, so duplicates don't multiply across stages.
How do we separate access for recruiters and managers?
We set rights by roles and zones: the recruiter works only with their vacancies and cards, the manager sees their department, the administrator sees funnel settings. Restrictions apply at the level of stage and fields, so candidates and agreements don't leak between departments.
Will current portal processes be affected?
We move automation into separate funnels, tasks, and rules without touching the working scenarios for deals and projects. We increase the data volume and number of robots gradually so that portal response time remains the same.
Let's discuss the task: recruitment, funnel, business processes
Before proposing a solution, we analyze your current recruitment process: how a request enters the system, at which stages candidates are lost, and where the recruiter switches to manual actions.
Send the description as it is — diagrams from email, funnel screenshots, a list of approvers. That's enough for us to come back with an estimate and a work plan broken down by stages and artifacts.
What will be included in the plan and what you will get as a result:
- Map of the current process: recruitment stages, responsible parties, bottlenecks, and candidate processing time at each step
- Funnel and stage scheme with candidate card fields, role rights, and transition triggers
- Business processes: assigning tasks to the recruiter, approving the job offer, notifications and reminders for responsible parties
- Integrations with email, calendar, email templates, and telephony, if it is involved in recruitment
- Launch regulations: hiring implementation stages, who is needed from the client side at each step, readiness criteria
- Transition without stopping recruitment: recruiter training, test environment, procedure for transferring active candidates
- Portal support terms: response to failures, modifications when the process changes, monitoring of automated scenarios
Describe the recruitment task as it looks now — we'll come back with an estimate and a work plan, including portal support. Then you decide: start with one department or roll out implementation across the entire hiring environment at once.