Queue System

CPRAM Co., Ltd. is CP Group's food manufacturer — a factory that takes in around 300 raw-material and packaging deliveries a day. I joined its CPRAM Event programme as the UX Researcher on a cross-functional team drawn from Warehouse, Planning, QA, IT and R&D, working on a PDCA plan over seven months.

There was no brief and no feature request. What we had was a situation: trucks queueing along the public road outside the plant, and a growing pile of complaints from the delivery firms who had to sit in them. My job was to find out what was actually going wrong, prove which problem was worth solving, and design something the in-house IT team could build.

What we shipped was an online queue-booking system. Suppliers pick the POs they're delivering, book a time slot against real loading-dock capacity, receive a QR code, check in at the security gate, and get notified when the queue shifts. Warehouse sees the day's incoming schedule in advance; Planning finally gets stock visibility.

Deliveries ran at roughly 300 trips a day — 7,894 in a single month in 2021 — and every one of them arrived unannounced. There was no booking, no schedule and no visibility: whoever reached the gate first got unloaded first, so suppliers came early and waited. On average a delivery took 360 minutes — six hours; some gate logs showed four to eight.

The cost of that wait didn't sit with the factory. Supplier satisfaction scores for the warehouse (82.14 in 2019, 83.16 in 2020) had been below the internal target for two years running, and the complaints had turned into behaviour: delivery firms were refusing factory jobs, and drivers were quitting.

I interviewed across eight roles — Management, Purchasing, Sales, IT, Planning, Warehouse, QA and the drivers themselves. The queue was the loudest complaint, but it wasn't the only one, and I didn't want the team to pick the loudest thing. So I wrote up all three problems people raised and put a number on each, using the factory's own operational records.

In a cross-functional team, whoever argues hardest usually wins. To avoid that, we scored all three problems on five criteria — importance, urgency, cost value, number of departments involved, and time to fix — and multiplied the scores so a weakness on any one axis really counted.

The waiting-time problem came out on top at 81. It was measurable in money, it touched the most departments, and it was fixable inside the programme window — the redundant price-comparison process was cheap to fix but low-value, and the urgent-PO problem was expensive but depended on overseas lead times we couldn't influence.

Scoring did something a discussion wouldn't have: it gave the people whose problem wasn't chosen a reason they could accept, which is why we still had their cooperation when it came time to research the journey.

The 360-minute figure came from records, so I went and walked it: gate, QA, warehouse, stopwatch in hand, timing each stage of a real delivery. It held up — and standing in it told me something the number didn't. Most of the six hours is dead time in a truck cab, not work.

I ran a fishbone analysis with the team across Man, Method, Environment, Material and Machine. Three root causes survived it: suppliers arrive unscheduled and therefore simultaneously, there are not enough loading docks to absorb the peak, and there is no queue discipline once they're on site. Only the first is a design problem — which is exactly why a booking system, not more docks, was the answer we could afford.

Then twelve field interviews: purchasing and warehouse staff, production, QA, security, supplier sales managers and drivers. Same event, five different kinds of pain — and two of them became the people we designed for.

The same six hours, felt from every side of the gate. Quotes as spoken, in Thai, with translations.

Mapped end to end, a delivery day runs about seven hours, and the emotional low sits squarely in the four-to-six-hour wait — not at the gate, not at unloading. That's where the opportunities were.

The flow was the real design work. A supplier logs in, sees the deliveries they owe, selects the POs going on one truck, opens the loading-dock calendar, takes a slot that still has capacity, and walks away with a QR code they can print and hand to the driver. Everything after that is confirmation and notification.

I sketched the low-fidelity screens by hand, because the people reviewing them were warehouse and IT staff rather than designers — pencil invites correction in a way a polished screen doesn't. Once the layouts held up, I built a small set of components (colour, type, inputs, buttons, grid) so the hi-fi prototype would be consistent and the IT team would have something specifiable to build from.

The prototype covered five screens: a dashboard with delivery status at a glance, a PO list with per-item detail, the loading-dock calendar, the booking confirmation with its QR code, and the notification a supplier gets when their queue moves.

Testing the prototype on five tasks caught the kind of thing you only find by watching someone try. The biggest was an ordering problem in my own head: I had put the booking action where I thought about it, not where users arrive at it.

The slot-conflict rule mattered more than it looks. Two suppliers can want the same dock at the same minute, and in an operational system the honest answer is that one of them loses — so the design's job is to make losing quick and clear, not to hide it.