7 July 2025
Why was 10X easier than 2X? This is the story of a hospital that didn’t set out to transform hospital logistics—but once they saw everything clearly in real time, speed followed, fairness followed, and outcomes exceeded expectations. A lesson in what happens when technology stops controlling people and starts working with them. Powered by Dispatcher, built for change.

Piyorot Piyachan
CEO of Mutrack
When people talk about “digital transformation,” they usually picture dashboards and future-tense promises. This story is different. It begins in the back halls of two of the busiest teaching hospitals in Thailand, where a private hospital logistics contractor was already performing at a level most facilities would envy: more than a million patient-movement jobs completed, a five-minute average first-response time, and a measured completion rate above ninety-nine per cent. In other words—success by every conventional metric.
In most hospitals, dispatchers were still juggling paper notes and radio calls, nurses still phoned to chase porters, and agents still spent precious minutes walking back to a central desk to find out what came next. The system performed, but it performed through hustle. That left no head-room for growth, no buffer against surges, and no clear data trail strong enough to satisfy modern quality teams. The organization didn’t want the next incremental tweak. It wanted an operational shift so deep that ten-times performance would feel easier than two-times pressure.
Long before new software entered the picture, the contractor already coordinated upward of a thousand transport and delivery requests every twenty-four hours. Calls arrived through a central hotline, handwritten slips stacked on desks, and a self-built website where agents “claimed” tasks from a public pool. The claim model seemed flexible—any available agent could take any job—but it introduced hidden waste. A task could sit unclaimed while agents walked past the very ward that needed help. No one in the office could see in real time who was truly available or which agent was about to finish. Nevertheless, the team kept the wheels turning through sheer vigilance.

No more guesswork, no more chasing jobs. With Dispatcher, porters and agents see their past, present, and next steps—clearly, right from their hands. It’s not just a job app. It’s a full shift in how hospital logistics flows. 🌊
The day the leadership team asked, “Could the next million jobs run without that daily grind?” the search for a new dispatch brain began. They found it in a platform that would soon be known across the operation simply as the system. In public we call it Dispatcher. In practice it became the silent conductor, orchestrating thousands of movements so smoothly that the entire tempo of work changed.
The first design decision surprised many veterans: break the big campuses into logical “hubs.” Every ward, clinic, diagnostic zone, storeroom, and service counter was mapped to a hub not by architectural blueprint but by lived reality—walking distance, elevator dependence, clinical urgency, and daily volume. The dispatch team didn’t need consultants or custom code; they opened the Admin Center, named four hubs for the largest site and three for the secondary campus, then dragged location tiles into the cluster that felt right. If a ward shifted function a month later, they dragged it again. No workflow broke, no IT ticket was filed.
Almost overnight the forgotten minutes between “job created” and “agent located” evaporated. Because hubs localized the talent pool, a request from the surgery floor no longer queued behind a request from the imaging unit three buildings away. The algorithm routed the job to agents who were already certified for that clinical class, already present in the right vertical stack, and already carrying a workload light enough to respond swiftly.
Dispatchers felt the change first. They stopped triaging sticky notes and started watching live heat-maps of demand, as though someone had switched on the lights in a room they never knew was dark.
Once hubs were humming, the team asked the next hard question: “Can we know where everyone is—without buying a beacon for every corridor?” The answer lay in the airwaves the hospitals already owned. Every agent's Android device listened to Wi-Fi access points, reading the unique BSSID signatures that told a silent story about proximity. The mobile app determined its own position using the strongest RSSI signal from the nearest access point (BSSID). Unlike traditional triangulation, it required only a single access point in view, making zone detection faster, lighter, and highly reliable even in complex hospital environments.
No ceilings were drilled. No cables pulled. Yet dispatchers could watch a digital floor plan populate with moving icons—green when free, blue when en route, gold when waiting to start. Location data meant that if an agent missed a notification, the system auto-rejected and reassigned the job within sixty seconds, always selecting the next-closest qualified agent. Because signals updated every few meters, the algorithm never asked someone in the basement to fetch a patient on the top floor. Minutes turned into seconds; frustration turned into flow.
Location awareness unlocked a deeper advantage: Optimizer mode. Instead of holding a static queue, the platform continuously analyzed urgency, travel distance, agent workload, and skill tags, then matched each fresh job to the best next agent. During day shift the dispatch team often made manual adjustments—because human judgment still matters—but once 6 p.m. rolled around, Optimizer took the helm. Overnight work used to feel like firefighting; now it looked like cruise control. Jobs landed on devices the moment the previous job cleared, eliminating the age-old ritual of “walking back to the desk to find out what’s next.” Idle miles disappeared. Value-added ratio rose from sixty per cent to ninety.
One night-shift supervisor phrased it best: “I used to chase jobs; now I watch jobs chase the right people.”
In theory, giving an agent multiple jobs at once sounds dangerous. In practice, it changed everything.
Before Dispatcher, agents handled one task at a time, in strict sequence. Finish the job. Report back. Get the next assignment. It was clean—but wasteful. A patient would be wheeled across the hospital, while another task—a document drop, a lunch tray, a quick equipment run—waited idle in the queue. Not because no one could do it, but because no one was allowed to do more than one thing.
Boosting productivity with Concurrent Jobs
Reduce idle time, improve job flow, and make better use of your workforce without adding complexity.

With Concurrent Jobs, that changed. Agents could now carry more than one job on their device at a time—but under control. Managers defined how many concurrent tasks were allowed per agent and for which job types. Some agents could carry two or three low-effort jobs at once. Others were restricted to a single patient transport for focus and safety. Some combinations were permitted—others deliberately blocked. One queue, many rules. Because not all “concurrent” is equal.
It wasn’t just about multitasking—it was about smart task stacking.
The logic behind it wasn’t arbitrary either. Dispatcher used cycle time ratios to decide if a second job made sense. If an agent's current job type usually took 20 minutes, and he had already spent 15, then a new 5-minute task might slot in perfectly before the next check-in. If not, it waited. Queue scores were constantly calculated based on real-time estimates and historic cycle time benchmarks—ensuring each added job made the workflow better, not heavier.
The best part? Agents didn’t feel like they were juggling. Because jobs were still displayed one by one, in the right order. They could see what was next, swipe when ready, and move forward with confidence. The queue was smart enough to stay quiet when needed, and proactive when the moment allowed.
By day, concurrent tasking boosted output. By night, it kept teams small but effective. One senior agent reflected on the shift this way: “Before, I did one thing at a time. Now, I do three—but it feels easier, because I don’t walk empty anymore.”
It wasn’t chaos. It was coordination.
At first glance, all hospital jobs look similar—someone needs something moved, someone needs help. But inside the operation, every job type has its own pulse.
A hospital logistics agent moving a patient across buildings can’t be assigned like someone delivering meal trays. A request to clean an operating room before the next surgery doesn’t follow the same urgency or protocol as restocking infusion pumps from Central Supply. Linen, food, specimens, pharmacy runs—each carries its own timing, route logic, and service expectations. In the old world, managing this meant building separate systems—or worse, layering paper and walkie-talkies over an already overwhelmed team.
With Dispatcher, that fragmentation collapsed. One platform, many streams. Every job type could be created, tracked, and optimized independently—but still coexist in a unified interface.
Each job type had its own workflow. Its own SLA. Its own team. Some jobs required Auto Dispatch at all times—urgent lab runs that triggered immediate assignment, even during overnight shifts. Others waited in queue until a coordinator manually matched the best person. You could turn Auto Dispatch on for linen jobs after 6 p.m., and off for maintenance requests during daytime when technician scheduling was more nuanced.
Flexibility didn’t mean chaos—it meant respecting the nature of each job.
Teams were fluid. Some were fixed to one domain—pharmacy agents focused solely on scheduled med runs. Others rotated freely—like float agents who could handle low-priority cleaning and internal mail when available. Each job, each person, each hour could follow its own logic, without breaking the system.
This made cross-departmental harmony possible. Dietary didn’t have to compromise their routines to fit into a patient transport model. Engineering didn’t have to “borrow” staff from the hospital logistics teams to fix a broken air handler. Everyone kept their rhythm, but spoke the same language.
A head of clinical logistics put it like this: “We used to treat every job the same because our system couldn’t tell them apart. Now we treat them differently—because we finally can.”
More than efficiency, this brought clarity. When dozens of jobs are flying across departments at once, the only way to stay in control is to acknowledge their differences—and manage them accordingly.
That’s what multiple job types made possible. Not one size fits all, but one platform that fits many.
Every hospital has invisible borders.
Some teams serve only a few floors. Others cover multiple buildings. Some agents handle just deliveries. Others only work nights. But when everything funnels into a single command center, roles blur. Workload gets tangled. And the same few staff end up absorbing the overflow—again and again.
Organizing diverse operations with Workspaces
Manage your own job types, rules, users, and workflows, all within a single platform.

Dispatcher fixed that, not by adding control, but by adding clarity. That clarity came from Workspaces.
Workspaces are where structure begins. They’re not departments, though they might map to them. They’re not just user groups either. Workspaces are operational zones—defined by responsibility, membership, and logic. Each one controls its own scope: what jobs can be created, who can receive them, how dispatching behaves, and who gets to intervene.
At one hospital, the hospital logistics team created separate workspaces for Patient Transport, Clinical Logistics, and Facilities Support. Each workspace had its own agents, dispatch settings, managers, and rules. Nighttime linen jobs didn’t spill into the pharmacy team. Patient transfers didn’t clog the queue of equipment agents. And maintenance requests didn’t distract the dispatchers overseeing meal trays during peak lunch hour.
More importantly, each workspace evolved on its own terms. Some enabled Auto Dispatch for every job. Others required dispatcher review. One workspace enforced strict job matching logic—accounting for agent skills, distance, and priority. Another prioritized simplicity and speed.
Supervisors could see only what they were responsible for. Agents received only jobs they were trained and approved to handle. Job types, agents, SLAs, visibility—it was all scoped. Clear lines, fewer mistakes, better focus.
Workspaces didn’t just separate teams—they unlocked a deeper layer of configurability.
Each workspace defined its own rules for concurrent jobs. One site limited agents to only one patient transport at a time. Another allowed up to three concurrent hospital logistics jobs—so long as they were short-distance, low-interaction tasks like equipment drop-offs. Some permitted mixed-type queues; others enforced strict homogeneity. All of this logic lived inside the workspace settings—meaning operational policies weren’t just written on paper. They were coded into how the system worked.
It also meant each job type lived its own life. Within a workspace, specimen delivery could run on full Auto Dispatch while patient transport requests required dispatcher review. Pharmacy requests might trigger priority overrides during night shifts, while equipment returns waited in a FIFO queue. The system respected the rhythm of each workflow because each workflow had its own space to breathe.
That’s how a hospital could run dozens of job types, hundreds of agents, and multiple shift schedules—without overwhelming anyone.
Workspaces held the line. Concurrent logic filled the queues. And every job found the right hand, at the right time. But this wasn’t isolation. It was alignment.
Cross-workspace coordination still happened—like when cleaning services needed to respond quickly after patient discharge. But now it happened with intention, not confusion. Jobs were forwarded, not dumped. Handoffs were tracked, not assumed.
One site manager described the shift like this:
“We stopped managing a giant tangle of tasks. Now each team manages its own system—inside one bigger, smarter whole.”
Workspaces created the structure that made complexity manageable. They turned a single platform into a constellation of coordinated systems—each tuned to its team, its territory, its tempo.
When you need to scale, you don’t duplicate. You segment. That’s the power of Workspaces. It’s not about making things smaller. It’s about making responsibilities sharper.
Before Dispatcher, requests were scattered across wards like whispers—one nurse calling a supervisor, another shouting across the hallway, a third jotting a note for someone to pass along. The problem wasn’t effort; it was fragmentation. When every department became its own dispatcher, hospital logistics turned into a guessing game.
That’s why one hospital made a pivotal shift: they centralized it all.
They established a dedicated Service Center, where a small team handled every logistical request via phone. Nurses no longer needed to open a screen, track down a porter / agent, or guess who to call. They just dialed a single number. Within seconds, someone at the Service Center logged the job into Dispatcher—accurately, cleanly, and visibly.
The Service Center saw everything. All jobs. All types. All statuses.
They weren’t just call-takers—they became command. Every job request, once entered, was immediately live on the platform. Whether it was a patient transfer, a lunch tray, a linen change, or a stat specimen, it entered the same dispatch ecosystem—tagged, time-stamped, and trackable.
Suddenly, the conversation changed.
A nurse no longer said, “Where is my porter?” She said, “Can you check job #A356?”
And the answer wasn’t vague. The Service Center could say: “It was dispatched 3 minutes ago. He’s already on the way—3 floors up.” Or: “It was rejected, but the system reassigned it. Someone new is picking it up now.”
This wasn’t a help desk. It was a truth desk.
More importantly, the Service Center operated across all workspaces, spanning all job types—from agents and pharmacy runs to equipment moves and cleaning requests. They didn’t need to know who to call in return. They didn’t have to remember which team covered which shift. The platform handled the complexity. The Service Center simply saw what mattered: what was requested, where it was going, and whether it was in motion.
Over time, the team became more than responders. They became workflow guardians. They flagged bottlenecks before nurses even noticed them. They monitored delay clusters, cross-shift carryovers, and repeated failure patterns. And when things went wrong, they didn’t guess—they knew.
This wasn’t about replacing nurse requests with a screen. It was about replacing frustration with confidence. One number. One team. One platform. A true one-stop service—finally real, finally running.
The numbers after go-live told a story no anecdote could rival. Across the dual-campus network the system cleared its millionth job while maintaining a five-minute average response time. More impressive: the completion rate stayed above ninety-nine per cent even as volumes climbed. Dispatchers processed nearly 130,000 requests on the busiest month of the year. Not one call was lost, not one job left orphaned in the queue.
#1
1+ million jobs
Completed over 1 million patient transport jobs with steady performance.
#2
99%
Consistently achieving over 99% of job completions with minimal issues.
#3
5 minutes
Providing superior service with an impressive response time of 5 minutes.

What changed for nurses? They created requests through the same screen every time—no calls, no follow-ups, no double-entry between departments. The moment a ticket appeared, its status timeline began: created, assigned, accepted, arrived, completed. Anyone with permission could open that timeline and know exactly where the patient or parcel stood.
What changed for agents? Their phones now displayed a simple list: current jobs on top, upcoming jobs below, each tile colour-coded for urgency. If something urgent overrode the queue, it jumped to the top automatically. Rejections were allowed—but only with a reason code and within the limits set by policy. That data became gold for supervisors, revealing hidden bottlenecks long masked by polite silence.
All this orchestration might sound like a major infrastructure project—something that requires quarters of planning, change management committees, and a spreadsheet the size of a runway. But that’s the twist: Dispatcher didn’t demand more from hospital I.T. It gave them their time back.
The platform is cloud-native, built to float above the complications of physical infrastructure. No server racks to install. No nightly database tuning. No fire drills because a Windows patch broke something critical. Devices enrolled with a single QR code. Updates pushed quietly via the app store. If the quality department wanted a new analytic view, the vendor enabled it at the platform level—no work orders, no delays, no risk.
When the hospital logistics leadership decided to expand Dispatcher to a third hospital—one with a completely different layout, team structure, and mix of services—the I.T. team didn’t flinch. Under the old claim-based model, that would’ve meant cloning legacy databases, hardcoding new department names, scheduling weeks of training, and praying nothing collapsed under the weight of customization.
With Dispatcher? They copied a workspace template, redrew the zones on the map, and shipped a new set of devices. Everything else scaled automatically.
But perhaps the most extraordinary detail wasn’t the lack of technical friction. It was how quickly the change took hold.
From kickoff to go-live, the onboarding process took less than two weeks. That’s not a typo. In under 14 days, the hospital had:
And within that same period, teams were not just “learning the system”—they were using it at full speed.
For a transformational project that touches dozens of departments, hundreds of staff, and thousands of daily interactions, this was nothing short of remarkable. What would normally take a quarter took two weeks. What would usually require IT escalation became a routine deployment. What once drained bandwidth became invisible—because it worked.
One IT manager, with a smile half-pride, half-relief, summed it up perfectly:
“It’s the first time in years we introduced a system this big … and didn’t get flooded with support tickets.”
In the end, Dispatcher wasn’t just a tool for hospital logistics.
It was a quiet gift to the IT department—proof that radical change doesn’t have to come wrapped in complexity.
Looking back, the leadership team never set out to chase tenfold improvement. That wasn’t the brief. They weren’t aiming for a moonshot. There was no pep talk about disruption, no burning platform, no mandate to revolutionize the system. All they wanted was clarity—real, moment-to-moment clarity. “What if we could actually see what’s going on? What if decisions weren’t guesses? What if we could respond at the speed of now?”
What came next surprised everyone.
Once clarity arrived, speed followed. Efficiency followed. Fairness followed. Morale followed. The numbers didn’t just improve—they unlocked.
Because incremental gains demand heroic effort. They require squeezing harder, moving faster, asking people to try just a bit more every day. 2X is painful. It assumes the same system, stretched twice as far. But 10X? 10X demands something else. A new lens. A different set of questions.
And in this case, those questions led to a very simple frame:
Map the reality.
Don’t structure operations by department names or administrative silos. Structure them by how people move—how work actually flows. That’s how hub definitions were born: not by copying org charts but by walking the halls, tracing footsteps, and acknowledging real-world motion.
Assign by data.
Humans are great at judgment, but terrible at volume. When 40 jobs land in 10 minutes, no one can manually calculate optimal routing. So the system did it instead. It weighed workload, location, skill coverage, queue size, and urgency—every second. Dispatching became less reactive, more rhythmic.
Remove loops.
One of the most damaging (yet invisible) inefficiencies was the “What’s next?” loop. After completing a job, agents often returned to a desk—or waited for a call—just to receive another instruction. Once those loops were cut and jobs flowed directly to devices, it was as if a fog lifted. Every second gained was a gift returned to patients.
Track for insight, not surveillance.
The system tracked timestamps, zone entry/exit, job delays, cycle time breakdowns—not because it wanted to control people, but because it wanted to understand work. And when work paused, so did tracking. Stealth Mode meant privacy stayed sacred, even as transparency improved. This made it easier to improve processes without breaching trust.
It wasn’t a massive strategy shift. It was a massive clarity shift. And with clarity, the curve bent. 10X wasn’t a moonshot—it felt inevitable.
Agents didn’t walk faster. They walked smarter. Nurses didn’t get more devices. They got fewer delays. Dispatchers didn’t memorize more—they let the system memorize for them. And the operations team didn’t burn out trying to chase KPIs—they designed a system where KPIs emerged organically, just by doing the work right.
The biggest insight?
Trying to double performance forces you to fight the system. Trying to 10X it forces you to change the system.
That’s why it felt easier.
Because you can only work harder for so long. Eventually, you need something better.
The contractor who once celebrated a single site now imagines a national network where every hospital speaks the same logistics language, yet each retains its own workflows. Hub boundaries will change daily, Optimizer rules will evolve, and location accuracy will tighten as campuses upgrade Wi-Fi. But the core stays constant: hospital logistics as a service, not a scramble.
That future begins with a question. The same question you may be asking today:
“If we already get by, why change?”
The answer is written in a million completed jobs, a five-minute response time, and a team that ends the shift tired from meaningful work—not from chasing paper.
You don’t need every step planned. You need the next step visible. Dispatcher makes that step clear. And once you take it, the path to 10X is shorter—and easier—than anyone ever warned you.
Numbers persuade, but nothing convinces like watching a request appear, flow, and close before your eyes. First Run—our no-risk pilot—drops Dispatcher into your workflow, on your devices, with your people in charge. One week later you’ll know whether the future feels lighter or heavier.
We think you’ll find it lighter.
Interested in running your own First Run pilot? 🎉
Reach out to us and we’ll show you what your hospital looks like in motion—without the delays.
Because when hospital logistics stops being invisible, progress stops being hard.
Continue Reading

30 June 2025

Piyorot Piyachan
CEO of Mutrack

16 June 2025

Piyorot Piyachan
CEO of Mutrack

15 January 2025

Piyorot Piyachan
CEO of Mutrack