WorkBuddy Scheduled Three Months of Department Shifts: Fast, But It Can't Do "Fairness"

Last week I was on the big night shift. At 3 a.m. the ward quieted down, and I came across an article about performance management systems. One line said that every goal-setting, every rating, every interview is traceable — something Excel can never do. The article also said AI's position in the system has changed, moving from an add-on module to the underlying architecture.

After reading it, the first thing I thought of was our department's shift schedule.

That schedule is also in Excel. In the last week of every month, the head nurse saves a copy of last month's sheet, changes the dates, and starts scheduling. She sends one version to the group chat; someone says the 15th doesn't work, so she changes it. Sends again; someone else says why am I on big night again, so she changes it again. An afternoon can see seven or eight revisions, and in the end someone is still unhappy.

I started using WorkBuddy in August, and it's been three months now. The first thing I wanted to throw at it was scheduling.

First, how I did it

The first time I was lazy — I just threw last month's sheet in and said schedule next month in this format.

The output was unusable. Dates were right, names were right, shifts were filled, but it was completely random distribution: one person on five consecutive big nights, another with zero night shifts the whole month. It didn't understand where the constraints were in this sheet; it just filled the cells.

So I changed approach. First, write the rules.

Rules — you only realize how many there are once you write them down. Our department's hard rules are these: after a big night you must rest two days; no more than two consecutive night shifts; no night shifts for anyone more than seven months pregnant; the two colleagues on breastfeeding only get day shifts and responsibility shifts. The soft rules are more numerous: those with fifteen-plus years of service get no more than four big nights a month; two people are studying for certifications, so give them weekends when possible; and there are people who can't work well together — that one can't be written into rules.

I organized the hard rules and the soft rules that could be put into words into a paragraph, about four hundred characters. I exported the staff list as CSV, twenty-three people, tagged with years of service, title, pregnancy and breastfeeding status, and who's studying for certifications. I threw both files in and said schedule November according to these rules, give me a first version to look at.

This time the output was presentable. About twenty minutes, a complete schedule came out, all hard constraints satisfied — I checked line by line, nobody worked the day after a big night, nobody had three consecutive night shifts, pregnancy and breastfeeding scheduling was all correct.

But it stumbled on the seniority weighting.

Its idea of fairness and mine are not the same thing

In the first version, everyone's big nights were distributed evenly. Twenty-three people, a total of over a hundred and ten big nights, about five per person.

This "fairness" is impeccable on paper. The problem is our department doesn't calculate it that way. For people with fifteen-plus years of service, four big nights a month is already the cap — that's a tacit understanding earned over years; newcomers get more big nights in their first two years, that's the default exchange. It flattened this tacit understanding, which amounts to taking away the senior nurses' privilege and giving it to the newcomers.

I wrote this into the rules and rescheduled. The numbers were right.

But there's another layer it can't touch. Two colleagues — put them on the same responsibility shift and something goes wrong. I can't write the specific reason, but suffice it to say that on any day they're scheduled together, someone comes to see the head nurse. There's no rule to write for this, and it shouldn't be written into any file. My approach is to let it produce the schedule first, then manually separate them afterward — about three or four cells a month.

So my conclusion is direct: WorkBuddy can compress scheduling from an afternoon of eight revisions to half an hour of three revisions, but those last three revisions can't be saved, and shouldn't be.

The three revisions are: first, check hard constraints; second, patch in the interpersonal relationships it doesn't know about; third, get past the head nurse — she wants to see the overall rhythm, like not stacking newcomers at both the start and end of the month.

One small thing: the exported CSV pasted straight back into Excel gets messed up — column widths and row heights all have to be adjusted by hand. It only takes a few minutes, but it takes a few minutes every time.

Back to that performance system article. It said the value of systematization is that every step leaves a trace, something Excel can't do. That's true, but it's talking about a different thing. That kind of system solves recording and traceability; a shift schedule solves who works which shift this month. WorkBuddy isn't a system either — it doesn't go into any database, it leaves no audit trail, it's just a tool that gets the work off your hands.

I tried having it also turn the schedule into a ledger format, with a row of records for each change. It can do it, but I'd have to manually feed it every time, which is worse than just adding a column in Excel myself. It shouldn't take on that kind of thing. Expecting WorkBuddy to be the foundation is wrong; what it's good at is the middle layer of manual work.

What's the middle layer? Taking twenty-three people's constraints, four hundred characters of rules, and last month's sheet, and kneading them into a usable new sheet. Before, it was an afternoon for me; now it's half an hour plus three rounds of revision. The time saved is enough for me to get some sleep.

Four weeks ago I started using Skill, and the first thing I did was lock down this scheduling workflow. The rule text and CSV template are fixed; each time I only change the month and personnel changes. I've revised those four hundred characters three times; the latest version adds a line telling it to separately list all cells involving seniority weighting after scheduling, so I can check them easily.

One pitfall to mention. Last week I wrote a post about WorkBuddy's settings entry layering, and at the time I thought I had it figured out — then I stumbled again on Skill. I wrote the scheduling rules into global preferences, thinking it'd be more general, but then the Skill for the drug quick-reference table got polluted too, and its output came with a bunch of night-shift terminology. Changing it to independent configuration within the Skill was the right way. Layering isn't something you explain once and get; you have to step in it yourself.

By the way, I just got started with WeCom these past few days, trying to send the finished schedule straight to the department group — less hassle than email attachments. But that's another matter; I'll talk about it after a full week.

Over three months I've done about four rounds of scheduling. The time saved is real.

But every time I finish the last revision, I still go through it myself from the top. After that sheet goes out, the people who come to me are living people, not constraint conditions. Seniority, pregnancy, certifications — these can be written down; the rest that can't be written down is the real difficulty of scheduling. The part I hand over to it to calculate, I accept; the part where it should make judgments for me — I still have to do that myself. I still haven't fully drawn that line; I can only recalibrate after each round of scheduling.