Most training reporting is built for whoever owns the programme. It aggregates — completion by department, trend over time, progress against target — which is the right view for deciding whether the programme works.
It's the wrong view for the person who can actually close a gap.
Two different questions
The programme owner asks: how are we doing, and where are the problem areas.
A team lead asks: who on my team hasn't done this, is it a problem, and what do I say to them.
An 82% figure answers the first and none of the second. To act, a manager needs names, what's outstanding, and how overdue it is. Reporting that only aggregates forces every manager to either request a breakdown or ignore it — and most ignore it.
What /progress gives them
/progress returns live completion by team, exportable on demand, as per-person timestamped data rather than an aggregate.
A team lead runs it and sees their own team: who's finished, who hasn't, and what's outstanding. No configuration, no filtering an org-wide view down to their people.
Because it runs in Slack, they get it without an account on anything else and without leaving the tool they already work in. That matters more than dashboard design does — a well-built web dashboard behind a login gets visited when someone is reminded to visit it, which is the same problem as the training itself.
Why managers close gaps faster
A central function chasing individuals is slow, and the person doing it usually has no relationship with the people they're chasing. It escalates awkwardly, gets resented, and therefore gets deferred.
A manager who can see three of their eight people are behind will usually resolve it with a single message. They know whether someone is on leave, buried in a launch, or genuinely ignoring it — and they can pick the moment. That context is what makes the follow-up land as a nudge rather than an escalation.
Making completion visible at team level converts chasing into something local and quick. It's the single highest-value change for most programmes.
Look for where people stopped
Binary completion hides the useful signal.
Someone who started and stalled partway through is in a different situation from someone who never opened it. The first suggests the module is too long, unclear, or assumes something people don't have. The second suggests the assignment or delivery didn't reach them.
If several people on a team stalled at the same module, that's a content problem to escalate rather than a discipline problem to chase. Worth mentioning to whoever owns the course.
Check the population, not just the percentage
The most dangerous number is 100% completion of an incomplete population.
If a course was assigned to a list that missed someone, /progress will show everyone finished — and it'll be true of everyone assigned. The gap is invisible because those people were never counted.
Assigning to a channel or to everyone joining from a date forward keeps the population correct without maintenance. When checking coverage, confirm the people you expected are actually in the list.
Don't make it a ranking
Comparing managers on their team's completion rate produces predictable behaviour — pressure applied at bad moments, and eventually people clicking through modules to move a number.
Give each manager their own team's picture and let them handle it. Cross-team comparison belongs to the programme owner.
As you grow
Paid plans add web-based user management, which becomes useful when your organisational structure stops mapping cleanly onto Slack channels. Under a few hundred people, a channel is usually a good enough proxy for a team.
Add Poplearn to Slack — free under 20 seats, installs in about a minute.
