CRM user acceptance testing checklist

Direct answer

Test the workflow with each role, not the settings screen. CRM acceptance testing means having the people who will use the system perform their real tasks on it: a rep logs a lead and moves it through the pipeline, a manager reads the forecast, an administrator changes a field. If they can do that, with the right visibility and the right automations firing, the configuration is accepted. Checking that settings exist is not testing.

This page is a checklist for that exercise. It applies whether you are configuring a new CRM, cleaning up an existing one or finishing a move from another system. For a full set of go-live steps see the CRM migration cutover checklist; for the overall sequence, the CRM implementation checklist.

Sandbox and test users

Decide where the testing happens before it starts. Some CRM plans include a sandbox or a separate test environment, and some do not; check your own plan rather than assuming one is available. If there is no sandbox, use a clearly labelled set of test records in the live system and agree how they will be removed afterwards.

Set up a test user for each real role, with the permissions that role will have in production. Testing as an administrator hides permission problems, because administrators see everything. Keep a note of which login was used for each check, so a failure can be reproduced.

• Test environment or labelled test records confirmed, and a plan to clean up afterwards
• One test login per role, set up with production permissions
• A short list of people who will run the tests and the time set aside for it
• Realistic sample data: a few clean records, a few messy ones, and at least one duplicate

Pipeline scenarios per role

Write scenarios in the language of the job. For each role, list the ten or so things they do in a normal week and run them end to end. The aim is to find where the workflow breaks, not to click every button.

• A new lead arrives, is assigned and appears in the right owner's list
• A rep logs a call or note, sets a follow-up and sees it in their tasks
• A deal moves through each stage, with required fields enforced only where agreed
• A deal is marked lost and the reason is captured in the agreed field
• A won deal triggers whatever handover step your process defines
• A manager reassigns a record and the history stays intact

Automation triggers

Every automation in the CRM should be tested by causing the trigger, not by reading the rule. For each one, note the trigger, what should happen, and what should not. Include the edge conditions: the field left blank, the record created by import or by a form rather than by hand, the record edited twice.

Look specifically for automations that fire too often, fire on the wrong records or send messages to real customers during testing. Turn off outbound email to real contacts in the test setup, or use internal addresses only, until you are ready to switch it on deliberately.

Permissions

Log in as each role and check both what they can do and what they cannot. Most CRM problems show up as someone seeing records they should not, or being unable to see ones they need.

• A rep sees their own records and the shared ones agreed, and nothing else
• A manager sees their team's records and reports
• Sensitive fields are hidden from roles that do not need them
• Only the named administrators can change fields, stages and automations
• A user who leaves can be deactivated and their records reassigned

Reports and dashboards

Reports are accepted when the numbers match something you can check by hand. Take a small set of test records with known values and confirm the report totals them the way you expect. Check the filters, date ranges and ownership settings, since the most common reporting fault is a report that quietly excludes records the team assumes are included.

Confirm each report is visible to the roles that should use it and hidden from those that should not, and that scheduled or shared reports go to the right recipients.

Email, forms and links

If the CRM is connected to a mailbox, a website form or a calendar, test each connection with a real submission. Send a test form entry and follow it: does the lead appear, with the right source, in the right owner's list, and does the automated reply go out as designed? Check that emails sent from the CRM appear in the record history and that links in templates point where they should.

Test the failure cases as well: what happens if a form is submitted with a missing email, or a known contact submits again. A duplicate rule that works in the settings screen but not on a form submission is a common finding.

Import spot check

If data was imported, do not try to verify every row. Take a sample: some records you know well, some oldest and newest, some with unusual formatting. Compare each against the source. Check that owners, dates, stages and related contacts carried over, and that no obvious duplicates were created. For the mapping decisions behind an import, see CRM data mapping for migration.

Sign-off

Record each scenario as passed, failed with a note, or deferred with an owner. Fix failures, retest them and only then sign off. Sign-off should name the person who accepts on the business side and the date, and it should list anything knowingly left for later so it does not get forgotten.

Keep the list. It becomes the regression check the next time someone changes the pipeline or an automation.

Where LATYNEX fits

LATYNEX is a remote, English-language vendor. Acceptance checks like these are part of how we finish a CRM setup: we agree scope and price in writing before work starts, and the client's people run the role-based scenarios. For one CRM and one main sales pipeline, the CRM Cleanup & Sales Workflow Setup package (€1,990, fixed scope) fits; multi-pipeline or migration work is scoped separately. If you want to see what is covered, start at CRM & Sales Workflow Implementation.