How a Gulshan shopping mall replaced its parking slip book with QR ticketing

Every mall in Dhaka has the same basement conversation. The parking is busy, the cash box fills up, and nobody can say with confidence whether what's in the box is what should be in the box. Not because anyone is necessarily stealing — but because there is no mechanism that could tell you either way.

Police Plaza Concord Shopping Mall sits on Road 144 in Gulshan-1, one of the most heavily trafficked retail addresses in the city. Its basement parking takes bikes and cars all day, every day. When we started, the operation ran the way most of them do: a handwritten slip, a mental calculation at the exit, and a cash box.

What the site survey actually found

Before writing anything, we stood at the gate and watched. Not for an hour — across different times of day, because a parking gate at 11 AM and the same gate at 7 PM on a Thursday are different problems.

Four things stood out, and only one of them was about software.

1. The slip was slow, and slow gets skipped. Writing a plate number, time and vehicle type by hand takes real seconds. When four bikes are queued behind the barrier, the pressure to wave one through and "write it after" is enormous. Whatever replaced the slip had to be faster than the slip, or it would be routed around within a fortnight.
2. The fee was a negotiation. With the rate card on a laminated sheet somewhere and the duration worked out in someone's head, the exit was a conversation. Conversations at an exit lane cost time, and time at an exit lane costs queue.
3. Nobody could answer the owner's question. "How much should today have made?" had no answer that didn't involve counting slips by hand. Without an expected figure there is nothing to compare the cash box against, so reconciliation was impossible in principle, not just in practice.
4. The basement is a hostile place for a computer. Dust, humidity, power that isn't always clean, and not much room for a desk. This drove more design decisions than any feature request did.

The design: two desks, one keystroke each

The whole system is built around a decision that sounds trivial and isn't: each desk does exactly one job, and that job is one keystroke.

The IN desk shows a single focused field. The operator types or scans the plate, presses enter, and the ticket prints. Vehicle type switches with the arrow keys. The parking area is fixed per desk, so it is never asked. There is no mouse, no menu, no dropdown, and no per-vehicle login.

The OUT desk is the mirror image. Scan the QR on the ticket, or type the plate. The system reads the entry record, computes the duration, applies the slab and shows the payable amount. The operator takes the cash and the invoice prints. The fee is never a human calculation, which means it is never a negotiation.

IN and OUT run as separate signed-in users. That is not a security ritual; it is what makes a shift report meaningful. Every ticket is attributable to a person and a period, so a shortfall has a name and a time attached to it rather than being a general fog over the whole day.

The ticket is the contract

The most under-rated artefact in the entire system is a piece of thermal paper about eight centimetres wide.

It carries the QR that closes the visit out, a sequential receipt number, the entry time, the vehicle number and class — and, critically, the rate slabs and the terms, in Bangla. First two hours at Tk. 30, Tk. 15 per hour after. Single entry. Non-transferable. Park at owner's risk.

That last part is not decoration. An argument at the exit lane is expensive: it blocks a queue, it escalates to a supervisor, and it occasionally ends with a discount that nobody recorded. Printing the rules in the customer's language at the moment of entry moves that argument to a place where it costs nothing — or removes it entirely, because the customer already agreed to a number they could read.

The ticket isn't a receipt. It's the moment the price stops being negotiable.

What we got wrong first

Three things we'd approach differently, stated plainly because they're the useful part of any case study.

1. We designed for the booth before we designed for the gate

The first build assumed a PC at a desk. That is a fine assumption for a permanent basement booth and a poor one everywhere else — an open-air overflow lot, a rooftop, a second entrance that's only staffed on Friday evenings. A desktop needs a surface, power, a dry environment and cabling, and half the places that need a parking system have none of those.

The answer was to make an Android device with an integrated thermal printer a complete deployment on its own — entry, ticketing, exit, fee, payment and reports, with no computer anywhere in the picture. The operator walks to the vehicle rather than the vehicle queueing at a booth, and the ticket prints in their hand. We should have built that path first, not second.

2. We under-estimated how much the printer would define the product

Thermal printers are unglamorous and they will humble you. Paper width, character encoding for Bangla, how a partial print is handled when the roll runs out mid-ticket, what happens when the operator hits print twice. Ticket reprint from the transaction list turned out to be a genuine daily-use feature rather than an edge case. Budget real time for the printer; it is not a checkbox.

3. Training should have started with the exception, not the happy path

We trained operators on the normal flow — vehicle in, vehicle out — and it took twenty minutes because the screens are deliberately boring. What actually needed the training time was the awkward five percent: a lost ticket, a torn ticket, a plate typed wrong, a vehicle that left through the wrong exit. Those are the moments where an untrained operator invents a workaround, and an invented workaround is exactly the hole the system was built to close.

The lessons that transfer to any mall

1. Speed at the gate is the whole ballgame. If issuing a digital ticket is slower than writing a slip, operators will route around it and you will have bought a very expensive slip book. Optimise the entry action before you optimise anything else, and measure it in keystrokes.
2. Take the arithmetic away from humans. Not because operators can't be trusted with it, but because a computed fee is consistent, and consistency is what turns an exit lane from a conversation into a transaction.
3. Reconciliation needs an expected number. A cash box is only auditable against a per-shift, per-operator expected total. Without that figure, no amount of reporting will tell you whether the money is right.
4. Print the rules where the customer reads them. Rate slabs and terms on the ticket, in the local language, prevent more disputes than any policy taped to a wall.
5. Assume the environment is hostile. Basements have dust, humidity and unreliable power. A system that needs a pristine desktop is a system that will be down on the day it matters. Design so that the smallest viable deployment is one device in someone's hand.
6. The audit trail matters more than the dashboard. Owners ask for charts and then use them twice. What they rely on is the ability to answer "what happened with this specific vehicle at 4 PM last Tuesday" — which needs append-only records, not visualisations.

Where it stands

The system runs the mall's basement parking today: every vehicle ticketed at entry, every exit priced by the system, every shift attributable to an operator. The slip book is gone. The owner has an expected figure to compare the cash box against — which was, in the end, the entire point of the project.