The Weekend Our Instructor Disappeared

One of our earliest attempts to expand CPR training beyond our first location ended before the class began. We had arranged a classroom, enrolled learners and prepared an instructor. The afternoon before class, the instructor stopped responding and blocked our contact.

There was no practical way to get a replacement there in time. We canceled the class, apologized to the learners and issued refunds.

That experience changed how I understood the business. Finding someone who could teach CPR was only one part of delivering a class. The rest was an operating system: preparation, clear responsibilities, support and a workable response when the plan changed.

This is an account of an early stage in ALLCPR’s development and the work that followed. The network’s later scale is recorded separately, with dates and definitions, on Bio & Facts.

The work behind a class

As we expanded, other last-minute cancellations and absences made the problem harder to treat as an isolated event. A class depended on several commitments coming together: the venue, the instructor, the equipment, the learners and the team supporting them.

By the time a learner arrived at a locked room or found no instructor, the disruption had already happened. Some had rearranged their work schedules or traveled a long distance. A refund addressed the payment, but it did not give them back the time.

I began to think about reliability as something the organization had to support throughout that sequence, rather than something it could assume from an instructor’s qualifications alone.

Why penalties were not enough

Our first responses included financial penalties and deposits. I expected the consequences to make commitments more reliable. In practice, these measures were difficult to enforce, created friction and did not solve the immediate problem of a class that could no longer run.

A canceled class still needed a response. Learners still needed information, and the team still needed to decide whether a replacement, rescheduling or a refund was possible.

The question became more useful when I changed it from “What consequence should follow a failure?” to “What must be in place to make delivery more dependable—and to respond when it is not?”

Selection, expectations and support

We changed how we assessed readiness. In that stage of expansion, we placed greater weight on actual teaching experience and access to the equipment needed for a class. That did not eliminate exceptions. It gave the operating team a more practical starting point than qualifications on paper alone.

Attendance was also only one part of readiness. Instructors needed to understand the requirements of the particular course they were delivering. Experience with one training program did not automatically mean familiarity with another program’s teaching format.

With the team, I worked on more structured guidance: a centralized resource site, clearer explanations of the transition between programs, and follow-up conversations about recurring questions. The aim was to make the expected work easier to understand and carry out.

We also made reliable work more visible. Recognition, feedback and ongoing support became part of the relationship, rather than limiting communication to the moments when something went wrong.

Reliability runs in both directions

Instructor support included how we handled payment. Our early process was not clear or predictable enough. From inside the office, that could look like an administrative issue. For an instructor, it affected confidence in the organization.

I pushed to improve the calculation and checking of class hours, clarify the payment schedule and move toward a biweekly cycle. Later tools and automation supported parts of that process. The work required coordination across the people maintaining records and the people handling payments.

The lesson for me was that the organization’s own operating habits matter. Clear expectations are more useful when accompanied by dependable information, timely follow-up and a process people can understand.

A response when the plan changes

No process removes every emergency. The team still needs to know what to do when an instructor cannot attend or a class arrangement changes.

We developed a more structured response: assess whether a substitute is available, establish what can actually happen, and communicate with affected learners. Timing matters. Finding out before traveling to a class is different from finding out after arriving.

Software and alerting can help bring a problem to someone’s attention. They do not, by themselves, resolve it. People still need to confirm the situation, make the decision and follow through with the learner. That distinction remains important as we add automation.

What I carry forward

My role was to recognize the operating problem, push changes in the workflow and coordinate with the people implementing them. The instructors, support staff, managers and technical team all contributed to the work.

The canceled class taught me to look at the connections around an event. Was the instructor prepared? Were responsibilities clear? Could the team see a problem early enough to act? Did a learner receive a useful response?

Those questions continue to shape how I approach distributed training. Reliability is an ongoing operating responsibility, supported by selection, guidance, visibility and response. It cannot be settled once through a contract or a piece of software.