Imagine a till serving a customer while someone on a laptop adds a product or changes its price.
The cashier searches for the item. A similar variant appears. The barcode is difficult to read. The laptop says the change is saved, but the till still shows the earlier information.
That is an illustrative situation, not a report of a particular product test. It is also the sort of ordinary overlap I would ask a provider to rehearse before a retailer commits to a new system.
A demonstration with ten tidy products can show how a screen works. It cannot establish how the team's catalogue, devices and day-to-day changes will behave together.
The useful trial has an agreed workload, an expected result and a record of what actually happened. Run it in an authorised test environment, not by experimenting on live customer transactions.
Start with the retailer's actual requirement
In a UK retailer's discussion about replacing an EPOS system, the request included a catalogue of more than 60,000 items and "a good backoffice that can be used offline or online". The retailer wanted staff to keep serving while products were added from a laptop.
Those are the retailer's stated needs, not a verified performance result or a requirement every small shop shares.
Before a trial, translate the need into a short setup record:
- How many products and variants must be available at the till?
- Which locations, devices and staff roles are involved?
- Which tasks happen at the same time?
- Which changes must become visible, and where?
- Is internet connectivity required throughout the intended workflow?
Count products and variants separately. A catalogue with a few hundred products and many size or colour combinations can create a different lookup task from the same number of simple items.
For the broader sale, return and stock consequences, use our inventory-handoff buying guide. This trial focuses on finding the right item and keeping the intended information usable during ordinary changes.
Separate the stages before timing them
"The scanner is slow" can describe several different failures.
| Stage | What to observe | What a quick response does not prove |
|---|---|---|
| Physical capture | Does the intended device read the label? | That the captured code belongs to the right product. |
| Product match | Does that code resolve to the expected product and variant? | That its current price or availability is correct. |
| Search response | Can staff find the intended item from the agreed search terms? | That the first result is the correct variant. |
| Add to cart | Does the intended item and quantity enter the basket once? | That the rest of the basket stayed unchanged. |
| Change visibility | Does a saved, supported update reach the intended till? | That an already-open basket follows the same rule as a fresh basket. |
A merchant's product-search and scanning report illustrates the distinction. The merchant described an unwanted item being added after a search followed by another scan. That account is not a diagnosis of every device or setup. It is a reason to inspect the whole basket after a mixed search-and-scan sequence, rather than timing the scan alone.
If the problem is the underlying identifier, start with the product-record and barcode guide. Do not replace a scanner to compensate for a duplicate or incorrect product record.
A small case sample is not a scale test
Choose representative cases before adding volume. Include:
- an ordinary product with a reliable label
- similar products with different sizes or colours
- an item requiring manual search because its label cannot be read
- an item not available through the tested selling location or channel
- a product with a supported price change
- a newly available product
Write the expected identity, variant and starting price beside each case. Otherwise the trial can look smooth while staff add the wrong item.
A small case list helps find functional mistakes. It does not establish how the system behaves with the full required catalogue.
If catalogue scale matters, ask the provider to authorize a suitably sized test dataset and explain any plan, device, location or import limits. Use permitted non-production records without customer details. Do not run an improvised load test against a production service or upload data you are not allowed to share.
Record the operating state
Two trials are not comparable merely because they use the same product name.
Record the app version, device model, operating system, scanner method, store location, connection, catalogue size and import state. Note whether the app has just signed in or changed location, or whether the normal catalogue import has finished.
Shopify's product-search documentation describes possible search delay while products import after initial use or a location change. It also distinguishes product availability for the POS channel. Those are provider-specific conditions, not an EzyCarto benchmark.
The practical lesson is to separate startup or import behaviour from normal operation. Test both when both matter to the shop, and label the observations accordingly.
Repeat the same cases using the same method. Keep failed attempts and interruptions in the record. One successful scan after several retries should not become an unqualified pass.
Rehearse a Back Office change during the till workflow
Ask two people to perform a supported sequence in the agreed test environment.
One builds a basket at the till. The other makes an approved change from the Back Office. Choose a product price change or a newly available item, depending on what the provider supports.
Before starting, agree:
- Which record is authoritative for the change.
- Where the change should become visible.
- How an already-open basket should behave.
- How a fresh search or basket should behave.
- What staff should do if the expected result does not appear.
Record the save time and first observed visibility at the intended till. Keep that separate from any cart-total or payment step. Do not treat a spinning indicator disappearing as confirmation that every connected screen has the new information.
Record ownership matters too. Lightspeed's Shopify integration guidance warns about conflicting edits and product-information overwrites. That is a specific integration, not a rule for every platform or a claim that EzyCarto provides the same connection. Ask your provider where each supported change belongs.
Use a compact acceptance record
Keep one entry for each case. A shared document can be enough; the important part is that the expected result and observation stay together.
| Field | What to write |
|---|---|
| Case and starting state | Product/variant reference, till/location, catalogue and connection state. |
| Expected result | The correct item, quantity, price and agreed change behaviour. |
| Setup | Intended device, app version, scanner method and supported configuration. |
| Attempts and stage times | Repetitions, retries, relevant start/end times and observed waiting. |
| Correctness | What entered the basket and what changed elsewhere in it. |
| Interruption | Any manual search, refresh, staff workaround or abandoned attempt. |
| Evidence | A permitted, minimal reference to the observation without customer/payment data. |
| Acceptance | Pass, fail or unresolved against the agreed requirement and limit. |
| Owner and retest | Who investigates, the next action and the result after another test. |
Set response-time expectations before the demonstration. There is no honest universal seconds target for every catalogue, device and shop. The target should reflect the retailer's task and the provider's supported configuration.
Avoid reporting only an average that hides repeated long waits. If the sample is small, preserve the individual observations rather than giving a precise-looking percentile a weight it has not earned.
Worked example: the save succeeded, but the trial did not pass
This example is invented to explain the record. It is not a customer incident, a measured benchmark or a statement of any provider's pricing behaviour.
Suppose the agreed test policy says an existing basket keeps its accepted test price, while a fresh basket should use the newly saved price once the update is available.
| Check | Agreed result | Illustrative observation |
|---|---|---|
| Existing basket | Keep the agreed starting price of GBP12. | It still shows GBP12, as expected. |
| Back Office save | Save the supported change to GBP13. | The workspace reports that the save completed. |
| Fresh lookup and basket | Show GBP13 within the agreed trial limit. | It still shows GBP12 beyond that limit. |
The existing basket behaved as agreed. The save confirmation appeared. The fresh-basket requirement still failed.
Do not average those observations into a mostly successful result. Keep the visibility issue open, assign an owner and repeat the case after the cause is addressed. If the provider's supported rule is different, use that rule from the beginning rather than changing the expected result after seeing the outcome.
Keep offline operation as a separate decision
A successful connected trial does not establish offline selling, editing or payment.
If those are requirements, check the current provider documentation for the actual country, account and hardware. Rehearse only supported procedures and never create real card charges just to see what happens.
Our offline recovery guide covers the separate questions about pending transactions, stock and reconnection. Do not turn this catalogue trial into an unsupported outage experiment.
Where EzyCarto fits
EzyCarto POS connects mobile selling with the retailer's configured product and stock context. Back Office is the connected management workspace. Together they are part of EzyCarto's wider retail operations platform, not a substitute for checking the shop's actual requirements.
The supported devices, payment eligibility, configuration and plan matter. Our public POS scope does not currently advertise offline selling or offline payment. This guide does not claim tested 60,000-item capacity or a verified concurrent-edit response time.
I would apply the same acceptance record to an EzyCarto discussion: representative products, intended supported devices, an agreed workflow and an explicit result.
Bring the acceptance sheet, not just the feature list
Before the next demonstration, choose the product cases your team finds awkward. Write down the expected result and the conditions that would make the setup unsuitable.
Then ask for the same supported sequence to be rehearsed, recorded and retested when necessary.
If you are considering EzyCarto, request a workflow discussion with your catalogue requirements, intended devices and the cases you need to verify. Confirm what can be demonstrated in the supported setup before making a commitment.