How to accept a CRM implementation
Follow one order from enquiry to completion. Check roles, fields, automation and exceptions. Download an acceptance checklist and issue log.
Agree the result before the demonstration
CRM acceptance starts with an observable result: an employee takes an order from enquiry to the agreed ending while related data remains correct. Prepare a safe test, run it under real user roles and record findings. After fixes, repeat failed and affected checks.
- Phase scope
- Use the agreed specification and function list. Define an action and expected result for each requirement. Mark excluded work separately.
- Test order
- Prepare an anonymised record with known fields and relationships. Agree the environment, notification recipients and roles.
- Participants
- Assign a future user, a customer-side acceptance owner and a supplier contact handling findings.
- Version and starting state
- Record date, environment, configuration or release version and starting data. Otherwise a retest may cover a different scenario.
Eight checks on one order
An out-of-scope mark is valid when it matches the agreed phase. Not tested does not mean working. Save the expectation, actual outcome and safe evidence for each check.
New enquiry
Create one agreed test enquiry. Find the record in the intended pipeline and reconcile contact, content and source. Check email or messaging separately from the saved record.
Owner and permissions
Open the order as a future employee. Check reading and permitted changes. An action available to an administrator may be unavailable to a manager. Also verify an agreed access restriction.
Required data
Attempt an agreed transition without a required field. Expect the specified constraint. Populate the field and try again. Only require a block where the specification calls for it.
Next action
Check the activity, deadline and notification when included. Verify execution under the relevant conditions. A configured rule and an activity actually created are different pieces of evidence.
Fulfilment and settlement
Complete the test order. Reconcile agreed fields, actual result and related records. For delivery or resources, test reservation, deduction and cancellation separately. A payment flag needs the agreed confirmation source.
Change and retry
Retry the same submission, then send a new task from the same customer. Verify the different event rules. If included, amend a completed order and check that related operations match its new version.
Failure and recovery
Reproduce an agreed integration failure in a test environment. Trace the pending operation, owner notification and recovery. Confirm that a retry has not created an extra record.
Report and handover
Locate the same order in the agreed report and verify what its measures mean. Receive agreed access, instructions, backup procedure, owners and support terms. Record actual outcomes for every check.
Make each finding reproducible
One finding should describe one failure. Replace “automation does not work” with the role, starting data, action and difference between expected and actual behavior. Attach a safe test-record reference or a screenshot without customer data.
- Example A-01
- Illustrative finding: a manager moves a test order to Confirmed. The specification requires a delivery preparation activity, but none appears by the agreed deadline. Check conditions and permissions. This is an example record, not a discovered client defect.
- What to record
- Environment, version, time, role, steps, expected result, actual behavior, evidence, impact, owner and retest date.
- How to close it
- Repeat the same steps after the fix. Record the new outcome and check an affected action. A “fixed” message alone is not a retest.
Checks suggested by real projects
Krest-NN Bitrix24 configuration connects order stages, ownership, required fields and the next action. The screen contains demonstration deals. It establishes pipeline structure; execution of a particular rule needs a separate test.
DOROGA suggests a different check: an order connects to fuel reservations, supplies and cash. Changing a stage is insufficient; reconcile related records and amendments to completed orders. These examples do not establish full client acceptance or measured project outcomes.
Record the phase outcome
- Map results to the full agreed scope, beyond the successful demonstration.
- Mark requirements as passed, untested, requiring a fix or out of scope.
- Assign owners, launch impact and retest dates to unresolved findings.
- Confirm instructions, agreed access and support handover. Assign a process owner.
- Record the phase decision and launch conditions through the project’s agreed procedure. Estimate new requests separately.
Define completion criteria before testing. Sales changes and day-to-day adoption need separate post-launch evidence. One successful order does not establish those outcomes.
Acceptance questions
Is a supplier demonstration enough?
It helps explain the system, but an employee should complete the agreed workflow independently under their own role. Record inputs, expected and actual behavior.
Is one successful order sufficient?
It is a useful first pass, usually not the entire acceptance scope. Add other order types, roles, exceptions, migration and load checks when included.
How do we test delayed automation?
Record the condition, timing and working calendar. Prepare a suitable test and wait for the agreed execution point or use supported debugging. Configuration alone does not establish execution.
Is a finding a defect or new work?
A defect breaks an agreed result. A new function changes scope. Clarify an ambiguous requirement first and keep these types separate in the issue log.
Can we test failure in production?
Use a test environment or an isolated agreed scenario. Actual payments, customer messages and interruption of live enquiry intake should not become accidental test actions.
When should we measure business outcomes?
Verify technical completion against agreed scenarios. Staff adoption, data quality and sales changes need a separate observation period. A passing test does not prove revenue growth.
Prepare your CRM checks
The initial BYstudio review is free. Describe the current system, agreed phase and one uncertain workflow. An anonymised description is enough for the first enquiry.
Ready-made CRM or custom software
Documentation for configuration checks
Check permissions, conditions and execution timing against the chosen CRM documentation. Bitrix24 defines role and action permissions; automation depends on conditions, sequence and timing. Documentation helps prepare a test, but does not replace one.
Checked on 21 October 2026. Adapt the checklist to your specification and system capabilities.