User acceptance testing (UAT) is the last moment where you can tell the vendor, "this doesn't work, fix it." Once you sign the acceptance protocol, every fix becomes a discussion about another invoice. Most SMEs waste that moment on a one-hour meeting where they watch a nice demo.
We know this scenario by heart. The vendor turns up with a laptop, walks through 4-5 use cases on hand-picked records, everything clicks in 2 seconds. The owner nods, says "looks good", signs. A month after go-live the same screen takes 40 seconds in production, because the real database has 8,000 records instead of five, and the reps out on the road can't enter a discount because the mobile view doesn't have that field.
At one of our clients — a 22-person automotive parts distributor in Silesia — UAT for a new CRM was two one-hour meetings. The director watched the demo and signed. A month after launch it turned out the road-based sales reps weren't using the system at all — the mobile view didn't show the individual discount field, so they kept writing quotes in Excel and sending them from private email accounts. Three months of work and about PLN 45,000 in consulting fees went down the drain. Fixes after the fact cost another PLN 18,000, and the rollout effectively had to be repeated.
That is the price of a shortened UAT. And it's the mild price — because there was no outage, just an investment quietly dying. The nastier scenario is when you accept an ERP integrated with a WMS, and a week later order picking runs 3× slower than before the rollout.
A demo is not a test
A vendor demo shows that the system can do what you ask it to. UAT checks whether the system can cope with what your company will actually throw at it on a Monday morning.
The difference is huge. A demo uses 3 prepared records. Your production has 15,000. A demo shows one user. Your production has 12 people clicking at the same time. A demo shows the "happy path". Your production generates exceptions: a missing customer record, a duplicated contact, a CSV file with a BOM at the start, a network that drops for two minutes.
If your UAT uses the same data, the same scenarios and the same user as the demo — it's not a test. It's another demo, and you're only telling yourselves you checked something.
Write scenarios from real life, not from the proposal
Good test scenarios don't come from the vendor's documentation. They come from what your company actually does every day. The classic mistake: the vendor supplies a "test case list" of 30 items, your people click through them obediently, everything passes. Nobody notices that the list has no scenario for "the sales rep issues a correction to an invoice from three months ago, on which the customer had paid a wire-transfer deposit in EUR".
Collect 15-20 real scenarios from the last 30 days:
- 5 typical everyday cases (the most frequent order, the most frequent invoice, standard goods receipt).
- 5 atypical but realistic ones (correction, return, prepayment invoice in a foreign currency, order to a customer with a credit hold).
- 5 edge cases (customer with no tax ID, order with 200 line items, product with zero price, picking from two warehouses).
- 5 "something went wrong" scenarios (internet dies mid-save, two users edit the same record, the price list contains a negative price).
Your people write these scenarios, not the vendor. That's 1-2 days of work for two people who know the process — an accountant, a warehouse worker, a sales rep — not the IT person. IT doesn't know what happens on the shop floor every day. They do.
Test on real volume, not on a sample
A whole class of bugs only shows up at real database size. Searching a contact by a name fragment is instant on 50 records and hangs for 15 seconds on 8,000. A monthly sales report takes 2 seconds for 100 documents and 4 minutes for 12,000. A price list import of 500 items passes; 30,000 times out.
Before you sit down to UAT, demand a test environment with real volumes. Not a sample, not 100 demo records. Import the production customer, product, stock and transaction history — at least 12 months of it. The vendor may protest that it's complicated. Good — that's exactly why they should do it before acceptance, not after, on your live data.
During testing, run the system under normal load: 6-8 people log in at the same time and click through their typical tasks for an hour. That will catch 80% of the performance and concurrent-access problems — and those are exactly the ones you can't fix with a single click after go-live.
Check what happens when things break
Well-implemented systems differ from badly implemented ones not by never having errors — but by how they behave when an error happens. Deliberately break things in the test environment:
- Yank the network cable mid-save — does the data come back, or vanish?
- Feed in a CSV file in the wrong encoding — does the system give a sensible message, or "unknown error"?
- Create two documents with the same number — does it block, or duplicate?
- Turn off one of the integrated systems (say the WMS) — does the ERP wait, retry, or hang?
- Log a user out mid-edit — what happens to their unsaved data?
If any answer is uncomfortable, this is the moment to demand fixes. After you sign the protocol, every such bug becomes a "new ticket", billed by the hour.
An acceptance protocol with criteria, not a handshake
The last thing SMEs consistently get wrong: they sign the acceptance protocol without written criteria. "The system works in line with the contract" is not a criterion — it's a statement of faith.
Before UAT starts, write a list of concrete, measurable acceptance criteria:
- Issuing an invoice takes less than 5 seconds with 10,000 customer records.
- 8 users at the same time can issue documents without noticeable slowdown.
- A price list import of 30,000 lines completes in under 10 minutes.
- All 20 real-life scenarios pass without a critical error.
- A database backup runs in the overnight window and can be restored within 2 hours.
Attach the criteria list and each test's result to the protocol. That's two extra pages. It protects you from the worst-case scenario in which, six months later, "well, it worked at acceptance" becomes the vendor's defence.
Also split defects into three categories: critical (block work, must be fixed before acceptance), medium (annoying, with a fix schedule attached to the protocol) and cosmetic (backlog). Without that split, every fix conversation ends with "that wasn't critical".
What next
UAT is boring. It requires pulling several people off day-to-day work for 3-5 days, writing scenarios, and having conversations with the vendor about topics the vendor would rather skip. But that week is the cheapest insurance you'll buy on the whole project — several times cheaper than a single fix after go-live.
If you have an ERP, WMS, CRM or custom-software acceptance coming up and you're not sure how to structure it so you don't end up owning a lemon — let's talk. The first call is free and takes half an hour.
The signed acceptance protocol is the end of your negotiating leverage. Everything you want out of the vendor, you have to get before it's signed.