Choosing a POS system in Kenya: test your shop before you buy

List the products and sale units you use: individual items, packs, sizes, colours or weighed quantities. Explain discounts, customer credit and returns if they are part of your operation. A system that works for a simple single-item catalogue may require additional rules for wholesale packs or variants. Ask the supplier to model those rules using sample products.

For multiple branches, define who receives stock, who authorises transfers and how the owner sees each location. For a single shop, avoid paying for unnecessary complexity without understanding the benefits. Decide which records staff need at the counter and which reports management needs after closing. Do not assume that an impressive dashboard answers both needs.

Have the supplier receive sample stock, sell an item, return it and perform an approved adjustment. Check the quantity at every step. Test a product variant separately so a sale of one size does not silently reduce another. Ask how damaged goods, supplier returns and opening balances are recorded.

A useful stock history should make it possible to understand why a quantity changed and who authorised it. Ask whether records can be edited or deleted after a sale and what history remains. For a transfer, demonstrate dispatch and receipt at different locations rather than merely changing a label on a product. Use these checks to evaluate the product; they are not claims that every POS includes them.

Prepare these scenarios before a sales call and record the outcome, including any feature that requires an extra module or subscription.

Do not accept the word offline without a test. Disconnect the network during the demo and try the required tasks. Some products keep only a cached screen, some queue transactions and others require a local server. Establish which devices can continue, whether payments still need connectivity and when stock from other branches becomes visible.

Reconnect and check for lost or repeated transactions. If two counters sell the same last item during an interruption, ask how the product handles the conflict and how staff discover it. The appropriate behaviour depends on the system design and your business rules. Record the tested limitations in the proposal, along with any router, power or local hardware requirements.

A button labelled M-PESA does not establish automatic payment confirmation. Safaricom Daraja provides APIs for integration, but the exact provider connection, business account and production setup still need verification. Ask which steps are manual and which are automatic in the proposed POS.

Demonstrate a pending payment, a failed attempt and an amount that does not match the sale. Ask who reconciles discrepancies and what prevents a cashier from treating an unconfirmed payment as settled. If you require tax-system integration, get the exact supported connection and obligations checked against current official guidance and your adviser before contracting; a printed receipt alone is not evidence of that integration.

Ask for the supported device, printer and barcode-scanner models rather than assuming your current equipment will work. Test the actual receipt layout and scanner with realistic packaging. Clarify replacement hardware, connectivity, installation and training costs. Include renewals, branch or terminal charges and payment-provider costs in the comparison.

Discuss named staff accounts, permission boundaries and how access is removed. Security questions can be structured using OWASP ASVS for a web-based application, with verification proportionate to the system. Ask how support is reached when the shop cannot trade, which hours are covered and what recovery steps staff can safely take themselves. A response target should not be confused with a guaranteed resolution time.

Use a trial import to check product codes, units, prices and opening quantities. Decide how stock will be counted and approved before the new system becomes authoritative. Avoid importing customer information you do not need; use sample or anonymised records during evaluation. Keep the previous system or source records recoverable while validating the transition.

Request a sample export and check that it contains the information another system would need. Download the demo script below, then review our POS service and the Goodmorning Baby Shop POS project for relevant work. Share your shop type, branches, products, current devices and required integrations when requesting a demonstration.