Short answer
User acceptance testing (UAT) is where the people who will use the CRM confirm it does their job before go-live. Write test scripts from real scenarios, test in a sandbox with realistic data and real user profiles, log every issue with a severity, and get written sign-off from the business owner before anything goes to production.
Prepare
- Pick testers who do the work every day, plus a manager or two. Two or three testers per role is enough.
- Write test scripts from real scenarios: "Onboard a new household with two accounts at Schwab", not "Test the account page".
- Load realistic, masked data into the UAT sandbox or test portal.
- Give each tester a login with their real profile and permission sets. Testing as an admin hides access problems.
- Agree the dates, the daily check-in time and the sign-off rule before testing starts.
Run
- Testers record pass or fail per step, with a screenshot for every fail.
- Log issues in one place with a severity:
- Blocker: can't do the job, no workaround.
- Major: can do the job with a workaround.
- Minor: cosmetic or wording.
- Change request: works as designed, but the design is wrong. Goes to the project owner, not the bug list.
- Fix, redeploy to the UAT environment and retest the failed scripts.
Exit
- No open blockers. Majors have an agreed workaround or a fix date.
- The business owner signs off in writing, naming the version tested.
- Training material reflects what was tested, not the original design.
For regulated firms
Include compliance in UAT for anything that touches supervision, recordkeeping, consent or client communications. Keep the scripts, results and sign-off; they are evidence that the system was tested before use.
Frequently asked questions
Who should do user acceptance testing on a CRM project?
The people who will use the system every day, two or three per role, testing with their own profiles. Managers and admins alone miss the problems front-line users hit.
What is the difference between a UAT bug and a change request?
A bug means the system doesn't do what was agreed. A change request means it does what was agreed, but the agreement was wrong or the need changed. Change requests go to the project owner for a scope decision.
Salesforce, HubSpot, Anthropic and OpenAI change their products often. Check the official documentation before you rely on a specific setting, limit or price.