Case Study: Staffing Planning at the University of Zurich
The Zentrum für Reisemedizin at the University of Zurich is Switzerland’s leading provider of travel medicine. It employs more than 100 clinical and administrative staff. Many are students, work part-time, or split their day between clinical and research roles. That makes staffing and long-term planning especially challenging.
Planning at ZRM worked because the person doing it knew the clinic inside out. She knew who was available, who was trained for what, and who preferred which shifts. That knowledge had been built up over years, and much of it lived with her rather than in a system. When she was on an unplanned leave for a while, two colleagues took over the planning and had to reconstruct the picture from the existing staffing planning system, a Teams channel, post-it-notes, an email inbox and an Excel list. That was the point at which the clinic decided to do something about it.
In addition to the bottleneck in planning, the clinic had sometimes hired extra staff to absorb fluctuations in demand and employment levels. On other days, it was short-staffed in specific disciplines. There was also no staffing key to plan against.
This was not a clinic-specific problem, but rather a process issue: the official system held the formal records, but the work still depended on context outside that system.
The System Didn’t Match The Workflow
ZRM uses Polypoint PEP, an industry-standard system for shift planning and scheduling that also interfaces with the University’s HR system. What was missing was a clear view of how employment changes over the long term. That made forward-planning difficult. Employee preferences were also hard to account for unless the planner tracked them separately, outside the platform.
Daily planning had drifted out of the system altogether. Whoever from the management team was responsible for that day’s assignment read the plan out of PEP and retyped it into a Word table and a Teams channel. The front desk printed that table every morning so staff could pencil in reassignments by hand.
This is a common situation. The system of record does its job, but a few workflows do not fit into it, and people end up handling those in Word documents, in emails and from memory.
We kicked off the project in February 2026. Within a month, ZRM had a prototype it could respond to. Since July 2026, the clinic has been using the software, planIQ, in its daily work.
Key Decisions
Keep the System of Record
Polypoint PEP, the existing planning platform at ZRM, does not cover all the functionality ZRM needed. But as the system of record for shift planning, it connects to key HR systems and supports processes adjacent to planning. Replacing it was explicitly a non-goal.
That meant planIQ had to sit next to PEP. PEP remained the source for official shift and employment data. planIQ used that data to support the planning work that had previously happened around PEP: long-term staffing scenarios, competencies, preferences and the printed daily plan.
Let the Prototype Shape the Concept
The goal for planIQ was to give the people responsible for planning an interface that actually helped them. Going live within months meant the discussions about functionality had to happen early. A prototype made those discussions tangible: people could try the workflows, react to the screens, and decide what the app really needed to do. It also nailed down early the information we needed to access from PEP.
Treat Hosting as Part of the Product
An agentic coding platform helped us move quickly early in the project. Once the concept was clear, however, we moved the infrastructure in-house. Staffing software works with employee data, and that data needs careful handling. An internal tool like this also has no reason to be reachable from the public internet. Because of that, we planned the migration to University IT infrastructure early instead of discovering any issues at go-live.
The mechanics of that migration are a topic of their own. I’ll cover how to take an AI-built prototype to production in a separate post.
Data on a Need-to-Know Basis
Vibe coded apps tend to show whatever data is available. Since this app handles employment data, we wanted to be deliberate about surfacing only what the work actually requires. That started during development. The prototype needed realistic data, but it did not need real employee data. Agentic coding tools are useful when they can see the shape of the problem: roles, employment percentages, absences, competencies, preferences, edge cases. They do not need to see actual people.
So the app was developed against pseudonymized demo data: a copy of selected real planning data where names, contact details, personnel IDs and other direct identifiers had been replaced.
Only when the app moved onto University infrastructure did we connect it to the daily snapshots from PEP. Even then, employee data that was not relevant to the workflows never made it into the app: there is no salary information and no other sensitive HR data. We also introduced user roles that grant access only to the parts of the app relevant to that person. An admin sees more than a planner, who sees more than an employee.
Handover to Internal IT
The project did not end when the app went live. Internal IT needed to know how the app was built, what infrastructure it depends on and, most importantly, how to extend it after handover. Today, the department’s IT team can make minor changes themselves with the support of coding agents. The project carries its own context: the original brief, the design patterns, and a decision log explaining why things work the way they do. A small change request no longer has to become a new project.
The Solution
planIQ is an internal web application running on University IT infrastructure. It receives daily snapshots of personnel, absences such as parental leave or holidays, and the employment details needed for scheduling.
The software covers three main scenarios:
- Modelling long-term employment scenarios: “Do we have enough of the right competencies next November, even when people are on leave? Are we already over-staffed?”
- Managing competencies and preferences: “Who can cover travel consultations based on their training?”
- Day-to-day planning: “Who works which shift today?”
Competency matrix in planIQ: planners can see who is qualified for which services, at what level, and how many qualified staff are available per area. Screenshot with pseudonymized demo data.
Capacity planning in planIQ: surplus and shortfall per service across twelve months. Screenshot with synthetic capacity and demand data.
Results
planIQ has been in daily use since July 2026. Two planners work in it weekly, whoever holds the day’s supervision rota opens it every morning, and the department head uses it monthly for the longer view.
What surprised me: daily planning was the smallest of the three scenarios and not the reason the project existed. It is the one that gets used every single day now. Nobody retypes the day plan into Word any more; planIQ generates a formatted PDF at the click of a button, and that is what the front desk prints. The benefits of this refined process are felt by employees every single day.
Planning is faster. More importantly, it is no longer one person’s job to know things. Anyone tasked with planning can now see who is available, who is qualified for what, and whose preferences have already been accommodated. The plans are not just quicker to produce; they are better. Preferences get honored more consistently because they live in the same place as the plan instead of in someone’s parallel list.
ZRM can finally answer the hiring question. Before the project, there was no staffing key at all. Today, the clinic can see which competencies will be short in which month and hire against that instead of hiring to absorb uncertainty.
“From a business standpoint, the project paid for itself just with the timeline page. It is interactive, and it lets me see across a calendar year not just how much FTE we have, but what profiles we have at which skill level. That matters because our teams are so mixed. Without planIQ, that matrix organization was never visible enough when planning ahead.”
— Jenny Crawford, Business Manager, Zentrum für Reisemedizin, University of Zurich
When This Approach Makes Sense
A few conditions were in place at ZRM that made this project work. If you are looking at something similar, it is worth checking whether they apply to you as well.
There was a system of record that we did not have to touch. The workflows we built already existed somewhere: in Word, in Teams or in someone’s head, so we did not have to guess whether anyone would use them. The data was sensitive, but limited enough that we could be strict about what the app was allowed to see. And there was an internal IT department that was willing to take the app over at the end.
If one of those is missing, I would probably give different advice. If the underlying process does not work, an app will not fix it. And if nobody in the organization can maintain the app afterwards, the project will run into issues within days of productive use.
If that sounds like a situation you recognize in your own organization, a workflow that has fallen out of your main system and now lives in a spreadsheet, a Word document or one person’s head, get in touch.
Share
About the Author
