Every vendor says yes.
Here is how to find the no.
A POS evaluation collects answers. Answers are cheap: no vendor has ever lost a deal by writing "yes" in a requirements column, and the ones who lose later are usually the ones who were telling the truth. These are six tests you can run inside a demo or a pilot that produce evidence instead.
Written by Teamwork Commerce, a POS vendor. Run every one of these on us. The last section of this page lists the tests we would fail, in our own words, because a testing guide written by a vendor is worthless unless it can be turned around.
A demo is a performance of the easy case.
It runs on a clean network, a seeded catalog, an empty store and an operator who has used the product for years. Your stores have none of those things. The gap between the two is where an implementation goes wrong, and it is invisible unless you design for it.
Ask for the failure, not the feature
Anyone can show you a sale completing. Ask to see one interrupted. The recovery path is the product; the happy path is the brochure.
Use your data, not theirs
A seeded catalog hides everything that makes yours hard: size and width matrices, variants that differ by market, the SKUs nobody has cleaned up since 2019.
Put it in an untrained pair of hands
The person demonstrating has a thousand hours on the product. Your seasonal hire in November will have twenty minutes.
Things you watch, not things you are told.
Each one is runnable in a scheduled session. None of them requires a pilot store or a signature.
Pull the network in the middle, not at the start
The offline demo begins offline. The device is already disconnected, already in its offline state, already showing you the screen it was designed to show.
Start the transaction connected. Scan two items, then take the network away between the basket and the payment. Then bring it back while a second sale is open.
Whether the sale completes at all, what the associate sees, and who owns the card authorization. Accepting a card offline is the payment provider's capability, not the POS vendor's. Ask which one you are being shown.
Count a floor that is trading
The count is demonstrated on a fixed set of stock that nobody is buying, in a room where nothing moves.
Ask what the count looks like at 2pm on a Saturday, with stock leaving the floor while the count is running.
Whether they admit to discrepancies. Stock moving during a count produces them, in every system ever built, and reconciling them is an operational job rather than a software feature. A vendor who says the count is simply correct is describing the demo condition.
Hand the device to someone who has never seen it
The product is driven by the person who knows it best, narrating as they go, never pausing in the wrong place.
Take the device yourself, with no script. Do a return against a gift receipt, then a split tender across a card and a gift card, then a price override.
Where you stop. Every place you have to ask a question is a place your seasonal staff will form a queue, and those three transactions are where most of a store's training time actually goes.
Configure a market you do not trade in yet
You are shown a list of supported countries. A list is a statement of intent, not a demonstration.
Name a market on your three-year plan and ask them to set it up while you watch: tax treatment, currency, receipt requirements, the local payment methods.
Whether it is configuration or a project. If the answer involves a scoping call, that is your answer, and it is not necessarily the wrong one. It just needs to be in the plan rather than in the pricing.
Ask to watch a release reach a store
You are shown a roadmap. A roadmap tells you what a vendor intends; it tells you nothing about what happens on the day.
Ask how a change reaches several thousand terminals, who decides when, whether a store can be left behind, and what the rollback looks like at 11am on Black Friday.
Whether upgrades are something that happens to you or something you schedule. This is the single question most likely to be missing from an RFP and most likely to shape the next five years.
Ask how your data leaves
Nobody asks this during a selection, because it feels like planning the divorce during the engagement.
Ask before you sign: which formats, what it costs, how long it takes, and whether transaction-level history comes with you or stays behind.
How readily it is answered. You will never have more leverage than you do now, and the answer is a reasonable proxy for how the vendor behaves when a relationship is not going well.
Where Teamwork Commerce fails these tests.
If a testing guide from a vendor cannot be run against that vendor, it is marketing. Here is what we would have to tell you, in the room, on each of the above.
Take it to every vendor on your list.
Including us. These pair with the two other things on this site that are free and ungated.
100+ RFP questions
The written half of a selection: a question bank across 15 sections, including the questions we would struggle with. No form.
Open the bankA technical review
If you are the architect or the CISO, run tests four, five and six in a working session rather than a product walkthrough.
See how it runsRun all six on us.
Bring the awkward ones. We would rather lose the deal now than the account in year two.