A POS demo checklist helps Kenyan shop owners evaluate software using real business tasks instead of judging it only by a polished presentation. A system can look impressive while leaving important questions unanswered about stock, payments, staff permissions, or daily reporting. The best demonstration follows the work your shop repeats every day.
This guide explains what to prepare, which scenarios to test, and how to record the results. It suits owners choosing a first POS or reviewing a replacement. The purpose is not to demand every possible feature. It is to establish whether the proposed setup can handle your essential requirements reliably and at a cost you understand.
Start your POS demo checklist with clear business problems
Record the main business problem on your POS demo checklist.
Begin with three or four specific problems from the shop. Perhaps closing cash takes too long, staff cannot find products, stock quantities are unreliable, or the owner struggles to review sales. Describe what happens today and what a useful improvement would look like, using examples employees recognise.
Separate current needs from future ideas. A small boutique may need accurate variants immediately while only considering another branch later. Treating both requirements as equally urgent can distort the evaluation. Make the essential tasks visible so a supplier’s presentation does not steer the conversation away from the work that matters most.
Prepare representative sample products
Add real product examples to your POS demo checklist before the meeting.
Bring a small product list with realistic names, prices, costs, and quantities. Include ordinary items and the awkward examples that usually cause confusion. Depending on the shop, these might be different garment sizes, similar phone accessories, products without barcodes, or goods purchased in packs and sold individually.
Ask to use this sample during the demonstration rather than relying entirely on the supplier’s prepared catalogue. A system that works neatly with five simplified products may reveal different questions when handling your naming conventions and product variations. Keep customer and other confidential data out of the sample unless there is a clear need and suitable arrangement.
Test product search before testing reports
Use your POS demo checklist to note search speed and barcode accuracy.
The cashier’s ability to find the correct item affects almost every transaction. Search using the terms employees actually use, including partial descriptions and familiar product codes. Observe whether similar items are easy to distinguish. The correct result should be identifiable without opening several records or asking the owner for help.
Try scanning a physical barcode where the proposed equipment allows it. GS1’s barcode standards overview provides background on identifiers, but practical compatibility still needs testing. Confirm what happens when a code is unknown or unreadable and whether staff have a clear route for resolving the issue without creating duplicate products.
Complete an ordinary cash sale
Record receipt quality and change calculation on your POS demo checklist.
Follow a transaction from product selection to receipt. Change a quantity, remove an item before completion, accept the amount tendered, and check the change calculation. Observe how clearly the screen shows what the customer is buying and whether the cashier can correct an ordinary mistake without restarting unnecessarily.
Review the resulting receipt and transaction record. Check the description, quantities, totals, and payment method. Ask how a cashier finds the transaction later when a customer returns with a question. A fast checkout matters, but it should also leave enough information for the next employee to understand what happened.
Demonstrate M-Pesa payment handling
Include payment references and confirmation steps in your POS demo checklist.
Ask the provider to explain exactly what happens when a customer pays through M-Pesa. Recording a payment method, manually matching a transaction, and receiving an automated confirmation are different workflows. The demonstration should make the proposed behaviour clear rather than using the word “integration” without showing the actual steps.
Use Safaricom’s official business payment guidance as background when discussing payment channels. Confirm any prerequisites, account configuration, transaction verification, and separate charges with the relevant providers. Ask what the cashier sees while a payment remains unconfirmed and who investigates a payment that cannot be matched to a sale.
Include a split payment and an unsuccessful payment
Your POS demo checklist should distinguish failed payments from completed sales.
Try a customer paying part in cash and part through M-Pesa. Check that the combined payments equal the sale total and that reports show the correct amount under each method. This simple scenario can expose whether staff understand payment entry and whether the interface makes accidental duplication easy.
Next, test a payment that fails or remains pending. Determine whether the basket is preserved, how another payment attempt is handled, and what prevents a duplicate sale. The provider should explain a workable exception process. A demonstration of only successful transactions leaves a major part of real trading unexamined.
Follow one item through its stock movements
Record the stock balance before and after each test in your POS demo checklist.
Record a sample delivery, sell an item, process an appropriate return, and inspect the resulting balance. The goal is to understand which actions increase or reduce stock and how the history explains those changes. Ask what happens if an employee tries to sell more units than the system shows as available.
Where your shop uses variants or packaging conversions, repeat the test with those examples. A balance can appear correct at product level while individual sizes or units are wrong. Confirm how authorised users investigate and correct differences, and whether the record preserves the reason and person responsible for an adjustment.
Test returns using an original transaction
Include damaged goods and partial refunds in your POS demo checklist.
Locate a sample sale and demonstrate a return or exchange under your business policy. Check the relationship between the returned item, stock treatment, payment adjustment, and authorisation. A process that handles a full cash refund may behave differently when only one item is returned or the original payment was split.
Use a damaged item as a separate example. Returning goods to the business should not automatically make them available for resale. Ask how the system represents the status you need and what happens when the required workflow is outside the standard setup. Record any agreed workaround and assess whether staff can follow it consistently.
Compare cashier and manager permissions
Use your POS demo checklist to compare cashier access with manager access.
Ask to see the same actions using different roles. A cashier may need to complete sales but should not necessarily change purchasing costs, alter permissions, or approve every refund. The appropriate boundaries depend on your business, but the demonstration should show that the proposed access rules can be applied in practice.
Check how a manager approves an exception without sharing personal credentials. Also ask how access is removed when an employee leaves. Clear ownership and individual accountability make records easier to interpret. A system with many role names is not automatically useful unless those roles correspond to the responsibilities in your shop.
Run a complete shift close
Add expected cash and counted cash to your POS demo checklist.
Use the sample transactions to close a shift and compare expected cash with an independent count. Add an opening float and, if relevant, a documented cash removal. The expected result should be explainable from the underlying movements, not merely accepted because a total appears on the screen.
Include a deliberate difference and ask how it is recorded and reviewed. Confirm whether staff can reopen or amend a completed shift, who can authorise that action, and what history remains. A practical closing routine should make exceptions visible while allowing authorised corrections through a clear process.
Review reports with a decision in mind
Record the report needed for each business decision in your POS demo checklist.
Choose reports that answer your original business problems. If purchasing is the concern, inspect product movement and stock information. If accountability is the concern, review staff activity and exceptions. Ask the provider to trace a summary figure back to the transactions that produced it, using the sample data you have just entered.
Check the reporting period and the meaning of each measure. Sales, payments, margin, and cash available are different concepts. An attractive dashboard can create confusion if employees interpret them interchangeably. Confirm export options and any plan restrictions that affect how the owner or accountant will review records outside the application.
Check invoicing requirements explicitly
Keep invoicing evidence alongside your POS demo checklist.
A receipt printer working during the demonstration does not establish that every electronic invoicing requirement has been met. Ask the provider to describe the proposed invoicing arrangement and show the relevant workflow. Identify any separate onboarding, integration, configuration, or third party service required before live use.
The Kenya Revenue Authority’s eTIMS information is the official starting point for current guidance. Confirm your applicable requirements and the exact supported setup with the appropriate adviser and provider. Document how failures and corrections will be handled instead of relying on a general statement that the system is compliant.
Test equipment and connectivity assumptions
List compatible equipment and recovery steps in your POS demo checklist.
List the devices you plan to use, including computers, tablets, printers, scanners, and cash drawers. Ask which combinations are supported and what additional equipment is required. A demonstration on the supplier’s computer does not establish that your existing printer or operating setup will work without changes.
Discuss connectivity and power interruptions realistically. Do not assume offline selling, automatic synchronisation, or recovery behaviour without a demonstration and clear explanation. Agree what employees should do during an interruption and how records will be reconciled afterwards. The answer may affect equipment, connectivity arrangements, training, and the suitability of the proposed system.
Compare total cost and support arrangements
Use your POS demo checklist to compare setup fees and ongoing support.
Request a written breakdown covering the subscription, setup, equipment, training, migration, integrations, and any recurring service charges. Ask how transaction volume, additional users, or other changes affect the price. A low headline amount is difficult to compare fairly when the underlying scope differs between providers.
Clarify support hours, response expectations, contact channels, and responsibility for hardware or third party problems. Ask what happens when the main cashier needs help during a busy trading period. Record these expectations alongside the software features so the final decision reflects the practical experience of operating the system.
Score evidence rather than presentation quality
Complete your POS demo checklist with an owner and deadline for every unanswered question.
For each essential requirement, record whether it was demonstrated, needs configuration, requires separate development, or remains unanswered. Add a short note describing what you observed. This makes supplier comparisons more useful than relying on memory or giving equal weight to every feature mentioned during a sales presentation.
Invite a cashier and the person responsible for stock to participate where practical. Their questions often reveal details the owner may overlook. Resolve important unanswered items before committing. A trial or follow-up demonstration can be useful when a critical workflow has not yet been shown with representative data.
Use your POS demo checklist in a Vega walkthrough
Vega POS describes tools for checkout, stock control, payments, staff roles, shifts, and reporting. Bring your sample scenarios to a walkthrough and ask which current plan and configuration fit them. The Vega POS selection guide offers additional questions for comparing operational needs.
If requirements extend beyond a retail counter into custom approvals, portals, or business integrations, explore Zama’s software development services as a separately scoped discussion. Keep standard product capabilities and additional development deliverables clearly identified in the proposal so responsibilities and costs remain understandable.
Frequently asked questions
How many products should I bring to a demo?
Bring enough to represent the important differences in your stock, rather than the entire catalogue. A small selection covering ordinary items, variants, unusual units, and missing barcodes can reveal more than hundreds of identical examples.
Should a cashier attend the demonstration?
Yes, where possible. The person who will use checkout daily can assess practical steps, confusing labels, and likely training needs. Include stock or finance staff when their workflows are central to the decision.
What if an essential feature is promised for later?
Treat it as unavailable until delivery, scope, timing, and acceptance criteria are clearly agreed. Decide whether your launch depends on it. Do not build a critical operating process around an undocumented future promise.
Keep the completed evaluation with the final quotation. When the agreed setup arrives, repeat the essential scenarios and compare the results with the demonstration notes. This helps confirm that the delivered configuration matches the understanding reached during selection, including equipment, permissions, payment handling, reports, and any separately agreed training arrangements.
Complete your POS demo checklist with a practical demonstration
Choose a system by testing the work your shop needs to complete. For a Vega POS discussion using your products, payments, and stock scenarios, call 0725345345 or message the team on WhatsApp. A focused demonstration gives you clearer evidence for a confident decision.
Explore Vega POS
Visit Vega Home, review the features and solutions, compare pricing, or contact Vega.
Explore more business websites
Explore PRIM, Zama Web Experts, Vega POS, TAS, Dereva and PMS. For enquiries, call 0725345345.
POS demo checklist example: compare two suppliers fairly
Give both suppliers the same sample products and the same scenarios. Your POS demo checklist should describe the starting stock, selling price, payment method and expected result for each exercise. This prevents a comparison in which one supplier demonstrates an easy sale while another is asked to solve a complicated exception. Let staff ask follow-up questions, but keep the core test consistent.
For example, select a product costing KES 500 and test a customer paying KES 200 in cash and KES 300 through the agreed mobile payment channel. Record the receipt total, the payment split and the remaining stock on your POS demo checklist. Next, ask how the transaction would be corrected if the cashier selected the wrong product. Treat the figures as test data, not actual customer payments.
Build a simple evidence sheet with columns for requirement, observed result, unresolved issue and responsible person. Attach screenshots only when the supplier permits them and no private information is visible. Your POS demo checklist becomes more useful when another employee can follow the evidence without attending the original meeting. Record the date and product version because software behaviour can change between a demonstration and installation.
Score each requirement using a clear scale: demonstrated successfully, demonstrated with a limitation, or not demonstrated. Avoid awarding points merely because a feature appears on a brochure. Use the POS demo checklist to separate essential requirements from optional conveniences. A missing essential function deserves a written resolution before purchase, even if the supplier performs well on many lower-priority tasks.
After the meeting, ask the cashier and stock controller to review the results independently. Discuss disagreements with reference to the recorded evidence. Keep the POS demo checklist beside the quotation when reviewing which services are included. Training, equipment setup, historical data import and support response arrangements should each have an explicit owner and scope.
Finally, repeat the most important scenarios during the trial or acceptance stage. A POS demo checklist is a reusable testing record, not a document to discard after the sales meeting. If the delivered system behaves differently, explain the difference using the original example and request a documented response. Keep your completed POS demo checklist available for future staff training and for evaluating changes as your shop grows.
