How do you test it before it goes anywhere near our customers?
There are two kinds of testing and only one of them gets talked about in proposals.
The technical kind
Automated tests for the logic, so a change in one place does not silently break something else. A staging environment that mirrors live, using realistic data rather than a tidy sample. Deliberate failure testing — what happens when the integration times out, the file is malformed, the field is empty.
This is table stakes and any supplier should describe it without hesitating.
The kind that actually catches things
A person who has never seen it, doing their real job with it, while someone watches and says nothing.
Not a demo. Not a walkthrough. Give them a genuine task and stay quiet, however uncomfortable it gets. Every serious usability problem I have ever found was found this way, in the first ten minutes, by someone who was not told where to click.
Who should do it
Someone who was not involved in the build, and ideally not the enthusiast who championed it. On one project we deliberately chose a field engineer who had not been part of the process as the gate before sign-off, and specifically excluded the person closest to the project.
That felt awkward to arrange. It was exactly right.
The rule
Sign-off should never be given by the person who commissioned it, alone. It should be given after somebody who will actually use it has tried, unaided, and succeeded.
Got a version of this problem? Twenty minutes minimum, seven questions, and a one-page Bottleneck Blueprint within 48 hours. If it's not a fit, we'll say so.
Book a call →