← Bobby Bingle

Case study — onboarding analytics

Finding why new-hire training stalled

Managers believed completion was low but had no figure to support it. Getting one meant building the record that didn't exist, then working out what the record could and couldn't establish.

This case study has been sanitized. The employer is not named, no individual is identified, and third-party platforms are described generically. No proprietary schema, data, or configuration is reproduced. The methodology and results described are accurate.

What this demonstrates Tracking-system design Airtable Operational analysis Stakeholder interviews Data quality Alerting and iteration

The problem

New hires were assigned a required custom skill track on a third-party learning platform. Managers believed completion was low, but had no reliable figure to support the concern.

Given an access account, I reviewed the 60 earlier hires who had been assigned the track and checked how many had finished it.

Three of 60 had completed the track. Five percent. The platform's records showed course completions, but not when the others stopped working, whether they had ever started, or what had interfered.

That was enough to establish the scale of the problem and nothing else. There was no usable record of work on unfinished courses, so there was no way to see where in the track people were dropping out, or when.

Tracking the next cohort

Thirteen new hires were about to onboard. I built an Airtable reporting database and a training-log procedure for that cohort, so we could follow progress from the start rather than inspect completion at the end.

I chose Airtable because its low-code tooling let me stand up the database quickly, connect an HTML form to it, and share records directly with the people responsible for onboarding.

How the database was structured

  • Learner record — one per hire, carrying the onboarding start date.
  • Assignment table — one linked record per required course, so completion was calculated against the courses that hire had actually been assigned rather than a fixed list.
  • Completions — course completions and dates pulled from the learning platform.
  • Time log — hires submitted date, course, and time spent per session through an HTML form; each submission created a linked time-log record.
  • Derived fields — total logged time by hire, most recent entry, and onboarding week calculated from the start date.
Inputs Linked records Calculated Outputs Platform completions and dates Required courses Hire and onboarding start date HTML form: session date, course, time spent Course assignment record Learner record Time-log record Assigned versus completed courses Onboarding week, total time, last entry Manager dashboard First-log and inactivity alerts Hire and manager
How a logged training session became a number a manager could act on.

I reviewed those records weekly alongside platform completions. Because hires started on different dates, I compared activity by onboarding week rather than by calendar date.

What the data showed, and what it didn't

A few of the 13 logged no training at all at the start. Managers followed up to ask whether they had opened the track, understood it was required, and knew when they were expected to work on it. I asked the onboarding coordinator and the hires' managers what instructions they had given, then compared those accounts against the onboarding message and the automated enrollment email from the platform. Some hires had been told directly that the track was required. Others had only received the automated email.

Most hires did begin. Some logged short sessions on most workdays; others worked in larger blocks with several days in between. Across the cohort, time-log entries fell off around weeks five and six.

A missing log entry did not establish that training had stopped. For hires whose logs went quiet, I checked for new course completions on the platform and asked whether they had trained without submitting the form. Some had missed entries. Most of the gaps we investigated, though, reflected little or no time on the platform. The decline in logs was largely a decline in training, not a decline in logging.

I then asked hires with gaps what had changed in their schedules and what training time they had planned, and asked their managers when project assignments and recurring meetings began and whether those had displaced training. The rise in project work around weeks five and six accounted for much of the timing. Several hires were also holding out for a large block of time to train, and other commitments kept taking those blocks.

The time logs showed when activity declined. The follow-ups established what was happening during the gaps. Neither would have been sufficient alone.

What we changed

  1. Blocked training time on calendarsManagers reserved recurring time for the track, so hires had a regular place to work on it as project load increased, rather than waiting for an opening that might never come.
  2. A recurring check-in cadenceManagers reviewed progress, asked about unfinished courses and gaps in activity, and agreed the next sessions. The check-in also gave them a place to confirm the hire understood the track was required.
  3. A manager-facing dashboard and two alert rulesIf a hire hadn't submitted a first training log by the end of their third workday, Airtable notified the hire and their manager. If a hire who had started went five workdays without another entry, it notified them again. The hire's alert linked to the logging form and asked them either to record training they'd done or to resume the track. The manager's alert showed the last recorded session and the outstanding courses, so the gap could be addressed in a check-in. A new time entry reset the inactivity count, so the same gap didn't fire a fresh alert every day.

Result

By the due date, 12 of the 13 hires had completed the full track. 92 percent.

What these numbers do and do not show

The historical 3-of-60 figure and the cohort's 12-of-13 result describe different groups under different onboarding procedures. Together they show the scale of the earlier problem and the outcome for the tracked cohort. They do not isolate the effect of blocked time, check-ins, or alerts, and I wouldn't present them as though they did.

The time logs were self-reported and sometimes incomplete. Checking them against platform completions and asking hires directly about gaps is what kept us from treating every missing entry as missed training. The dashboard identified a possible interruption. The check-in established what had actually happened and what the hire needed.