← Selected work

02 / Software & operating decisions

A schedule is part of a larger system.

For a distributed training network, publishing a class is one step in a longer chain. The class, its instructor, its learners and the team supporting them need a shared operating picture.

My role
Workflow design & technical direction
Status
In use · further automation in development
Account updated
October 2026

The operating problem

A scheduled class connects several kinds of work: a venue and instructor must be available, learners need accurate instructions, and support staff need to know what is happening when a question or exception arrives.

As the network expanded, adding people to each task was not enough. The information and the handoffs between those tasks also had to improve.

My role and the team’s work

My engineering background informs how I approach this problem. I work with the operations and technical teams to define the workflows, identify the information needed for decisions and improve the tools that support those workflows.

The technical team implements software; operating teams use it in the daily work. I help connect their needs and set priorities for the next improvement.

From information to action

Class listings and learner records provide a shared reference for scheduling and support. People still make confirmations and handle exceptions. Software is useful when it makes those decisions easier to carry out and follow through.

At the management level, operating records inform decisions about class frequency. We began with manual review of site income and costs, then introduced tools to improve the information used in that review. Further pricing automation remains in development.

What I am improving

The aim is a connected workflow from a class being offered to its delivery and completion records. Different parts of that workflow have different levels of automation; a tool being developed is not the same as a process already in daily use.

My continuing work is to make the information more usable, keep responsibility for exceptions clear and turn recurring support needs into better instructions and software requirements.

A first-person account of my work with the ALLCPR team. The diagram is illustrative. Network figures and source types are listed separately.