You can assess a CRM implementation through an employee's ordinary work: receive an enquiry, find the customer, take the next step, hand a task to a colleague and handle an error. The number of fields and automation rules created does not, by itself, show whether the team is ready.
We will use an illustrative launch for a small company: website enquiries, one sales pipeline, several sales representatives and a manager. Use it to build your own deliverable list and run checks. Telephony, inventory integration and complex business processes are not automatically included in this example.
Agree on the working journey before configuration
Ask a sales representative to show one recent sale without exposing unnecessary customer data. Where did the request come from, who replied, where was the proposal prepared, when was the next contact scheduled and how did they know the work was complete? Describe an exception alongside it: the representative is absent or the customer returns with a new task.
Describe work states in plain language. “Clarifying the task” means contact has been established but information for a proposal is still missing. “Proposal sent” requires an actual send, not an intention to prepare one. Define the action and owner for each transition.
You do not need to carry every habit over from the old spreadsheet. If nobody uses a field to make a decision, ask why it is needed. A required field with no available value encourages employees to enter arbitrary data.
| State | Employee action | How to check the transition |
|---|---|---|
| New enquiry | Checks contact details and assigns a next action | There is an owner and a clear task |
| Clarifying the task | Collects missing requirements | Information needed for the proposal is complete |
| Proposal sent | Records the send and agreed next contact | A document or action record exists |
This is an example, not a mandatory Bitrix24 pipeline. A service company and a shop will have different states. Your stages should explain your team's actual work.
What each stage should deliver
The official Bitrix24 implementation overview identifies analysis, configuration, training and ongoing monitoring. To assess a specific project, each stage needs a tangible deliverable.
- Discovery: a diagram of one process, participants, fields, enquiry sources and exceptions.
- Configuration: a working CRM journey, agreed records and roles.
- Migration: field map, test import, discrepancy report and preserved relationships.
- Integrations: verified data transfer, error monitoring and stop instructions.
- Training: employees perform their scenarios independently.
- Handover: instructions, company-controlled access, limitations and a support owner.
Mark excluded work directly in the plan. If telephony belongs to the next stage, its absence should not unexpectedly block acceptance of the form. But if the form is in scope, demonstrating manual record creation cannot substitute for testing it.
Prepare people and test conditions
You need a business representative, an ordinary sales representative, an administrator and the provider. One person may hold several roles, but test each using the appropriate permissions. An administrator usually has broader access and may miss a field unavailable to sales staff or a restricted deal visible to everyone.
Bitrix24 supports CRM roles and permissions; availability of the role model depends on the plan. The official permissions guide describes current settings and conditions. First agree on an access matrix in words: who may read, edit, delete and export data. Check that the Russian-market documentation applies to the edition and account you use.
Use agreed test records. Warn notification recipients, disable unapproved external actions in the test environment and define how test results will be cleaned up. Do not create a practice order that the warehouse will treat as real.
Follow one enquiry from start to finish
- Open the connected form and enter test data with a recognisable label.
- Find the enquiry in the CRM; verify contact details, text, selected service and source.
- Check owner assignment and receipt of the expected notification.
- As a sales representative, take the next action and change the stage under the agreed rule.
- Add the conversation outcome and schedule the next contact.
- Hand the enquiry to a colleague; check that the new owner can see the required data.
- Complete the practice deal with the agreed outcome and find it in the report.
Record the actual result after each step. “Email sent” and “enquiry saved” are different checks. A record may exist even when its notification does not arrive; a website may show “Thank you” while the record is still missing.
Check values and actions first, then usability. A poor field label matters, but a lost enquiry needs a more urgent response. Separate issues that block work, affect a particular scenario and represent future improvements.
Go beyond the ideal scenario
| Check | Expected result | What to record |
|---|---|---|
| Repeated delivery of the same enquiry | No second record from a technical retry | Event identifier and result |
| New request from the same customer | The separate enquiry is retained | Link to the contact |
| Missing required data | Clear error or manual review | Location of the original enquiry |
| Sales representative absent | The agreed reassignment procedure works | Who received the enquiry |
| External service unavailable | Waiting or error status is visible; data is retained | Who restores the integration and how |
Test prohibitions separately: a sales representative cannot see restricted records, export prohibited data or alter system settings. Confirming that permitted actions work does not prove that restrictions hold.
Decide in advance who handles each error. If a field disappears from the source, sales staff need a clear manual path, while the technical specialist needs diagnostic information without unnecessary disclosure of customer data.
A completed acceptance-test entry
Suppose a test enquiry was saved, but the selected service is blank. “The form works badly” is not enough to reproduce the problem quickly. A more useful entry is:
Scenario F-03: enquiry from the support page. Roles: visitor, then sales representative. Expected: “Service” equals “Website support”. Actual: enquiry created; field empty. Evidence: test time and practice-record identifier. Priority: fix before launch because the service determines team assignment. Retest: submit the same scenario with a new event identifier and check the field and owner.
Do not erase the original entry after a fix. Add the retest date and result. This distinguishes issues actually closed from those merely marked fixed by the provider.
Verify training through action
After a demonstration, ask the sales representative to process a new practice enquiry independently. They should find the customer, record a conversation and assign the next action without the instructor's prompts. Add difficult steps to the instructions instead of blaming the employee for inattention.
The manager must be able to find unprocessed enquiries and understand what a report includes. The administrator needs instructions for access, reference-data updates and stopping the integration. A one-hour call recording is a useful supplement, but finding one action in it is awkward: prepare short, role-specific guides.
Example task for a representative: “Find the practice customer, create a new enquiry for another service and schedule the next contact.” This tests real work and helps distinguish a new deal from a duplicate contact.
Hand the system over and monitor launch
Check who owns the portal, connected accounts and integration settings. Company access should not depend on a contractor's personal phone. Transfer passwords and tokens through an agreed secure method, separately from public instructions.
The handover pack should include the process diagram, access matrix, integration list, acceptance log, employee instructions, limitations and support procedure. For custom development, clarify which materials and source files will be handed over under the agreement.
During the first working cycles, reconcile incoming enquiries with CRM results and collect employee difficulties. The monitoring period depends on work frequency: one error-free day with two enquiries says little about a monthly process. Watch processing delays and manual workarounds separately.
When to stop acceptance
Do not accept a critical scenario as ready if enquiries disappear, permissions expose too much, errors are invisible or the team lacks a manual fallback. Keep a blocker list and retest after corrections. Cosmetic requests can be handled separately from failures to meet the agreed result.
If the company has not appointed a process owner or agreed stage rules, postpone a large project until those decisions are made. A simple journey may need only self-configuration and help-centre training. Compare scope with the implementation estimate, and prepare old records using the database migration guide.
Terms for a shared understanding
- Pipeline — agreed states of work on a deal.
- Role — an employee's permitted actions.
- Acceptance scenario — a sequence of steps with an expected result.
- Blocker — a fault that makes agreed work impossible or unsafe.
- Handover — the materials, access and knowledge the company needs to continue operating.
Apply this to your task
List implementation deliverables and test ordinary and error scenarios using employees' actual working roles.
Bitrix24 implementation acceptance record: open the worksheet · Download the CSV to complete. Free access, no registration. Use it yourself or share it with your provider.