About us

ไทย

Join us

Work on meaningful problems with good people.

Piyorot Piyachan17 February 2025

Share this essay

Join us
LINE Facebook Email

We’re a small team PiyorotSataporn focused on building great products that solve real problems in thoughtful and meaningful ways.

We care about the details, the impact, and the people we build for. If you enjoy thinking deeply, creating with purpose, and making things better, you might find a home here.

A different way to improve hospitals

Mutrack is built on clear principles that reflect how hospitals actually operate, how people really work, and how lasting improvement is achieved.

Hospitals as interconnected systems

Hospitals do not operate as isolated departments or standalone workflows. They function as interconnected systems—where people, spaces, equipment, and time continuously influence one another.

Operational problems rarely stay where they appear. Patient delays surface in wards but originate in transport. Equipment shortages show up in procedures but begin in circulation, visibility, or timing. Optimizing one area in isolation often pushes friction elsewhere instead of eliminating it.

Mutrack starts at the system level. By connecting movement, availability, and workload across departments and roles, it allows improvements in one part of the hospital to strengthen the whole—rather than shifting bottlenecks downstream.

This is why system-level clarity creates results where point solutions cannot.

Plan vs. intelligence

Traditional operations rely on predefined plans and static assumptions. Hospitals, however, change by the hour—patient volume, staff availability, priorities, and constraints constantly shift. Systems built around fixed plans quickly fall out of sync. Mutrack focuses on real-time operational intelligence—allowing hospitals to respond to what is actually happening, not what was expected to happen.

One system, multiple roles

Hospitals succeed through coordination across many roles, not through isolated tools. Doctors, nurses, porters, technicians, and managers operate within the same system—but require different views, levels of detail, and interactions. Mutrack supports multiple roles through tailored experiences built on a shared operational foundation, so each role works effectively without losing alignment with the whole.

Hyper-location intelligence as the foundation

Physical location is the invisible layer behind most hospital operations—movement, waiting, handoffs, and availability. Mutrack is built as a hyper location–intelligent platform, using precise indoor context to connect people, assets, and activities in real time. This foundation enables multiple applications—today and in the future—without fragmenting the system into disconnected tools.

Human-first design

Hospital operations work because of people—professional judgment, experience, and coordination under pressure. Technology that ignores this reality may look efficient on paper, but often fails in practice.

Many systems are designed to maximize control, compliance, or reporting. In real hospital environments, this approach creates resistance, workarounds, or silent disengagement. When staff feel monitored rather than supported, the system gradually loses accuracy and usefulness.

Mutrack is designed around the people who do the work. Visibility is provided to reduce uncertainty and friction—not to replace judgment or enforce rigid behavior. By respecting roles, context, and professional autonomy, the system supports coordination that feels natural instead of imposed.

This is why human-first design leads to adoption, trust, and sustained use—where control-first systems eventually break down.

Clear, calm user experience

Complex systems fail when clarity is missing. Mutrack’s interface design prioritizes simplicity, relevance, and calm interaction—showing the right information at the right time, and never interrupting users unless it’s needed. A clear user experience reduces cognitive load, shortens decision time, and helps teams act with confidence, even under pressure.

Designed for real work

Hospital work is interrupted, non-linear, and shaped by constraints. Systems built around idealized processes add friction in reality. Mutrack aligns with how work actually happens—across shifts, interruptions, and exceptions—so staff spend less time managing the system and more time doing their jobs.

RespectDignityPrivacy

Respect, dignity, and privacy by design

Human-first means acknowledging that people are not machines. Mutrack is built to respect professional judgment, personal dignity, and privacy—avoiding simplistic interpretations or automated judgments about “performance” without context. This creates an environment where people feel supported rather than evaluated, making participation honest and sustainable.

10X improvement philosophy

Incremental improvement focuses on making existing processes slightly better. In hospitals, these gains often plateau because they operate within the same constraints—fragmented workflows, delayed information, and heavy reliance on manual coordination.

10X improvement takes a different path. It redesigns the structure that creates those processes, addressing friction at the system level rather than optimizing individual steps.

Mutrack enables this shift by removing hidden effort—searching, waiting, checking, and rework—through automation and real-time operational intelligence. Improvement comes from alignment across people, space, and time, not from pushing staff to work harder.

This is how progress becomes sustainable without placing additional strain on people.

Curated automation and intelligence

Automation and intelligence are applied intentionally—only where they augment human judgment and support better coordination. Systems are designed to remove friction, not dictate behavior. By reducing manual handoffs, waiting, and repetitive work, teams operate with greater focus and flow. Productivity improves as a result of better alignment and less waste—not increased pressure on people.

Abundance of real-time information

10X improvement requires visibility that is timely, trustworthy, and continuous. Mutrack provides an abundance of real-time operational information—accurate, complete, and grounded in what is actually happening on the floor, not delayed reports or assumptions. When frontline teams have reliable information at the right moment, decisions are made faster and with greater confidence.

Elimination of systemic waste

Most operational cost and delay come from work that should never exist—idle walking, repeated counting, paperwork, manual reconciliation, unnecessary rentals, and avoidable asset loss. Mutrack is designed to remove these forms of waste at the system level.

Life at Mutrack

We work hard every day to build a modern, supportive workplace for amazing people like you. That’s why we offer competitive salaries and a comprehensive benefits package for full-time employees, including time off, health insurance, and educational opportunities for career growth.

The team round the meeting table, posing for the cameraThe Mutrack sign by our office doorLunch together, gift bags in handA colleague listening across the meeting tableFramed posters waiting to go up on the wallColouring with children at a schoolPresenting Dynamic Shift Rostering in our meeting roomSketching an idea over app screens on a tabletA colleague raising her drink at the meeting tableFive of us by the glass wall, peace signs upA chair seen through the fluted glass of a meeting roomTwo of the team going over a design on a tablet togetherLaughing during a photo shoot in the officeTwo of the team holding up printed booklets

We are a digital-first company.

From the very beginning, we’ve been a remote-first team. We believe in flexibility while staying connected and productive with the right tools to help you do your best work—wherever you are.

You will build something great.

Whatever team you’re on, your ideas and contributions matter. You’ll play a key role in creating exceptional products and experiences that make a real impact.

You can learn and grow.

You won’t be the same person after working with us. We support continuous learning and happily reimburse members who buy books, attend professional conferences, or take courses to develop new skills.

We love spending time together.

Giving back is part of our culture. Whether it’s charity work, knowledge sharing, or team outings, we always make time for offsite trips, lunches, and monthly group dinners to strengthen our bond beyond work.

Internship Program

Every year we open one class of data science interns. It’s a co-op, four to six months with us, and the work is about the future: products and features we don’t have yet. Each class receives an assignment letter before it starts. Where the work leads is theirs to discover; sometimes it stays on course, sometimes we change direction together.

Class 27

Precision in Motion

Can we build a copy of a hospital good enough to break on purpose, a thousand times, so the real one never has to?

Two places, one for the Simulator and one for the Optimizer, opening in November.

Class 26

AI that matters

Can we teach an AI to write a performance report that actually helps someone?

They stayed on course. What began as a generative report became Mu, our operational intelligence.

Class 25

The Worker Model

A system that doesn’t just count tasks but truly understands the people performing them.

In the first week, we decided together to change direction, to Roster. Their ideas shape it.

Class 24

The R4 Project

To use the data to answer some questions nobody has asked before.

Prediction models for porter jobs at each hub and location, which inspired Class 25 to carry on into Roster.

Class 27

Precision in Motion

Dear future Class 27 intern,

Let me tell you a story.

It is 10:00 on a Monday morning in a hospital in Bangkok. Clinics open. Imaging lists start. Wards send patients down for scans. Within one hour, sixty people need a porter.

Thirteen porters are on duty.

For a while, everything is fine. Each request is picked up in a few minutes. Then three more arrive. Then five more. Somewhere, without anyone noticing, the hospital crosses a line. A patient who would have waited four minutes now waits twenty-five. A scan is missed. A surgery list slips.

Nobody did anything wrong. Every porter was working. The system simply broke.

And here is the strange part. In a building on the other side of the hospital, quiet at this time of day, four porters are standing idle. They belong to their own hub. They are not allowed to come.

We build Dispatcher, the platform that sends those porters to those patients. We have the data: every job, who took it, when it started, how long it took.

What we cannot do yet is see the line before we cross it.

Your Mission

Your internship will revolve around one question:

Can we build a copy of a hospital good enough to break on purpose, a thousand times, so the real one never has to?

Find where it breaks. Then find a way to keep it from breaking, without hiring a single extra person.

Imagine a hospital manager reads this one morning:

At today’s settings, Monday 10:00 breaks at about 70 jobs an hour. Let neighbouring hubs share porters when the queue builds up, and it holds to about 76. Move idle porters toward Radiology at 09:30, before the work arrives, and it holds to about 82. Same porters. Nobody hired. Twelve more patients an hour, moved on time.

Those numbers are made up. Finding the real ones is your job.

What you build will become part of Mu, our operational intelligence. You already know its name from every statistics class you have taken: μ, the mean, the line against which every variation is judged.

What You’ll Try

There are two of you. One mission. Two halves that cannot work without each other.

It starts with a day exactly as it was. We replay any day of patient transport on screen: every job, every porter, every minute, pure and unaltered.

One of you builds the Simulator, and takes over from there. First, you run that same day through your simulator with nothing changed. It should land on what really happened. When it doesn’t, the gap is your model’s error, and finding out why is where you will learn the most.

Then come the what-ifs. One more porter in this hub. Auto reject at 2 minutes instead of 3. A manager asks for the change, in plain words to Mu or on a screen, and your simulator reruns the day a thousand times, because one rerun is only one possible day. Then it shows the new result beside the day as it was. Finally, you push demand up until each hour breaks, and you can say how much room every hour has left.

One of you builds the Optimizer, which decides what the hospital should do. First you have to know what best means: the fastest response, the most room before breaking, the fairest workload for porters, or the least waste. Each is a different goal, and they pull against each other. Then, for each goal, you search the settings Dispatcher offers:

  • how jobs are matched to porters;
  • when porters take their breaks;
  • how long a job waits for a porter to accept it before it moves on;
  • whether a hub lends its porters when the hub next door is drowning.

And if you go far enough: telling porters where to wait before the work arrives. Like ride-hailing drivers who know that tomorrow morning, the orders will come from this street.

Whatever you try, you choose the winner with a confidence you can state, because every answer from a simulator is a little noisy, and luck must never pick the winner.

The Simulator measures. The Optimizer decides. The Optimizer asks the Simulator about every plan it considers, so it is only as good as the Simulator is honest. When the two of you disagree, one of you is wrong, and you will have to find out who.

The hospital keeps its secrets. We built a hospital for you. You will see exactly how its dispatching works: every matching rule, every setting. You will watch its days replay on screen. What you will never see is how its people behave. You get only what they leave behind: their job history, month by month, exactly as a real hospital would. Somewhere in that history are behaviours we put there on purpose. Nobody will tell you what they are.

Finding them is the work.

How You’ll Learn

You will build in two ways, and learning both is the point.

The hard work, you write yourself, in Python. Pipelines that read the hospital’s history, fit your models, run your simulations thousands of times, and write what they find to our analytics database. Real code, in our real codebase, with tests and code review, merged like everyone else’s. Your first two months are mostly this. You may ask Claude, our AI coding assistant, to explain an error or review your code. You may not ask it to write your statistics. If it writes your model, you will have a model and no understanding.

Everything that shows your work, you build with AI coding assistant. The screen where a manager watches a day replay. The panel where they try a new setting and see the breaking point move. The Skill that lets Mu explain your result in plain words, without ever making up a number: every figure Mu says comes from your pipelines. This is the new way of building software, and you will learn it by doing it.

Every phase ends with both: a result from your Python, and a screen built with the AI coding assistant that lets someone see it.

Then the statistics you studied gets a job. It will come as five questions, one at a time:

  1. Can I trust this data?
  2. How does the work arrive?
  3. How long does the work take?
  4. Why is my simulation wrong at 10:00?
  5. What would have happened if we had done it differently?

Every month, the hospital releases another month of its life. Before it does, you predict what it will show. Then it arrives, and you find out how far off you were, and whether you knew how uncertain you were. We care more about honest than about confident.

Your first simulator will be wrong. That is not a setback. That is the assignment. Find out why, fix it, try again. The second one will be wrong too, in a more interesting way.

The Output

By the end of your internship, you will have built:

  • a simulator of patient transport, in Python, tested and merged;
  • the room every hour of the day has left before it breaks, under every policy you tried;
  • the best plan for each goal, and how sure you are of it;
  • an answer to a question hospitals pay for: how much more can the same porters handle?
  • the screens and the Mu Skill, that let a manager see your answers and ask about them;
  • an honest record of every way you were wrong, and what it took to get it right.

The internship is four months. If you are all in, it becomes six, and your work goes into Mu, where a hospital manager can ask it a question and get your answer.

It starts in a hospital we built. But the question is real. Every hospital we serve faces it every morning at ten.

We believe in a Precision Society: one where the work that keeps people alive is measured honestly, so it can be done better. Patient transport is where we start.

Who We’re Looking For

You don’t need to be a programmer yet.

You don’t need to know anything about hospitals.

But you do need to want to test your statistics against something that pushes back. You need to be curious about why things break, and stubborn enough to try again when your model does.

You need to believe that a porter’s work is invisible only because nobody has looked at it closely enough. And that behind every job in the queue, there is a patient waiting.

This isn’t a training program. There is no answer sheet you can find. There is a hospital, its secrets, and the two of you.

If that sounds like you, then welcome to Class 27.

We can’t wait to work with you.
Class 26

AI that matters

Dear future Class 26 intern,

Let me tell you a story.

At our company, we run systems that help hospital staff do their jobs better—porters, nurses, interpreters, logistics workers, and more. These are the people who move patients, deliver blood samples, carry medicines, and make sure nothing gets left behind.

Every day, they complete tens of thousands of jobs inside hospitals. Our platform, Dispatcher, tracks them in real time—who accepted which task, how long it took, how many jobs they completed in a shift.

We have the data.

What we don’t have—yet—is the clarity.

That’s where you come in.

Your Mission

Your internship will revolve around a deceptively simple idea:

Can we teach an AI to write a performance report that actually helps someone?

Not just charts.

Not just numbers.

But something that a team lead can read and immediately say:

“Ah. Now I see where we’re strong. And where we’re struggling.”

You’ll explore how to turn raw performance logs into stories. How to design metrics that matter. How to write logic that guides AI to say something meaningful—without sounding robotic. And how to do it all while keeping in mind one thing:

Every “job” in the system was once a real task from a real person for real help.

What You’ll Try

Imagine a hospital supervisor opens their dashboard and sees this:

Hello K. Areepanich,

You completed 59,121 jobs this month with an on-time rate of 96.3%.

Your peak hours were Wednesday 12:00–15:00, where SLA performance dipped by 9%.

8 of your agents worked over 110% capacity.

Consider rotating high-load agents or adding part-time support during peak hours.

Thank you for keeping things moving. — Dispatcher AI Report Engine v1.2

That paragraph was generated automatically. Your challenge? Teach the AI how to write that. But better. The big question for you is are you committed to this?

  • Designing a rule-based AI engine that writes human-friendly reports from raw data
  • Defining which metrics matter—and which ones don’t
  • Figuring out how AI should speak when things go wrong (blame? coach? stay silent?)
  • Turning confusing dashboards into insightful, readable summaries
  • Finding ways to help real supervisors see their teams more clearly
  • Exploring the tension between precision and perception—what should the AI highlight, and why?

This internship is about experimentation. You’ll try things. Some will work. Some won’t. But every attempt brings you closer to clarity—and your code might just end up powering the next version of our reporting system, used in real hospitals across the country.

The Output

By the end of your internship, you’ll have built something that:

  • Generates automated reports based on live data
  • Can be used by supervisors to make better staffing decisions
  • Helps agents understand their own strengths and areas to grow
  • May even be shown to hospital directors who want to improve their teams

This is not a mockup. It’s not a “test task.”

It’s real work. For real users. In real hospitals.

Who We’re Looking For

You don’t need to be an AI expert.

You don’t need to be perfect at Python or dashboard design.

But you do need to care.

And yes—you’ll need to be ready to get your hands dirty with real code, real logic, and real-world complexity.

You need to believe that clarity is a form of kindness, that invisible workers deserve recognition, and that AI should help people—not confuse them.

Because this isn’t a training program. It’s a chance to build something that people might actually use. Something that helps make invisible work visible. Something that matters.

If that sounds like you, then welcome to Class 26.

We can’t wait to work with you.

Warmly,

Piyorot Piyachan
CEO, Mutrack
Class 25

The Worker Model

Dispatcher at Its Core

Since Day 1, we had decided to create Dispatcher for operators like porters, messengers, and service agents. We took a courageous journey to put those who usually are neglected first—before managers and executives. Because we see them as a person, understand how hard they work every day to make sure a hospital can be run effectively with logistical needs.

Dispatcher is built to capture as much as possible the effort these workers pour into their tasks. Every task, every step, every minute counts, because when it comes to measuring and evaluating their contributions, they will finally get the recognition they deserve.

This was the core idea that ignited Dispatcher. And it still is today. But we feel that it’s time to find a better way to do this—time to go beyond simple tracking and basic reports.

We need to build a system that doesn’t just count tasks but truly understands the people performing them. A system that can analyze, learn, and improve over time—one that recognizes not only how much effort is being poured into the work but also how best to support and empower those workers.

This is why we are launching the Worker Model Project, and we need creative, data-driven minds to join us in this journey.

A Holistic Design for the Work Model

We are not afraid to think differently and act purposefully. This time too that we don’t shy away from not looking at what others are doing because we have our own ideas - the holistic one that can be a new industry standard for evaluating field service agents.

Our Worker Model must integrate multiple dimensions of performance into a comprehensive evaluation framework. By combining quantitative metrics like job count and complexity with qualitative factors like feedback and efficiency, our system offers a multifaceted view of worker performance that is not commonly seen in typical dispatch or workforce management systems.

This holistic approach will not only capture how much work is being done, but also how well it is being done. It will allow us to evaluate workers fairly, recognizing their strengths, identifying areas for improvement, and ensuring that every worker’s contribution is valued and optimized for success.

Let me reassure you that this initiative is vital to the success of Dispatcher. It will reaffirm who we are and what we stand for—to make technology that puts people first. This is not just about building a better system; it’s about staying true to our mission of empowering the individuals who keep everything running behind the scenes.

The challenges that lie ahead are paramount. We are not just creating a simple dashboard, although that is important too. Instead, we must answer critical questions that will shape the future of our Worker Model:

  • How can we truly understand workers by looking at their performance?
  • How can we ensure fairness in every aspect of the system?
  • How do we safeguard against any misuse or misinterpretation of performance data?
  • How can we seamlessly combine quantitative metrics with qualitative insights?
  • How can we design an evaluation system that fosters constructive feedback?
  • How can we build the model that is flexible and adaptive for future improvement?

When you look at this project closely, it’s clear that it goes far beyond just data aggregation, preparation, modeling, and visualization. This is a full-fledged design thinking practice that requires creativity, empathy, and a determination for solving complex problems.

Fueling Innovation with Your Ideas

At Mutrack, we believe that your ideas are crucial to the development of our platform. Let me share an example that I find truly inspiring.

In 2024, one of our interns (Class 24) used K-means clustering to analyze worker performance based on a number of jobs and a total time of executing the jobs of each worker. The result was a graph that classified workers into Fair, Good, and Exceptional categories based on their past performance, as shown below:

Porters clustered by jobs and total time worked, 2024 025005000750010000125001500017500 02004006008001000120014001600 Time worked Jobs FairGoodExceptional 0.000.250.500.751.001.251.501.752.00 Cluster

Porter Performance with K-Means Clustering

This visualization didn’t just highlight differences in worker performance—it opened up new ways for us to understand and improve our system. This kind of data-driven innovation is exactly what we encourage here at Mutrack. Your contributions could lead to similarly impactful results, and we are here to support and nurture your creativity and determination.

I am not going to tell you everything about the Worker Model. I want to hear your ideas. I want to challenge you to think and express how we can make this even better. I want to you come up with better ideas than mine.

Are you up for it?

From Academic Assignment to Novelty

This project is more than just an academic exercise. The Worker Model will be a critical part of our future dispatching system, enabling us to improve worker efficiency, job satisfaction, and resource allocation in real time. Your work will directly impact how hospitals and organizations around the world manage their teams—creating smarter, more dynamic systems that benefit both workers and managers.

It is a big task with a lot of unknowns. But this is the beauty of doing creative works. We will work as a team with our technical leader and me as strategists and consultants to deliver something truly amazing (if we succeed). We will cross the line nobody else ever did before together.

Exciting times ahead!
Class 24

The R4 Project

Background

Over the years, we have been collecting a lot of real data from a few big hospitals who use our products - Linen and Dispatcher. And for a long time, I have been dreaming about mining this kind of big data to help improve our customers’ operations and to step closer to the ultimate goal of ours - “To help customers become better decision makers”

This may be a good time that we can start doing something with this by collaborating with fresh-minded students and universities. Although the goals can be adjusted but the intention is still to use the data to answer some questions nobody has asked before. Follow me.

The Better Version of Dispatcher // Dispatcher 2.0

Why Dispatcher? What’s wrong with Linen? Nothing but I think Dispatcher is a better showcase that can link up many big data with real process improvement. It is a great example in which we can look back in the past to understand our customers’ performance, use historical data to optimize real-time productivity and even predict what to happen and suggest a proactive plan.

Understanding What Has Happened

Most of the time, data visualization works with historical data to help us understand more about what has happened. Data turned information and knowledge can enlighten us to think about how well we performed and in which area we could have done better.

DashboardTotal Jobs : 51

Job by Status

Job Created1
Inprogress0
Completed40
Cancelled7

Porter by Status

Available0
Active0
Not Responding2
Inactive2
No. of Jobs - Last 7 Days
262728293012
Time of the Day of Jobs - Last 7 Days
00:0003:0006:0009:0012:0015:0018:0021:00
Duration of Jobs (mins) - Last 7 Days
5101520253030+
Average Jobs per Porter - Last 7 Days
262728293012

The Current Simple Dashboard

The idea of the current dashboard is to help managers see real-time numbers (Job by Status and Porter by Status) and operational trends of the porter team.

GraphDescription
No. of JobsTo see job trends in the last 7 days
Time of the Day of JobsTo see peak durations of the day
Duration of Jobs (mins)To see how long most of jobs were
Average Jobs per PorterTo see if porters took reasonable no. of job per day

Is it too simple? - Maybe. It works as it is but it can be a lot better with data. If we look closely to the current dashboard, they provide so little knowledge to the managers about their teams’ performance. The “No. of Jobs” says almost nothing about the fact that their staff were doing OK. The “Time of the Day of Jobs” doesn’t indicate how long the jobs were taken from start to finish. Our dashboard must bring more values to the customers. We need more.

Jobs by Status

20 On Going
3 On Hold
2 Unaccepted
4 Delayed
7 Scheduled
3 Priority

Porters by Status

24 Available
27 On Duty
10 On Hold
8 Main Break
2 Mini Break
0 Unscheduled Break

Process Efficiency

82% Ontime
42.1m▲19% Avg. Lead Time
2.2m▲3% Accepting Time
8.3m▼13% Preparing Time
14.5m▲6% Waiting Time
16.8m▲7% Delivery Time

Workload

431 Job Finished
7 Jobs per Porter
243.2km Distance Covered
3.98km Distance per Porter
214.1h Work Duration
3.5h Duration per Porter
Ben Watson 19
Grace Willock 17
Wayne Curry 14

Top Three Porters by Jobs Taken

Ben Watson 4.1
Wayne Curry 4.0
Paula De Marco 3.6

Top Three Porters by Distance Travelled

The Enhanced Dashboard - 1

What if we can deliver more to help our customers (managers) understand more about what is happening on the ground? We should introduce “Process Efficiency” dashboard to break down a big process into smaller steps and compare each of them with past performance - be it yesterday’s, or even last hour’s. At least, this gives the managers something they can take action with. For example, if they see the average lead time is 19% worse than the last hour, they may deploy more staff to improve the service level. This kind of data presentation should inspire actions.

We can do better with insights. A time series concept should be employed here to visualize operating trends. No of jobs, Delay jobs, Average jobs per porter, and more are there to compare the current stat (today) with a selected previous period (yesterday).

Then, there can be another kind of graph that shows both time series and performance targets - Average Ontime Percentage for instance. Not only does it shows a time series graph, it also draws a dotted line to help the managers see if how well their teams met a performance target.

Jobs

3,459Total Jobs▼ 3%

Delay

31Total Delay Jobs▲ 8%

13 July: 12 jobs
Average Jobs per Porter

25Jobs▼ 12%

Distance

2,153kmDistance▼ 6%

Average Ontime Percentage

82%Ontime▼ 3%

Average Leadtime

40.1mLeadtime▲ 11%

Leadtime Distribution by Minutes

45%Of Jobs Done Between 30-40m

Leadtime Distribution by Steps

18.3mLongest Time at Delivery

Top Porters by Jobs Taken
Ben Watson192
Grace Willock190
Wayne Curry187
Christy Blues187
Ryan Butterfield186
Rory McCann183
Pat Rowling182
Top Equipment by Times of Use
Wheelchair1,891
Infusion Pump738
Stretcher562
Oxygen Tank447
Distance Distribution

28%Of Jobs Travelled Between 1-1.5km

Top Locations by Jobs Requested
Ward 1072
Physiotherapy 258
Children Center50
ICU 140
Top Locations by Job Delivered
Discharge Center145
Physiotherapy 3104
Main Lobby91
Waiting Room85

The Insight Dashboard

The next one is interesting. It is a bar chart that represents a distribution of factors throughout a predefined spectrum. The “Leadtime Distribution by Minutes” for example, its X-axis shows a set of durations for jobs to be completed. It starts from 0-10 mins, then 11-20, 21-30, 31-40, and so on. Its Y-axis plots numbers of jobs to which were completed in each duration. For instance, there were 468 jobs completed within 31-40 minutes, which was 45% of the total jobs performed in the last seven days. When we add a comparison whether toward a performance target (leadtime target = less than 35 minutes) or historical data (43% of the total jobs performed last week were completed between 41-50 minutes), the managers are equipped with a good analysis that they can design a better operational plan to improve their teams’ performance in a near future and monitor if the new plan effectively brings the leadtime down even further.

To summarize, the first step for analyzing the data we have collected is to help users understand what has happened. The expected result from this task is to implement a better dashboard system, which looks back into the past and visualize key values that are related to general stats, operational performance, and so on.

Making a Smarter Real-Time Decision

The second level is to work with present through the now features. We need to dig deep to find knowledge that can help users answer the following questions:

Should I assign a new job to a porter now or should I wait a little longer for another porter who will be finishing his job in a few minutes?

This question seems simple but it is very complicated to answer from the system’s point of view. Let’s start with the fact that the current algorithm to find the best fit porter for a job is to look at who is the nearest to a pickup point. So, it looks at who is available first and measure how far each available porter to the pickup point and pick the nearest. At a glance, it looks the most effective way to do this but if we consider this a bit deeper, we can still see a flaw.

What if another occupied porter (Porter B) who is a lot more closer to the closest porter (Porter A) on the available list is about to finish job in the next two minutes? Will this porter be a better choice to accept this job?

What do we need at hand in real time in order to answer this question and make a better decision?

  1. Do we know with an acceptable level of certainty that Porter B is going to finish his job in less than two minutes?
  2. Do we have enough knowledge about how long (in terms of duration) Porter A is likely to take from his current spot to the pick up point?
  3. What should be our fall back plan if Porter B doesn’t finish his job as expected?

Let’s assume we know all the answers, here is what we should do. If we are certain that Porter B is going to finish on time (within less than two minutes) and it will take Porter A at least five minutes to arrive at the pickup point, we should be waiting for Porter B to finish his current job and take this one. However, if two minutes has passed and Porter B is still on the job, we need to re-calculate who is the next most fit for this job.

Another fall back idea, which may seems harsh, is to give the job to Porter A first. Let him walk to the pickup point while Porter B is in a short list. Once Porter B finishes the job, the system will decide at that moment if it should re-assign this job from Porter A to Porter B.

From the data science’s perspective, we should be able to predict how long Porter B needs to finish his job. It involves many factors; type of job, pickup and drop off locations, time of day, equipment required, past performance of Porter B, etc. It is very challenging task.

Where should porters go and wait for a job?

Imagine you are on Grab. Would you want to know where the jobs are? Definitely, because you want to be near the jobs. More jobs, more money. Same holds true with porters.

This feature, if we can implement it, will be beneficial not only for porters but for patients and hospitals too. The key idea is to suggest porters periodically where they should stand to ensure he gets more jobs.

In order to do that, we need to be able to predict where the porter service be required at what time based on the past records. If we can do so, we should be able to attract (suggest) porters to go and wait at a location nearby to increase a chance to get a job.

We must make a good balance here too. We cannot suggest a majority of porters to be at some high-demand locations and leave other locations unattended. This means that not all porters get the same recommendation. This is based on the current location of porters, time of day, type of jobs and more.

What we are trying to implement here can be, as I see it, called the “dynamic resource clustering”. With real time information, we can design a flow of porters to provide the best possible service. Let’s imagine that with an intelligent algorithm, the system starts to lead 10 porters to a zone of interest (building, floor, department) at 10.00 AM and keep the 10 porter there until 11.30 AM to only serve jobs created from that zone. In the afternoon, these 10 porters may be brought to another zone serving another high-demand locations.

Instead of a fixed cluster, we are going to introduce a new way of optimization with data, machine learning, and real time tracking technologies. This will make our solution so mobile, flexible and responsive. So cool!

To summarize, this level is to make the whole operations as optimum as possible with real time and historical data. An expected result is to apply this to the current Dispatcher through our Optimizer and Mobile App.

Forecast and Prepare More Effectively

The third level is a promise land, where the system can recommend how to prepare the resource in the best way to handle future’s workloads.

I fancy this as an advanced simulation tool. It should compare, predict and visualize the demand and supply side and see how it affects key performance indicators. We may start with a demand heatmap (day of week and time of day).

Mon 5774647971951101361121201068785898261475128 Tue 6996819387881341201832671128587856566524938 Wed 60951177772107117139131691339199362185128103968116 Thu 517993939410312012212913610091102706642403439 Fri 68679970736210110811388769073635641321822 Sat 31302016252529262442373220183516171514 Sun 19111822222330213117322526181423292139 0123456789101112131415161718
0691

A Date and Time Heatmap

Next is to dig deep into each box to understand what results were and what affected such results. As an example, if we look at Fri at 9, we managed to completed 88 jobs within that hour. Can we dissect it to be more comprehensible like this?

The Workload Heatmap
98%100%92%91%93%88%78%79%95%100%98%110%123%99%98%99%96%99%91%93%94%91%95%95%78%79%83%88%90%90%87%80%

The Workload Heatmap

Knowing only traffics is not enough. We should be able to create a heatmap for the daily workload as well. The workload can be calculated as follows:

  1. Get the total number of porters being on the shift at that particular hour. eg. 38 porters
  2. Calculate a total serviceable minutes for that hour eg. 38 x 60 = 2280 minutes
  3. Find a number of fulfillable jobs at 100% workload eg. 2280 minutes / 23.4 minutes per job = 97.4 jobs per hour
  4. Count total jobs created in that hour eg. 92 jobs
  5. Predict the hourly workload for that particular hour eg. 92 / 97.4 = 94% in the Green box

This means the current workforce can cope with all jobs created at that particular hour. What follows is as interesting. All the factors (no. of jobs, no. of porters, locations of jobs, etc) affect three main KPIs.

  • Assign time (the duration to which a job gets assigned to the next available porter)
  • Respond time (the duration to which a porter arrives at a pickup location)
  • Total time (the duration to which a porter completes a job)

By theory, if we have more supply (more porters) the KPIs will improve. On the contrary, if we have less supply, everything will start to decline.

The key idea here is to predict, simulate and recommend. Based on the past information, we should be able to predict how many jobs will be created tomorrow in each hour. Throughout the day, we can then visualize the two heatmaps above - a comparison between the No. of Jobs and Staff Workload.

TimeNo. of JobsNo. of PortersWorkloadRespond TimeTotal Time
………………
9.006020117%6 m 13 s23 m 24 s
10.007523144%11 m 32 s26 m 18 s
………………

It would be great if we could simulate scenarios where No. of Porters is changed. What if we add three more porters at 9.00, what will happen with the workload, respond and total time.

TimeNo. of JobsNo. of PortersWorkloadRespond TimeTotal Time
………………
9.006023101%5 m 25 s20 m 11 s
10.007528117%9 m 40 s22 m 51 s
………………

We can do this to have the most optimum workload (as close to 100% as possible). See the table below.

TimeNo. of JobsNo. of PortersWorkloadRespond TimeTotal Time
………………
9.00602498%4 m 40 s18 m 33 s
10.007532102%9 m 08 s21 m 10 s
………………

This will help a manager plan her service plan in the most optimum way. She may decide to deploy 24 porters during 9.00 and increase her workforce to 32 porters from 10.00 onwards. This is great.

To summarize, we aim to create a new web application designed specifically for managers. It will work as an intelligent assistant to help the managers plan their future operations better.

An Execution Plan

We definitely have big data from one of the biggest hospitals in Thailand. We are looking for ones who are inspired by this, and possess some knowledge about statistics, data analytics and computer programming to join our small-but-nimble team.

TaskDurationBy
MUST HAVE
- Get to know the system
- Prepare historical data
- Design data theory		1 monthInterns
MUST HAVE
- Model the data
- Build data dashboard
- Present results to customers and partners		2 monthsInterns
MUST HAVE
- Create data heatmaps
- Simulate scenarios
- Present results to customers and partners		1 monthInterns
MUST HAVE
- Build a new web app for manager		2 monthsDev team
OPTIONAL
- Design algorithm for real-time job shuffling
- Design algorithm for dynamic resource clustering
- Present results to customers and partners		2 monthsInterns
OPTIONAL
- Implement real-time optimization features into Web and Mobile App		2 monthsDev team

It is a big task with a lot of unknowns. But this is the beauty of doing creative works. We will work as a team with me as a strategist and consultant to deliver something truly amazing (if we succeed) together. We will cross the line nobody else ever did before together. Exciting time!

Interested in joining us? Just tell us a little about yourself through our contact form. No formalities needed—we’d love to connect!

Contents