Setting up resource planning in Bitrix24

Why resource planning in Bitrix24 does not match actuals

The portal stores tasks and deals, but does not know team capacity.

Resource planning in Bitrix24 breaks where the list of works must be compared with the actual pool of hours: a task has an assignee and a deadline, but there is no data on how much of their time has already been consumed by other projects.

Hence the discrepancy. Utilization lives outside the portal — in spreadsheets, in chats, in the manager's memory. In a spreadsheet an engineer has one row per project, but in reality they run three parallel tracks, are on support duty, and spend part of the day on approvals.

Planning in spreadsheets shows employee utilization at one hundred percent, while actual is noticeably higher.

Then a cascade triggers: a task hangs "in progress" for a week without movement, but the system stays silent — it does not compare the remaining work with the assignee's calendar time.

A project deadline miss surfaces at a review when there is nothing left to shift, and team overload is visible only in a post factum report by the number of closed tasks.

The cause is not people's discipline, but that plan and actual live in different contours: plan — in a spreadsheet, actual — in tasks, with no connection between them in either direction. Until the contours are brought together, any schedule remains a forecast on paper. We analyze how this is closed with the portal's standard tools.

What a unified load contour provides: effect in measurable values

A unified load contour removes the main cause of misses — the discrepancy between how work was allocated in conversation and what is actually in the plan. Below — what changes in measurable values after implementation.

Utilization is transparent over a horizon of several weeks

The manager sees a summary picture across the team, the engineer — their own load and free windows. Overload is detected at the task assignment stage, not on delivery day, so the share of works moved to the next cycle stops growing.

Planning comes from actuals, not expectations

Project estimates are compared with actual labor costs on similar works. The plan includes the real team velocity, so deadlines are set with adjustment for already known resistance, not with hope for a lucky coincidence.

Load accounting by projects — in one picture

Load is collected automatically: tasks, participation in related work, absences, reserve for support. The utilization report is built from the same data as the plan, so the plan/actual discrepancy is visible immediately, not surfacing at acceptance.

Manual spreadsheet reconciliation goes away

No need to consolidate exports and fix formulas — data for planning and reporting is the same. The failure class "everything stalled because the key assignee is overloaded" is closed: reserve is allocated in advance for a peak or the start is shifted.

Ways to run resource planning: comparison of modes

Planning modes are chosen not by the beauty of diagrams, but by the work contour: one long project, a flow of short requests, or a team loaded by roles. In Bitrix24 all schemes are built on the same tasks and calendar, but give a different load picture.

Comparison of modes

Planning limitations are common to all modes: overload is calculated by the working time calendar, not by the assignee's promises, and visibility of others' loads is granted through roles and permissions.

When there are several work contours, the modes are combined: project-based — for large initiatives, role-based — for request flow, scenario — for validating decisions before start.

Implementation stages: from utilization audit to regulation

Resource planning in Bitrix24 is not enabled with one switch: first you need to understand how people and tasks are actually distributed in the company, and only then transfer this into the system. If you start with reference books, you get a neat structure that no one uses. Therefore we proceed sequentially — from facts to rules.

1. Utilization audit. We export tasks, calendars, and time tracking for several months, talk with department heads. The output is a map of overloads and idle time: where a person is almost fully engaged, where half, and what works are not accounted for anywhere at all.
2. Distribution scheme. We fix by what attribute a task goes to an assignee — role, project, competence, or queue. Separately we agree on what we consider planned load and what is urgent unplanned work that shifts deadlines.
3. Setting up roles and stages. We configure roles, departments, task types, and stages so that moving a task through stages changes the assignee's load by itself, without manual spreadsheets.
4. Task distribution rules. We set priorities, time norms per work type, and deadline shift rules, and check that the rules do not conflict with each other.
5. Testing on real tasks. We run the current project flow through the new rules and compare the plan with actual utilization. We analyze discrepancies and adjust norms until the picture matches.
6. Handover of regulation. We give a document with the rules, show responsible people how to make changes, and agree on periodic revision of norms.

After the regulation handover, the system lives without us: load is visible by stages, conflicts by assignees surface before deadlines are missed, not after.

Load schemes, access roles, and utilization reports

After implementing resource planning, what remains in the system is not a "configured portal" but a set of artifacts by which the manager works without us. The check is simple: if the scheme cannot be read without its author, the work is not finished.

• Load scheme — map of entities: which tasks and projects form utilization, how employee, project, and period are connected, where planned capacity comes from. From it the administrator reproduces the structure from scratch.
• Access policies — roles and visibility levels: a department head sees their team, the project office — a slice across all, an employee — only their own tasks. Overloads are visible where decisions are made.
• Utilization reports — slices by person, team, and period, plan/actual deviation, lists of overloaded and idle. Each report is built on real data and opens without manual export.
• Instructions for managers — one-to-two-screen memos: set a plan for the period, reassign a task, read a report. Learned in one pass, without separate training.
• Update regulation — what is revised and how often: role composition, capacity calculation rules, employee reference, report set. Without it the scheme degrades in a couple of quarters.
• Settings passport and control run — required fields, automatic rules, procedure for transferring the portal to another administrator, and checking scenarios "new employee," "vacation," "parallel projects."

Case: how a department of 40 people stopped planning in spreadsheets

A department of 40 people planned in spreadsheets: deadlines, load, and assignees lived in different files, which everyone edited in their own way. Tasks without an assignee were discovered at acceptance, and engineer overload — already after a deadline shift.

Planning was moved to Bitrix24: load types, calendar working time, distribution by projects and roles.

Metrics before and after

The mechanics are held by two rules. First: a task does not go into work without an assigned assignee and estimated labor intensity.

Second: planned load is compared with the calendar and absences, so double booking of one engineer is visible in advance, not at the delivery stage.

The effect came from the department load report: the manager sees whose time is occupied by projects a little over half, and whose — over capacity. The former are loaded further, the latter are unloaded by redistribution before the client notices a shift.

Forecast accuracy grew not because of stricter estimation, but because estimation stopped diverging from the actual availability of people.

How resource planning differs from employee utilization accounting

Employee utilization accounting answers the question "what has already happened": how many tasks were closed, how many hours were written off, who has an overload in fact.

Data comes from labor costs and task status changes, so the report is assembled only after the work is done. This is a contour of control and results review, not distribution.

Resource planning works with the future. It distributes the upcoming volume across assignees in advance and relies on employee availability: calendar, absences, part-time rate, participation in several projects simultaneously.

The planner matches a task not with a specific person, but with a role — competence, rate, level — and by role selects who will close it.

The main difference is in what is considered a constraint. Accounting sums up the result, planning solves a problem with constraints: how many hours an employee can actually give per week, how many parallel projects they hold, in what role they are available.

Task utilization is composed of these values, so overlaps by deadlines are visible before the start, not at the moment of a miss.

Hence different consequences for management. In fact, overload is recorded when deadlines have already slipped, and all that remains is to explain the causes.

The plan shows a capacity shortage in advance — you can shift a stage, connect a second assignee, or rebuild the sequence.

In practice, both contours work together: the plan sets the forecast, the actual refines it and gradually calibrates norms.

In Bitrix24 they diverge into different tools — the load chart and task reports rely on written-off time, while planning requires filled availability and roles. If availability is not maintained, any calculation remains accounting with a different label.

Technical doubts: permissions, integrations, overloads

Doubts about resource planning usually concern not the load chart itself, but how it fits into an already working portal: who sees others' rates, whether data is pulled from tasks, what happens when projects overlap. Below is an analysis of the questions that most often surface at the evaluation stage.

Is planning connected to tasks and projects?

Yes, assignments rely on the same projects and tasks that are already run in the portal: actual labor costs are pulled from closed tasks, and planned rates are entered in the project card. Double accounting does not arise — plan and actual live in one entity.

What happens if an employee is engaged in several projects?

Rates are summed across all tracks, and the overlap is immediately visible in the chart: if the total load exceeds the available time fund, the cell is highlighted. This allows catching overload at the planning stage, not by the fact of a missed deadline.

Can already accumulated data be transferred?

We transfer from spreadsheets and accounting systems via an intermediate template: we match employees, projects, and rates by reference books, load historical periods for reporting. Erroneous rows are cut off before recording, so duplicates do not remain in the portal.

Let's discuss your load scheme: where do we start

So that the assessment and plan rely on your reality, not on average figures, we need to see the current load scheme in Bitrix24 and around it: how tasks get to assignees, where hours are recorded, who approves deadline shifts. Below is what is worth sending before work starts.

• Composition of roles and divisions between which tasks are distributed, and who approves the final load.
• Export of the employee reference and division structure — from a file or directly from the database, the format does not matter.
• Examples of typical tasks with labor cost estimates: how duration is calculated and what happens on overtime.
• Approval rules: who sets a task, who moves a deadline, what exceptions occur most often.
• Work time and calendar accounting scheme — shifts, part-time day, overlaps with vacations and projects.
• Reports that management reviews regularly, and those that are missing.
• Access restrictions: which test contour can be used for setup and who grants rights.

Next we compare this with the available load accounting mechanisms and show where the standard configuration is enough and where business process improvements are needed.

In response you receive an assessment and plan with resource planning implementation stages: from setting up roles and calendars to reporting and regulation of manager workflow.

Describe the task in a convenient way — we will return with an assessment, a plan, and a work start date.