User Acceptance Testing (UAT) for CRM/ERP: Scenarios and Acceptance

What UAT solves when implementing CRM/ERP

UAT (user acceptance testing) answers one question: is the system ready for real work or not. This is not a code quality check or a set of technical tests. Here the business confirms that processes run as they do in the company and the result can be safely handed to users.

The difference in focus is simple. IT usually looks at stability, bugs, integrations and performance. The business looks at meaning: can you issue an invoice, process an order, close a request, generate a report and at the same time keep department rules intact.

UAT closes risks that often appear after go-live:

• critical process steps don't match actual practice
• data is entered but not used later (or ends up in the wrong place)
• access rights are set so work is blocked
• reports don't match how managers see the picture
• users find workarounds and return to Excel

The result of UAT is not a “bug list” but a management decision: accept, accept with caveats (with known limitations), or send back for rework. This decision should rely on pre-agreed acceptance criteria.

Without acceptance criteria testing quickly becomes an argument. One person says: “it works, you press the button — the status changes.” Another: “it doesn't work, the status is wrong and in the wrong moment.” For example, in CRM a manager should see the “Approval” stage only after attaching a commercial offer and checking the credit limit. If the rule isn’t written as a criterion, everyone will interpret “ready” differently.

UAT participants and distribution of responsibilities

UAT works only when it’s clear who decides and who helps. The business accepts the system. The implementation team provides conditions, explains settings and fixes issues, but does not “take the exam for the business.”

The result owner is usually one of two options: the process owner (sales, procurement, warehouse) or the head of the unit most affected by the system. They define what counts as success and defend the decision to management.

Key users are the people who will work in the system every day. Their task is to run scenarios in their role and honestly record where the result doesn’t match real work. It’s important to agree on time in advance: UAT almost always fails if done “between meetings.”

The implementation team (including the analyst) helps to:

• turn business situations into clear scenarios and test data
• explain how the system should work by configuration and regulations
• quickly triage defects and questions
• maintain discipline in recording results

But implementers should not replace the business. If a scenario is “passed” only because an analyst suggested a workaround, that’s a signal the process or interface needs improvement.

The final sign-off is made by the assigned business sponsor (often the process owner or head of direction). The basis is completed scenarios, met acceptance criteria and a list of known limitations the business agrees to accept now. If you work with a system integrator, record this rule in writing: who accepts, who fixes, who confirms the fix.

Defining scope: what we test and what we leave out

Scope is needed so the team checks the same things and doesn’t waste time on arguments like “let’s also test all reports for five years.” It’s convenient to record scope on one page: what we check, on which data, in which roles and what counts as “ready.”

Start with the list of processes that must pass UAT because they will be used on day one after go-live. Typically these are:

• sales: lead - deal - invoice/contract - closure
• procurement and warehouse (for ERP): request - order - receipt - write-off
• finance: documents, payments, status reconciliation
• service: request - assignment - execution - closure
• access management: key roles and typical rights

Then decide which integrations and reports are included in the check. The rule is simple: include what affects the user's decision here and now. For example, email and telephony integration for sales, exchange with accounting for invoices, BI export — only for 2–3 key data marts.

It’s important to record up front what is not part of UAT unless agreed separately. Most often out of scope are load testing, information security checks, backups, tech support and monitoring processes.

To keep scenarios from spreading, follow the rule: one scenario — one expected result to verify. Example: “Manager creates a deal and issues an invoice” — the expected result is exactly one fact: “the invoice got status ‘Sent’ and appeared in the invoice register.”

How to collect UAT scenarios without extra bureaucracy

Scenarios are easier to collect not “from scratch” but from what the business lives by every day. Hold 2–3 short meetings of about 45 minutes with key users: sales, service, finance, warehouse (if present). Discuss daily actions, frequent pains and reports needed by day or month end.

Sources of scenarios are usually obvious: regulations and manuals, current reports and exports, list of frequent support requests, project requirements. A useful technique: ask users to name 5 situations that currently cause them to lose time or money. That is the core of UAT.

To avoid bloat, use a simple scenario template:

• objective
• steps (5–10 actions without unnecessary detail)
• test data (which fields and values are needed)
• expected result
• notes (limitations, roles, pitfalls)

Prepare test data together: the business provides realistic examples (customers, items, typical amounts), the implementation team helps load them into the test environment. Store data in one place with clear rules: one owner of the data set, clear names, and a ban on personal data unless agreed.

Don’t forget exceptions. Besides the “happy path,” add 1–2 checks per scenario: order cancellation, return, duplicate customer, incomplete data, change of assignee.

A minimal set that almost always helps:

• end-to-end chains from start to finish (lead → deal → document → payment)
• 2–3 critical reports (day, week, month)
• access rights by roles
• integrations without which the process fails
• one scenario for “user error” (missing field, wrong amount)

This way you test the essentials without thick binders and hundreds of test cases no one can finish.

Appointing business owners: how to choose and assign the role

The business owner in UAT is the person who speaks for the process: “yes, this is how we work” or “no, this is unacceptable.” Without this role the test quickly becomes a collection of scattered comments with nobody making decisions.

Choose not the most active person but someone who actually manages daily work and has the right to a final word. Often this is a group leader, senior specialist or process owner (for example, head of sales for the sales funnel and deals).

Signs a candidate is suitable:

• knows the process and exceptions, not only the ideal path
• can make decisions and record compromises
• is available during UAT (time allocated in advance)
• expresses expectations in simple terms, not in implementation details
• is ready to be accountable for the result, not only to “ask for changes”

How many business owners you need depends on scale. Practically, appoint at least one per key process (sales, procurement, warehouse, service). Larger projects add a business coordinator to resolve overlaps.

Powers should be documented: an order/project directive, an email with the list of processes and dates or the UAT kickoff meeting minutes.

Step-by-step UAT plan: from start to acceptance decision

To keep UAT from turning into chaos, the most important thing is to fix the working order and not change rules during the run. Testing is best done in a separate environment with clear access and a “frozen” system version for the entire check period.

Working plan:

• prepare the environment and accounts (roles, rights, test data); do not update the version during UAT without agreement
• run a short briefing (20–30 minutes): where scenarios are, how to record steps, what counts as a defect vs an enhancement request
• execute scenarios and use unified statuses: “passed”, “failed”, “blocked”
• hold a daily sync (10–15 minutes): what passed, what blocks, who removes blockers and by when
• after fixes, retest: first the failed scenario, then related processes (regression control)

In practice it looks like this: a sales manager’s scenario “create deal — issue invoice — process payment” is blocked by a role issue in the accounting module. The blocker is logged, an owner is assigned. After the fix the scenario is rerun and adjacent flows (e.g., contract approval) are checked to ensure rights were not broken.

The final step is the acceptance protocol. It usually includes: percentage of passed scenarios, list of open defects (severity and deadlines), what is accepted with caveats, and a clear decision: accept, accept after fixes or postpone go-live.

Acceptance criteria: how to write, agree and measure them

Acceptance criteria are the agreement you use to decide: is the system ready for launch or not. They protect against vague “seems to work” and help close disputed points quickly.

A good criterion is always verifiable. It answers three questions: what we do, on which data, what result is correct and how we measure it. Terms like “convenient”, “fast”, “correct” without examples usually cause conflicts.

How to phrase criteria so they can be signed off

A convenient format: action + conditions + expected result + tolerance.

• function: “Manager creates a deal with mandatory fields; without the customer ID the deal is not saved; the system shows a clear error.”
• data: “After migration 100% of active customers have a unique ID; no duplicates by ID; 10 sample records match the source on key fields.”
• calculations: “Invoice total = sum of lines - discount + VAT; on a test set of 5 examples discrepancy = 0.”
• integrations: “Invoice from CRM appears in the accounting system within 5 minutes; payment status returns; errors are logged.”
• limits: “30 simultaneous users for 1 hour without crashes; opening a customer card under 3 seconds.”

Example for sales: the criterion is not “invoice is generated” but “invoice is generated from template N, details are pulled from the directory, the total is calculated according to rules, the file opens without errors.”

Acceptance threshold: what blocks the launch

Agree in advance which defects are critical. Usually critical means it breaks a key process, corrupts data or prevents period closing.

• critical: cannot process an order or invoice, data loss, wrong totals, mandatory integration broken
• non-critical: typos, non-ideal layout, report improvements

Record criteria in one document and have process owners sign it. Then UAT ends with facts: done or not, plus a clear list of exceptions and deadlines.

Recording results: test log, defects and change requests

If UAT results live in email chains, control is quickly lost: what was checked, what is broken, and what was just a wish. You need one shared log that shows each scenario’s status and next action.

Minimum fields for the log:

• scenario and step
• expected and actual result
• evidence (screenshot, export, document number)
• checker (business) and fixer (implementation)
• status and date (Found, In progress, Ready for retest, Accepted)

Agree on a simple defect classification so you don’t argue priorities on each case:

• critical: process stops
• important: process works but with losses (calculation errors, wrong rights, integration failures)
• cosmetic: does not affect results

To prevent UAT from dragging out, set rules on deadlines and confirmations: when to fix, when to schedule a retest and who gives final “accepted”. For example: critical — fix in 1–2 days and retest the same day; important — in the next sprint; cosmetic — into the backlog.

A common trap is confusing a defect with a change request. A defect is when the system does not implement agreed requirements and acceptance criteria. A change request is “let’s do it differently now.” Mark these as change requests and evaluate them separately.

A useful artifact is a list of known limitations. For example, the business knowingly accepts that in the first version a report is generated manually once a day and this does not block launch. The main thing is that this decision is recorded and signed.

Frequent UAT mistakes and how to avoid them

The most common reason UAT fails is organization, not bugs. The goal of testing is to confirm processes work on real data and in real roles, not just that screens open.

1. Too general scenarios. If it says “create a customer” without input data and expected result, participants will test differently. You need a role, specific data (e.g., ID number, contract type, discount) and a clear result (card created, status changed, document generated).

2. Starting before ready. If there are no accesses, no test database with directories and no short instructions, people spend time on workarounds. It’s better to postpone the start a couple of days than lose a week.

3. Vague decisions. If business owners are not appointed, every comment becomes a discussion. Each process needs an owner with final authority.

4. Uncontrolled fixes. If changes are made without recording the version and rechecking, UAT results cannot be compared and bugs reappear.

5. Turning acceptance into a design argument. UAT prioritizes process operability: process an order from request to shipment, close an invoice, get a report.

Example: if a manager cannot proceed with a deal because of a required field — that is a defect. “The button should be on the right” is an enhancement request and should not block acceptance.

Short checklist before starting UAT

Before start, make sure you are ready not only to “run the system” but to make a release decision.

Check test boundaries. If the scope includes the chain “lead — deal — invoice”, then telephony and accounting integrations must either be included or explicitly excluded and documented.

Minimum pre-start checks:

• scope agreed: list of processes, roles and integrations approved
• scenarios ready: steps, test data and expected results in clear terms
• business owners assigned: each process has a person who confirms results and knows the criteria
• environment ready: accesses and roles issued, test users created, test data loaded, external services working or consciously disabled
• rules for recording and resolving issues defined: who maintains the log, how to describe a defect, fix deadlines, date and format of the final protocol

If at least one point is fuzzy, UAT usually becomes a battle of opinions. It’s simpler to spend a day on preparation than a week on retests and manual workarounds after go-live.

Example scenario: UAT for CRM implementation in sales and service

Context: the company sells equipment and provides post-sale support. UAT participants include sales, service, accounting and the head of direction (who confirms the process “works as needed”). The focus is not on “interface polish” but on whether key operations run without workarounds.

Critical scenarios are conveniently written as short stories with a clear result:

• a lead enters the funnel, an owner is assigned, source and next step are recorded
• from a deal a contract and invoice are created, then shipment, and statuses change in sync
• a request is registered, classified, assigned to an executor and closed with a comment
• a return/claim is linked to a shipment and reflected in service and accounting
• the manager views funnel reports, service load and overdue items

Acceptance by domain: sales is accepted by the head of sales (or key manager), service by the service head (or senior engineer), accounting confirms document correctness and integrations.

Write acceptance criteria measurably: “request closes within 5 minutes without missing required fields,” “deal and shipment statuses do not diverge,” “monthly sales report matches the control export,” “service shows overdue items and reasons.”

The UAT outcome is a list of scenarios with statuses “accepted/not accepted”, a list of accepted limitations (what is done manually for now) and a post-launch improvement plan with owners and deadlines.

What to do after UAT: launch, control and support

After UAT it’s important to prepare a clear acceptance package: the decision protocol, defect list with statuses and known limitations (what currently works “as is” and why it’s acceptable). This reduces disputes in the first days after launch.

Then agree a launch plan: when to enable the system for everyone, whether to roll out by departments, and what change window is acceptable in the first weeks. Also plan training: short role-based sessions (sales, accounting, warehouse) often work better than one big training.

To ensure honest control, choose 3–4 metrics for the first 2–3 weeks. They should show process operability: number of critical errors, number of support requests, time to complete a key operation (order processing or request closure), number of operations done via workarounds.

Support and improvements should also be described in advance: single channel for questions, prioritization rules, short daily reviews in the first days after launch, owners for decisions and a schedule for fixes.

If the project also includes infrastructure work (servers, workstations, 24/7 support), it’s convenient to entrust this to one partner. For example, GSE.kz as a vendor and system integrator can take on infrastructure and support tasks so the project team is not split between UAT, launch and user support.