Representative case study · ShopPilot

How a 3-branch pharmacy chain replaced their POS in 14 days

The chain has three branches in Mohammadpur and Adabar — call it "Sehat Pharmacy". The main branch on Tajmahal Road is the busiest: a 14×20 foot shop, three serving counters at peak, a cool storage room behind. The two satellite branches are smaller, each one counter, each run by a family member of the owner.

Their POS for the last seven years was a desktop Windows machine running a locally-installed pharmacy POS — the kind sold off-the-shelf at Stadium Market for Tk. 18,000 plus a yearly support fee. It worked. Then it didn't.

The four reasons they finally moved

1. The desktop died. A power surge in April 2026 fried the main branch's PC. The last full backup was 11 days old. They lost about 1,800 transactions and the previous week's reconciliation. The recovery took six days and Tk. 9,000.
2. The satellite branches had no real connection. They were running pen-and-paper at the smaller shops, then transcribing daily totals into the main system. Stock between branches was guesswork.
3. The support contract ran out. Renewal quoted Tk. 22,000 for a year that would expire whether they used the software or not.
4. Customers had started asking for digital receipts. The thermal printer worked, but more customers wanted bills on WhatsApp. The old POS couldn't.

What they ruled out first

The owner shortlisted four options before settling on ShopPilot:

• Cloud POS (subscription, web-based). Ruled out: required reliable internet at every branch. The Adabar branch loses power roughly twice a week; that's twice a week the POS would be down.
• Branded ERP (~Tk. 80,000 setup + Tk. 8,000/month). Too expensive, too feature-heavy for what's really three counter-staff and an owner who knows the stock by feel.
• Stay with the desktop POS, just upgrade the PCs. Considered seriously. Killed by the realisation that this would solve only the dead-PC problem, not the satellite branch problem or the WhatsApp receipt problem.
• Build something custom. Quoted around Tk. 1.5 lakh by a freelance dev. Would have worked, but no support afterwards.

ShopPilot was picked because it ran on Android tablets (so power-tolerant), worked fully offline (so internet-tolerant), supported multi-branch with manual sync (so the satellites could just sync nightly), and cost nothing per month.

The 14-day rollout, branch by branch

Days 1–2 — main branch only, alongside the old POS

One Samsung tablet (Tk. 14,000) at the main branch's third counter. The other two counters kept using the old POS. The tablet processed real transactions but only for cash customers who explicitly agreed to be the "test customer".

The first 40 transactions on the tablet were also entered into the old POS. Slow, but it built confidence: the totals matched to the taka by the end of day 2.

Days 3–6 — load the SKU master

12,400 SKUs is a lot. The owner had a partial Excel from 2024 (about 9,000 rows) and the rest lived in his head and on shelf labels.

The Excel imported in 40 minutes — barcodes, brand, generic name, MRP, current sell price. The remaining ~3,400 SKUs were added during downtime over four days, one at a time as they came up in real sales.

The key decision here was not trying to load everything before going live. Anything not in the master got typed in when the customer asked for it. By day 7, the master had 11,200 SKUs (90%) and was effectively complete; the remaining 1,200 trickled in over the next month.

Day 7 — main branch switches fully

The old POS stayed on for read-only reference. All three counters at the main branch now used tablets. Day 7 had three issues — one barcode that didn't scan, one MRP discrepancy, one moment where the cashier panicked and called the owner. All three were resolved in under five minutes each.

End of day 7: total recorded in app matched cash in drawer within Tk. 80 (under 0.2% of the day's takings — within normal hand-cash margin).

Days 8–10 — satellite branch #1

The Adabar branch got a tablet on day 8. Its inventory is a subset of the main branch (about 4,200 SKUs) — those were marked as available at Adabar in one bulk action.

The satellite branch was harder than the main one not because of technology but because of staff confidence. The Adabar cashier (the owner's nephew) had only ever used pen-and-paper. Two full half-days of side-by-side training were needed before he was comfortable.

Days 11–13 — satellite branch #2

The Mohammadpur side branch went live on day 11. The cashier there was already familiar with the tablet from helping at the main branch on day 6. Much smoother. By end of day 13 all three branches were on ShopPilot exclusively.

Day 14 — first chain-wide closing

Sunday closing: chain totals, branch totals, top-selling SKUs, stock movement. The owner saw branch-by-branch comparison for the first time in seven years. The Adabar branch was outperforming the side branch on margin (he'd suspected this; now he had numbers).

What changed over the next two months

• Daily reconciliation: 45 minutes per branch (manual count + Excel) → 8 minutes per branch (app's close-of-day report).
• Stock-out events: ~12 per week → ~4 per week. Cross-branch visibility means an SKU that's out at Adabar can be confirmed in stock at the main branch in seconds.
• WhatsApp receipts: zero → about 35 per day across the chain. Customers like it. The chain spends nothing on the feature.
• Transactions lost to system failure: ~1,800 in one event last year → zero in 60 days post-migration. The tablets back up to Drive every night.
• Time spent on FIFO batch tracking: was effectively impossible on the old POS → now automatic. Two months in, the chain has identified Tk. 31,000 of stock that was sitting unsold past its preferred sell-through date.

"The old POS gave me totals. ShopPilot gives me reasons."
— composite reflection from the owner

What we'd do differently

1. Start with the satellites, not the main branch

The instinct is to roll out at the busy branch first because that's where the value is. In hindsight, doing one of the quiet satellite branches first — where transaction volume is low and mistakes have low blast radius — would have given the cashiers a safer place to learn.

2. Print a one-page cheat sheet on day one

The cashiers asked for the same five things repeatedly in week one: how to void, how to add a customer to a sale, how to add a manual discount, how to look up an SKU by part of its name, how to switch users. A physical printed card on each counter would have saved at least a day's worth of small panics.

3. Migrate the customer list earlier

The chain had about 600 regulars — names, phones, sometimes credit notes. They left this until week four, then realised they'd lost the ability to track credit sales for that month. Doing this in week one would have been better.

The transferable lessons

1. Run two systems for 7–10 days, not 30. Long parallel runs lose discipline; people stop reconciling. A focused week is plenty.
2. Don't load the SKU master 100% before going live. 70-80% is enough. The rest fills in from real demand. Trying to perfect the master is what kills retail POS migrations.
3. Train at the quiet branch first. Confidence built in low-stakes conditions transfers; confidence forced in high-stakes conditions doesn't.
4. Print the cheat sheet on paper. Counter staff don't want to scroll a help screen during a customer interaction.

The Bangladesh DGDA's published guidance on retail pharmacy record-keeping requirements is worth reading before any pharmacy POS migration — the regulator's requirements for sale logs, expiry tracking and supplier records dictate which workflows you can't get wrong, regardless of which software you pick.