What we learned from 240 onboarding calls

We do onboarding calls differently than most SaaS companies.

There is no pre-recorded walkthrough. No "getting started" checklist that sends automated follow-up emails at day three, day seven, and day fourteen. Every team that joins Mediora gets a live call — sometimes two — with someone who has done this before. We do this partly because we think it produces better outcomes, and partly because we are selfish about what we learn in the process.

After 240 of these calls, the patterns are clear enough that we have started designing around them rather than just noting them.

Pattern one: the spreadsheet is never just a spreadsheet

Every team that moves to Mediora from spreadsheets tells us the same thing in the first five minutes: "our spreadsheet is pretty simple." It is never simple. By the end of the first call we have usually found three tabs, two owners, one person who hasn't been told a new system is coming, and a column that only one person knows how to interpret.

This is not a criticism. Spreadsheets that serve operational teams for years become load-bearing in ways their creators didn't intend. They accumulate logic. They develop a grammar that lives partly in the cells and partly in the head of whoever built them.

The implication for onboarding is that data migration is never purely technical. It is also an act of translation — from implicit logic to explicit structure. We used to treat it as the former. We now treat it as both, and we added an extra session to the process specifically for surfacing the logic before touching the data.

Pattern two: the manager adopts first, the technicians adopt last — and that's backwards

The instinct of most operations managers is to set the system up themselves before rolling it out to the team. Get it right first, then hand it over. This is a reasonable instinct and it consistently produces worse outcomes than the alternative.

Teams where the manager onboards alone first, then introduces Mediora to technicians as a finished thing, have lower adoption rates at ninety days than teams where at least one technician is in the room from the start. The reason is straightforward: technicians who watch the system being configured have opinions about it. Those opinions improve the configuration and — more importantly — give the technician a stake in how things are set up.

We now ask, on every onboarding call, whether there is a senior technician who could join the second session. Most managers are initially reluctant. Almost all of them, in retrospect, say it was the right call.

Pattern three: the first week is about trust, not training

We used to structure onboarding around features. Here is the device record. Here is the scheduling module. Here is how you log a job. It was logical and it was wrong.

The question a technician is actually asking in week one is not "how does this work" — it is "can I trust this." Can I trust that the record I log at 7am in a hospital basement will be there when I look for it at 3pm from a different site. Can I trust that if I make a mistake it won't cascade into something I can't fix. Can I trust that this is faster than the thing I was doing before.

Features don't answer those questions. Repetition does. We restructured the first week of onboarding around three or four core actions — log a job, update a device record, check a colleague's schedule — done repeatedly until they feel boring. Once they feel boring, the trust question is answered. Then we introduce the rest.

Pattern four: someone always misses the call

In 240 onboarding sessions, we have yet to run one where the full team was present. There is always a technician on a site visit. A coordinator covering a sick colleague. A manager pulled into something urgent at the last minute.

For the first hundred calls we treated this as an inconvenience. Then we started treating it as a design constraint.

Every piece of onboarding material we produce now assumes that at least one relevant person won't see it live. Every configuration decision made in a call is logged in a shared document that non-attendees can read and comment on. Every call ends with a two-minute summary that the manager can forward without editing.

Onboarding a team is not a single event. It is a rolling process with a ragged edge. Designing for the ragged edge changed how quickly teams reached full adoption.

Pattern five: the hardest conversation is about what to stop doing

Most onboarding conversations focus on what Mediora replaces. The harder conversation — the one that determines whether the transition actually sticks — is about what behaviours to stop.

Stop sending the weekly service summary over email and let the dashboard do it. Stop maintaining the parts spreadsheet alongside the system and let the system be the record. Stop taking photos of completed job sheets as a backup and trust the sync.

These are not software questions. They are habit questions. And habits are harder to change than workflows because they are attached to things people have learned to rely on — often because a previous system let them down.

We added what we call a "stop list" to every onboarding process: a short written agreement about which parallel habits the team commits to winding down, and over what timeline. Not immediately — immediately doesn't work — but deliberately, with a date attached.

Teams that have a stop list at onboarding are significantly more likely to be running cleanly at six months than teams that don't.

What we changed because of all of this

Six things, specifically.

We added a pre-call questionnaire that asks about the spreadsheet structure, the team composition, and who is most likely to resist the change — not to pre-judge anyone, but to know who needs the most reassurance in the first session.

We moved data migration to session two, not session one. Session one is now entirely about understanding the existing system.

We include a senior technician in at least one configuration call. Non-negotiable ask.

We restructured week one around three core actions, not a feature tour.

We produce a written summary of every call, formatted for forwarding to people who weren't there.

We close every onboarding with a stop list.

The median time to full team adoption — defined as every role using the system as the primary record — dropped from eleven weeks to six. We think there's more to find.