If you're the one who has to report on enquiries and enrolments across more than one site, you already know the real problem isn't tracking at any single site. Each site, taken on its own, usually has something roughly workable. The problem shows up the moment you try to see all of them at once.
That's the job that tends to fall to an operations manager or registrar rather than a course coordinator, and it's a different problem from the one a single admin person at a single site deals with. It's not "did we log this enquiry." It's "can I tell you, right now, how every site is actually doing."
Why the rollup is harder than the tracking
Most multi-site training providers don't have one tracking problem. They have as many as they have sites, each slightly different, and someone has to reconcile them into a single picture.
Status doesn't mean the same thing everywhere.
One site's "following up" is another site's "quoted." A third site doesn't use a status column at all, just a colour someone remembers the meaning of. None of this is anyone doing it wrong. It's what happens when each site builds its own version of a tracker independently, with no shared definition to work from. By the time it's rolled up into a single report, half the job is translating one site's language into another's before the numbers mean anything.
The rollup only happens as often as someone does it by hand.
If getting a cross-site view means opening four spreadsheets, or waiting on four people to send their latest export, that view only exists as often as someone has time to build it. In practice, that's usually month-end, sometimes less. Which means for most of the month, nobody, including the person responsible for the numbers, actually knows how enrolments are tracking against target across the business. Problems that would be obvious in a live view (a site quietly falling behind, a course that's under-enrolling three weeks before it runs) don't surface until the monthly report catches them, if it catches them at all.
Enquiries don't respect site boundaries, even when the tracking does.
Someone enquires at one site, doesn't hear back quickly enough, and tries again at another site nearer them, or a site they found through a different search. Without a shared system, both sites work the enquiry independently, neither aware the other is doing the same. Best case, that's wasted effort. Worst case, the learner gets two different answers from two different people and loses confidence in both.
Staff moving between sites lose context, not just access.
Someone covering another site's enquiries while a colleague is on leave doesn't inherit that site's shorthand, its half-finished conversations, or the specific commitments made to specific learners. They inherit a spreadsheet, if they're lucky, and whatever wasn't written down is simply gone. When they hand it back, the receiving site has the same problem in reverse.
Comparing site performance is a research project, not a report.
Which site converts enquiries fastest. Which site has the most enquiries sitting stalled. Which site is closest to filling its next cohort and which needs a push. These are reasonable, ordinary questions for anyone managing more than one site, and in a spreadsheet-per-site setup, answering any of them means someone manually pulling numbers from every source and building the comparison from scratch, every time it's asked.
What a shared system actually fixes
None of this is really about tracking harder. It's about tracking once, in one place, with one shared definition of what each stage means.
A CRM built around a single pipeline, used the same way by every site, fixes the status problem directly. "Following up" means the same thing whether the enquiry came through the head office phone line or a regional site's web form, because it's the same system, not four versions of the same idea.
Tagging each enquiry and enrolment with its site turns "how's site B doing" from a research task into a filter. The rollup a registrar needs for a board or leadership report isn't a separate exercise anymore; it's the same live data, viewed a different way.
Because it's one shared system, an enquiry that comes in at more than one site is visible as the same enquiry, not two independent ones being worked by two people who don't know about each other. And when someone covers another site, or a role changes hands, the notes, history, and outstanding follow-ups move with the enquiry rather than living in a document that only makes sense to whoever built it.
For the reporting side specifically, sales analytics and reporting built on live pipeline data means an operations manager can see conversion rates, enquiry volume, and enrolment progress by site without waiting for month-end or chasing anyone for an export. Custom fields and tags handle the site-level segmentation without needing a separate system per location. And because it's one connected pipeline rather than four disconnected ones, cross-site duplicate enquiries and lost handovers stop being a recurring cleanup job.
What this means day to day
For the person actually responsible for this, the difference isn't dramatic on any single day. It shows up as not having to ask four people for their numbers before a leadership meeting. As being able to answer "how's enrolment tracking for the March cohort across all sites" in the moment it's asked, not the next morning. As a colleague covering another site's enquiries picking up exactly where the previous person left off, rather than starting from a blank document and a guess.
None of that requires reworking how any individual site runs its day-to-day admin. It requires everyone working from the same system instead of their own version of one, so the view from the top is the same data, not a monthly act of translation.
If enquiry visibility across sites is the specific gap, rather than tracking at any one site, that's exactly the problem a shared CRM is built to close. For the single-site version of this problem, and where manual tracking tends to break down first, see why training providers still run enquiries through a spreadsheet.
For the fuller picture of how Capsule fits a training provider's enquiry-to-enrolment process, our CRM for Training & Education Providers page covers that in more depth.
Try Capsule free for 14 days. No credit card required.
FAQs
Does this replace the training management platform we use for scheduling and delivery?
No, they solve different problems. This is about enquiry and enrolment visibility across sites, not course scheduling, eLearning delivery, or compliance tracking. If you're weighing whether you need a platform like that at all, you don't need a training management platform covers the distinction, and Capsule vs a training management system compares the two directly.
We're not ready to roll this out across every site at once, where should we start?
Start with the site that's losing the most visibility right now, or start smaller than a full CRM rollout entirely. The No-Missed-Enquiry Checklist is a free way to bring some structure to enquiry tracking before committing to a system-wide change.
Does a shared system help with anything beyond the enquiry-to-enrolment stage?
Yes. Once enquiry and enrolment records live in one place across sites, that same history makes it far easier to spot past learners worth re-approaching for a new cohort. Turn past learners into repeat business covers how that works in practice.
