Turnkey setup of surveys and questionnaires in Bitrix24

Why native Bitrix24 surveys do not provide a complete picture

The built-in survey module in Bitrix24 covers a one-off scenario: create a questionnaire, send it to the news feed, view a chart. Once there are several surveys — onboarding for newcomers, engagement, contractor evaluation — the holistic picture falls apart.

The first typical failure is fragmented forms. Some questionnaires live in the built-in module, some in forms on the website or in CRM, and some are collected manually in spreadsheets.

Responses land in different entities, and the keys do not match: sometimes an employee ID, sometimes email, sometimes nothing. Collecting employee responses turns into manual data collection — export, matching, merging tabs — and each new survey increases that work.

The second failure is lost responses and duplicates. A native questionnaire does not link a response to a department or role, and resubmission creates a second response for the same person, so the branch share is counted twice.

Feedback management is not closed-loop into processes: the result does not create an assignment, does not change status, and does not return to the manager as a task with an assignee and deadline.

Hence the cost: numbers cease to be comparable between measurement waves because the sample and wording change each time. The survey is conducted, the report is shown, no decision is made — and the next measurement has nothing to compare against. Below we analyze how this is addressed.

What changes after moving surveying into a single loop

Moving surveying into a single loop changes not the filling form but what happens to responses after submission.

Previously, exports scattered across files and emails; now responses go into one storage inside Bitrix24, and reporting is assembled according to a repeatable scenario. Below is what to check in the system so the effect is measurable rather than declarative.

Collection and processing

• The collection cycle shortens: a response is visible in the system immediately, and intermediate file forwarding between employees disappears.
• Survey automation eliminates reconciliation — parsing rules fill the required fields themselves, and manual processing remains only for non-standard cases.
• A single response database replaces a set of spreadsheets: one questionnaire, one storage, and duplicates and lost file versions disappear.

Reporting and analytics

• Survey reporting is assembled on schedule, not on request: the summary arrives with the same set of fields each period.
• Response analytics is built on breakdowns — department, period, questionnaire version — and does not require manual sample reassembly.
• The reduction in manual processing is measured by the share of questionnaires brought to report without human involvement; this share is visible in the processing log.

What we check first

• Completed questionnaires are not lost during a failure and are not duplicated on resubmission.
• Editing a questionnaire does not break statistics from past periods: versions of questions and answer options are preserved.
• Access to responses is delineated: an employee sees only their own department and their own sections.

Options for implementing Bitrix24 surveys: comparison of approaches

Native portal mechanisms cover standard response collection: a poll in the feed, a questionnaire in a deal or contact card, a question inside a business process. Then the fork begins — either customize the configuration, move the form outside, or combine both approaches. Below is what each option provides and where it hits limitations.

The choice is determined not by interface convenience but by what should happen to the response after submission. If data lives in portal reports, native forms suffice.

If the response changes the deal stage, triggers a process, or affects metrics, customization or integration with an external source is needed.

Implementation stages: from process audit to handover of regulations

A Bitrix24 survey breaks not at the form level but at the data level: if questions were assembled "however was convenient at the time," results later cannot be consolidated by department or linked to cards.

That is why implementation runs as an engineering project centered on the data and permission schema, with form assembly as a consequence.

1. Process audit. We analyze which decisions are made based on survey results and who makes them. The output is a list of questions with justification for each and a list of entities to which responses need to be linked.
2. Survey data schema. We design question types, required fields, branching, scales, and category dictionaries. Here we also define links to cards and rules for calculating aggregates: average score, share choosing an option, dynamics by periods.
3. Rights and access. Role matrix: who edits the questionnaire, who sees individual responses, who sees only the summary. We establish anonymity technically, not in words, otherwise there will be no honest answers.
4. Setup and automation. We assemble forms, branching, reminders, and tasks to the responsible person for low scores. We check that data reaches analytics, not only the card.
5. Testing forms on a pilot group. We run all branches: empty and incomplete responses, resubmissions, access to others' results, export. We look at which question people drop off on and why.
6. Handover of regulations. We provide instructions to the administrator and users, the rights matrix, the procedure for changing the questionnaire, and export rules. After that, the team changes questions and roles without us.

Schemes, templates, and access rules in the handover package

We hand over not screenshots of settings but a working configuration: the client edits questions, assigns access, and exports responses. All survey documentation is in the portal knowledge base — with the build date and the owner responsible for keeping it current.

• Survey forms: field composition, required status, branching by answers, department binding, and placement map — where each questionnaire opens.
• Result access rules: role matrix — who sees summary breakdowns, who sees personal responses, where anonymous mode is enabled and how it is confirmed.
• Questionnaire templates for recurring tasks: post-deal evaluation, employee survey, service feedback — with ready-made question blocks and scales.
• Administrator instructions: step by step — add a question, close collection, restart exchange with an external system, export a breakdown for a period.
• Response processing regulations: response times to evaluation, route for passing negative feedback to the responsible person, recording the outcome in the client card.
• Configured exports and reports: breakdown forms, data exchange formats, schedule for automatic sending of summaries to managers.
• Support regulations: frequency of data integrity checks, control points, and procedure for edits when the org structure changes.

The package removes dependence on the contractor: a new survey launches from a template rather than development from scratch.

Case study: employee surveying in a retail chain

A retail chain — several dozen locations and high employee turnover. Feedback was collected with paper questionnaires and a shared spreadsheet: filled out at the location, responses transferred manually, non-respondents called separately.

The survey cycle stretched over two weeks, and some questionnaires were lost on the way to the office.

We moved surveying into Bitrix24: the form opens in the employee card, responses go into structured storage, and the summary is built automatically for each location.

Anonymity is configured so the response is linked to the location and shift, but not to the name — the honesty of ratings increased.

What automatic reminders delivered

The invitation goes out on the wave start day, the repeat after two days, and on the fifth day the location manager joins. Reminders go to the work chat, so they do not depend on shifts and vacations, and completion status is visible for each employee.

Data completeness rests not on discipline but on process design: the response immediately enters the summary and cannot be lost.

Discrepancies between the report and source data no longer arise, and the network-wide breakdown is assembled on the wave close day instead of two weeks.

What to do if responses are already collected in a third-party form?

The first step is source inventory: list all forms and services through which responses arrived, who owns each, which fields were collected, and in what form the accumulated records exist. Until the list is complete, any migration produces duplicates and missing audience segments.

Next is field mapping: each column of the external questionnaire gets a place in Bitrix24 entities — contact, company, smart process item, custom field.

Single choice maps to a list, multiple choice to a multiple field, ratings and scales are transferred as is, and the original response is saved in a separate text field: during data reconciliation there will be something to compare against.

Migration of accumulated responses proceeds in batches with duplicate checks by email and phone — a repeat inquiry is linked to an existing contact rather than creating a second one.

Then control: record count before and after, sums by numeric fields, manual spot-check of a dozen questionnaires. A discrepancy here means a mapping error, not an export error.

Separately, we decide how to collect going forward: move the questionnaire into the system or keep the external form and set up automatic receipt of responses into the card.

In both cases there is a single point of truth — the record in the system — and the old form link is not removed but redirects to the new one, so as not to lose clicks from already published ads and mailings.

Technical concerns and limitations of the solution

Before approving the survey structure, it is worth resolving several questions that come up during design: what the platform can do natively, and where limitations and organizational risks begin.

Will there be load on the portal during a mass survey?

The portal can handle simultaneous completion by several hundred employees if invitation sending, reminders, and report generation are staggered over time, and exports are calculated on schedule rather than at peak activity.

The main load comes not from the responses themselves but from accompanying scenarios — notifications and synchronization with external systems.

What happens to the survey when the company structure changes?

The portal structure is the source of rights and recipients: renaming departments, changing managers, and the emergence of new departments immediately affect the survey.

If the questionnaire is linked to departments rather than fixed employee lists, changes are picked up without rebuilding.

For historical breakdowns, we save a snapshot of the structure as of the survey date — otherwise old reports are recalculated under the new hierarchy, and dynamics cease to be comparable.

Let's discuss the task and come back with an estimate and work plan

To come back with a timeline estimate rather than general wording, we need initial inputs for the task. Describe in free form where the survey should live — in a deal card, on the portal, or on a public page — who takes it, and where responses should go. This is already enough to discuss the task substantively and outline the scope of work.

Then we clarify details and compile the implementation plan as a document: what we do, in what order, what we check at each step. From you, we usually need the following:

• questionnaire logic — which questions we ask, whether there is branching, and which answers trigger it;
• where the result is written: deal or contact fields, tasks for responsible persons, notifications;
• list of fields and dictionaries already in the system, so as not to create duplicates;
• access rules — who sees full responses, who sees only the summary, who needs export;
• adjacent systems: 1C, mailings, telephony, external services, if the survey must exchange data with them;
• reporting — which breakdowns management needs and at what frequency;
• dates by which the survey must be operational, if tied to an event or launch.

Send these inputs — we will come back with an implementation plan, scope of work, and timeline estimate. If some details are not yet defined, we will lock them down during the first review.