BYstudio. CRM implementation acceptance checklist
21 October 2026. Adapt to the agreed phase. This is a test procedure, not a record of completed acceptance.
Source: https://bystudio.ru/en/solutions/crm-implementation-acceptance/

Project:
Date, environment and version:
Specification and phase scope:
Acceptance owner:
Future user and tested roles:
Supplier:
Test order and starting state:
Approved test-notification recipients:
Excluded functions:
Phase completion criterion:

1. New enquiry
One record in the intended pipeline with correct fields, contact and source. Check notification separately.
Role and starting data:
Actions:
Expected result (verify against the specification):
Actual result:
Status: passed / finding / untested / out of scope
Evidence without customer data:
Issue reference and owner:
Retest, version and result:

2. Owner and permissions
Check allowed and prohibited actions under employee roles, beyond the administrator account.
Role and starting data:
Actions:
Expected result (verify against the specification):
Actual result:
Status: passed / finding / untested / out of scope
Evidence without customer data:
Issue reference and owner:
Retest, version and result:

3. Required fields
A missing field blocks the transition where specified. Populating it permits the agreed action.
Role and starting data:
Actions:
Expected result (verify against the specification):
Actual result:
Status: passed / finding / untested / out of scope
Evidence without customer data:
Issue reference and owner:
Retest, version and result:

4. Next action
Agreed activity, deadline and notification occur under their conditions. Verify configuration and execution separately.
Role and starting data:
Actions:
Expected result (verify against the specification):
Actual result:
Status: passed / finding / untested / out of scope
Evidence without customer data:
Issue reference and owner:
Retest, version and result:

5. Fulfilment and settlement
Completion, actual data and related records reconcile. For resources, test reservation, deduction and cancellation. Payment uses the agreed confirmation source.
Role and starting data:
Actions:
Expected result (verify against the specification):
Actual result:
Status: passed / finding / untested / out of scope
Evidence without customer data:
Issue reference and owner:
Retest, version and result:

6. Change and retry
Apply different rules to a repeated event and a new task from an existing customer. Completed-order changes do not duplicate related effects.
Role and starting data:
Actions:
Expected result (verify against the specification):
Actual result:
Status: passed / finding / untested / out of scope
Evidence without customer data:
Issue reference and owner:
Retest, version and result:

7. Failure and recovery
In a test environment, trace pending transfer, owner notification and recovery. A retry creates no extra record.
Role and starting data:
Actions:
Expected result (verify against the specification):
Actual result:
Status: passed / finding / untested / out of scope
Evidence without customer data:
Issue reference and owner:
Retest, version and result:

8. Report and handover
Find the order in the agreed report. Receive access, instructions, backup procedure, owners and support terms.
Role and starting data:
Actions:
Expected result (verify against the specification):
Actual result:
Status: passed / finding / untested / out of scope
Evidence without customer data:
Issue reference and owner:
Retest, version and result:

PHASE OUTCOME
Verified requirements:
Untested and excluded requirements:
Open issues and launch impact:
Owners and retest dates:
Handed-over materials and support:
Decision and launch conditions under the agreed project procedure:

One order is a first pass. Other order types, roles, migration, exceptions
and load need their own checks when in scope. Use anonymised data and an
agreed test environment. Do not send real payments or customer messages for testing.