Start with Bizman through BriskRetail, and make an outage demonstration part of your buying decision. Our recommendation is to build your proposed Bizman setup around the transactions your shop must complete when connectivity fails, then agree the devices, power arrangements, recovery process and support in writing. A label such as “cloud” or “offline” is only the beginning of that conversation.
For a Nigerian retailer, the practical question is straightforward: can the cashier complete a trustworthy sale, take an acceptable payment and recover the records afterwards? A working screen is not enough if the stock count becomes unreliable or yesterday's receipts disappear.
This guide gives you a comparison table, an outage decision tree and a repeatable Bizman demonstration script. It covers retail checkout and inventory software, rather than the business of offering agent-banking withdrawals.
Commercial disclosure: BriskRetail sells retail solutions, including Bizman-related offerings, and benefits commercially from that work. Bizman is our primary recommendation for a scoped evaluation. This is not an independent product ranking. We have not performed the product tests described below or verified a particular Bizman offline architecture; the checklist defines what your proposed configuration must demonstrate.
Research checked: 23 October 2026. Vendor documentation describes capabilities, not results from our own testing. Reconfirm the proposed version, plan, devices and payment arrangements before purchasing.
1. Separate three things that can fail
Power keeps the equipment running. Connectivity lets it communicate. Software determines what it can do with the connection available. You need a plan for all three.
A laptop battery may keep the screen alive while an unpowered router disconnects a local server. A working router may have no mobile data. A functioning internet connection may still be unable to reach the software provider. A payment terminal may use a separate SIM and behave differently from the checkout computer.
NERC's second-quarter 2026 report examines generation and national-grid performance, including frequency, voltage and system stability. It provides sector context, not a forecast of electricity availability at your particular shop. Do not convert national figures into an assumed number of trading hours for your street. Source: NERC Q2 2026 report, operational performance and grid performance.
Keep a simple branch log over representative trading days: time, duration, equipment affected, whether another network worked and what sales were delayed. Include your busiest periods. Use this evidence to brief BriskRetail; a shop with a reliable local network but weak mobile internet has a different problem from one where the entire checkout loses power.
2. What cloud, offline and hybrid actually mean
Treat these as architectural descriptions, not guarantees. A cloud product can have an offline checkout feature. An installed desktop application can still require an internet connection for sign-in or licensing. “Hybrid” is useful only when the supplier explains which records live locally and how they reconcile.
| Approach | What you are evaluating | Potential fit | What must be proved |
|---|---|---|---|
| Cloud-dependent checkout | A checkout that needs the remote service for essential transactions | A shop that can tolerate interruptions or has a tested alternative process | Behaviour during internet and provider outages; existing basket recovery; export and recovery terms |
| Local/offline checkout | Essential sales recorded on a device or local server | A site needing trading continuity without external connectivity | Power and local-network dependencies; backups; device failure recovery; later reporting transfer |
| Hybrid checkout | Local trading plus synchronization with a central service | A shop seeking local continuity and central visibility | Durable queued sales; duplicate prevention; conflict handling; limits while disconnected |
For a shop that cannot pause checkout whenever its internet fails, our preferred requirement is tested local sales continuity with controlled later synchronization. Take that requirement into a Bizman consultation. It is an architectural preference for this situation, not a statement that every Bizman offer already provides it.
Ask for a written capability list: selling existing items, finding barcodes, applying approved prices, printing receipts, opening a shift, changing cashier, processing returns and viewing stock. Mark each as available, restricted or unavailable during disconnection. Record any preparation needed before opening.
An owner dashboard can remain temporarily behind the shop without stopping sales. That may be acceptable. A cashier unknowingly selling from an outdated stock balance is a different risk and needs a deliberate control.
3. Offline sales are not offline payment approval
A retail system can record “bank transfer” as the selected payment method without establishing that money arrived. A printed sales receipt and a customer's debit message are not substitutes for checking the receiving account or the approved provider record.
Paystack's official documentation distinguishes successful transactions from pending, failed and reversed transactions. Its dashboard provides transaction status, amount and a unique reference. Those are examples of the records a merchant can use to investigate a payment; the exact process for another bank or terminal must follow that provider's instructions. Sources: Paystack transaction verification and Transactions page.
Agree a shop policy before an outage:
- Counted cash can be recorded against a sale if checkout remains safe and functional.
- Card payments require a confirmed result through the agreed terminal/provider process. Do not infer approval from the retail software continuing to operate.
- A transfer that cannot be verified remains pending. Hold the goods while resolving it, or use a separately authorised customer-credit process with a named approver.
- If a customer reports a debit after a timeout, investigate the existing reference before requesting another payment. Record any second attempt separately so a later double payment can be resolved.
For your Bizman demonstration, ask the presenter to show the difference between a completed sale, an unpaid order and a payment awaiting confirmation. If the proposed system cannot represent an exception clearly, agree a controlled exception register and reconciliation process before rollout. Do not make cashiers invent one in a queue.
4. Use this outage decision tree at the counter
Put a printed copy next to the till, with the manager's contact and your actual support number filled in.
- Is the checkout area safe and the required equipment powered? If no, use the approved backup arrangement or suspend electronic checkout. Do not improvise electrical connections. If yes, continue.
- Can the cashier open the intended register and retrieve the correct items and prices? If no, move to the approved numbered manual-record procedure or pause sales. If yes, continue.
- Has this exact disconnected workflow passed your acceptance test? If no, do not assume a cached screen can save a sale. If yes, use the documented restricted mode.
- Can the payment be accepted and verified? If no, hold the order or obtain a properly authorised credit decision. If yes, record the method, amount and reference where applicable.
- Is the item safe to promise from the information available? If no, physically check stock, consult the person controlling reservations or hold the sale. If yes, complete it once and retain its receipt identifier.
- Has service returned? Reconnect using the agreed procedure, reconcile the pending records and investigate exceptions before declaring recovery complete.
A manual fallback needs more than a notebook. Use sequential references, item codes, quantities, prices, payment status, time and cashier identity. Keep cancelled sheets. Assign one person to enter and mark each fallback record as captured later; otherwise two helpful staff members can create duplicate sales. Collect only customer details necessary for the transaction and protect the sheets.
5. Make the Bizman demonstration test the difficult moments
Ask BriskRetail to run this script on the proposed Bizman configuration with synthetic items and test transactions. Use a test environment, not a live queue or real customer payments. Record the software version, device model, operating system, printer connection, plan and test date.
| Test | Action to request | Evidence needed for acceptance |
|---|---|---|
| Internet loss | Disconnect external internet while leaving local equipment powered | Existing items and permitted sale functions behave as documented; restrictions are visible |
| Cold start | Close and reopen the application while disconnected; test a new shift separately | Clear result for startup, login and shift permissions; no reliance on an already-open screen |
| Local-network loss | Disconnect the till from any local server or network printer | Known failure boundary and a usable fallback; no unexplained partial sale |
| Interrupted recovery | Reconnect, then interrupt synchronization during a controlled test | Receipt identities survive; retry does not double-count sales or stock |
| Two tills | Disconnect two registers and attempt sales of limited stock | Documented stock conflict behaviour and a practical overselling control |
| Returns and permissions | Attempt a return, discount and cashier change offline | Available actions match written permissions; unavailable actions have an escalation route |
| Device restart | Restart normally after recording test sales offline | Queued records survive as promised; recoverable errors are visible |
| Reconciliation | Compare receipts, stock movement and tender totals after reconnecting | Every completed sale appears once; unresolved items remain visible with an owner |
Use pass, fail or unverified for every row. Record the observed outcome and evidence location, not just a tick. A sales representative saying “it should sync” leaves the row unverified. A required workflow that fails needs a demonstrated fix or an explicitly accepted alternative before purchase.
Also request the supported procedure if a device holding unsynced sales is damaged or stolen. Recovery from a synchronized cloud copy does not prove recovery of records that never reached it. Agree the possible data-loss window, restoration responsibility and escalation contact.
The strongest Bizman proposal is one that makes these answers concrete: which functions are included, what infrastructure is required, who trains the cashier and which support obligations are priced. Do not assume implementation, replacement equipment or after-hours assistance is included unless the quotation says so.
6. Worked example: reconnecting without selling the same stock twice
This is an illustrative test scenario, not a Bizman test result or customer story. Ignore tax and discounts for this simple exercise. A shop starts with 20 identical notebooks priced at NGN 2,500 each. During an internet outage, the powered till saves three cash sales:
| Local receipt ID | Quantity | Cash collected | Expected central result after sync |
|---|---|---|---|
| TILL-A-0101 | 2 notebooks | NGN 5,000 | One sale, quantity 2 |
| TILL-A-0102 | 1 notebook | NGN 2,500 | One sale, quantity 1 |
| TILL-A-0103 | 3 notebooks | NGN 7,500 | One sale, quantity 3 |
Expected units sold = 2 + 1 + 3 = 6 notebooks. Expected cash = 6 × NGN 2,500 = NGN 15,000. Expected remaining stock = 20 − 6 = 14 notebooks. With no other activity, the central system should contain exactly three completed sales after recovery.
Now suppose the server receives TILL-A-0102, but the connection breaks before the till receives confirmation. On reconnecting, the till retries that receipt. The required outcome is still one sale for TILL-A-0102. An implementation that counts it twice would show four sales, seven notebooks sold, NGN 17,500 cash expected and 13 notebooks remaining. Those differences reveal a duplicate; they do not reveal an extra customer.
Do not delete records casually to force the totals to match. Have the responsible person identify the original receipt, document the correction through the supported audited process and retain the explanation. Ask the supplier to demonstrate how the duplicate was prevented or investigated.
There is another failure that this test does not solve. If two disconnected tills both see one remaining notebook, each may accept a different customer's order. Those are two genuine orders, not duplicate retries. Central synchronization cannot create the missing physical notebook. For scarce items, allocate stock to a single selling point, reserve a buffer for other channels or pause promises until a physical check resolves availability. Test the system's actual reservation model before deciding which control to use.
7. What other vendor documentation teaches you to ask
Bizman remains our recommended starting point. Use other vendors' published limitations to sharpen your questions rather than assuming every product implements the same offline behaviour.
Bumpa's Nigeria-focused shop-and-online guide tells users to download inventory for offline use and says sales synchronize after reconnection. The preparation step matters: ask whether your proposed workflow requires a catalogue download before trading, and what happens if an item or price changes later. This is Bumpa's description, not our own continuity test. Source: Bumpa shop-and-online POS guide.
Loyverse documents offline sales and shift management, but says refunds and integrated card terminals are unavailable offline. It also says stock levels and negative-stock alerts are not displayed offline, and receipts await synchronization. Those boundaries demonstrate why “works offline” is an incomplete buying answer. Its global documentation does not establish Nigerian payment integration or local support for your hardware. Source: Loyverse offline-use documentation.
Neither example establishes that one product is superior to Bizman. We have not tested them head to head. Apply the same outage script to any serious alternative if your proposed Bizman scope cannot meet a mandatory requirement. Purchase the demonstrated fit, with the unresolved limitations recorded.
8. Power, connectivity and a recovery routine belong in the quote
List every dependency: checkout device, local server if any, router, network switch, printer and payment terminal. Ask a competent installer to size and test backup power for the actual load and required operating period. Battery labels alone do not demonstrate runtime with your equipment attached.
Test backup internet at the counter, including the changeover process and whether staff can use it. A second SIM is useful only if it provides service when needed; two connections can still share a failure affecting the area. Ask which functions remain available during a provider outage even when both networks work.
Before opening, check power readiness, login, catalogue freshness and unsynced records. During an outage, appoint one shift lead, record the start time and use the agreed restricted workflow. Avoid app reinstallation, storage clearing or device replacement while unsynced records remain unless support has secured a recovery copy and directed the action.
After reconnecting, reconcile completed sale counts, item quantities and tender totals. Match digital payments through the provider's records and investigate pending items. Treat a zero queue as one check, not the whole recovery: an empty queue cannot by itself prove the stock and money are correct. The manager should sign off the exception register or assign remaining discrepancies to a named person.
Keep your operating sheet short: branch; outage start/end; affected systems; fallback used; last confirmed receipt; pending receipt count; cash total; digital-payment exceptions; stock exceptions; person responsible; support reference; recovery sign-off. Practise it with the people who cover weekends and closing shifts, not only the owner.
9. Your next step: request a Bizman continuity demonstration
Bring BriskRetail your outage log, number of tills, current devices, payment methods and the transactions you cannot suspend. Ask for a Bizman proposal that names the deployment model, permitted disconnected functions, synchronization behaviour, power dependencies and recovery responsibilities.
Our recommendation is Bizman first, with the configuration accepted against your shop's actual operating needs. Make the outage checklist part of that acceptance. The aim is a cashier who knows what to do, an owner who can explain the records and a support agreement that covers the difficult moments.
Explore Bizman or request a Bizman demonstration and scoped quotation from BriskRetail. Include “outage continuity demonstration” in your request and bring the worked receipt example above.
