Training Provider Course Operations Software Problems: The 6 That Eat Your Margin, and How to Avoid Them

Why does instructor allocation get scoped as a calendar?

Because the visible symptom is a clash, and a clash looks like a calendar problem. The brief gets written as stop double booking trainers, the developer builds resource booking, and the system does exactly that while the actual decision stays in the coordinator's head.

Assigning a trainer is a constraint problem, not an availability lookup. Only four of your eleven trainers hold current approved status for the accreditation you deliver under, and one of those certifications expires in March. Two are contractors on a day rate that turns a small cohort unprofitable. One lives near the Birmingham venue and one would need a flight and a hotel. One is on a closed client course that could move because that client is flexible, and one is on a public course that cannot move because seats are sold. Administrate, Arlo and accessplanit will all stop you double booking a person. What they generally do not model is the qualification matrix with expiry dates, the true cost to serve of a given trainer at a given venue, and the substitution logic that answers who can legally cover this course when the first choice calls in ill on the Sunday night.

Make the matrix a first class object. Each trainer carries qualifications with issue and expiry dates, subject competencies, day rate, home base and travel preferences. Each course template carries the qualifications it requires and the room and kit it needs. Allocation becomes a ranked suggestion with the real cost of each option shown side by side, and the system warns you in January that both your approved trainers for a given accreditation have certifications lapsing before the summer season. That one warning is worth more than the rest of the feature list.

What goes wrong when you migrate the calendar and framework balances?

Course templates, trainers, venues and customers import cleanly from Excel, which lulls everyone into treating migration as an afternoon. The two records that do not import cleanly are the ones that carry money.

Open framework balances are the first. A corporate client pre bought a pot of delegate days at a negotiated rate, and the remaining balance is tracked in a spreadsheet the account manager updates when he remembers. Those figures are almost always disputed somewhere, because a cancelled delegate, a transferred seat or a goodwill place was handled by email and never deducted. Loading them unverified means your new system starts by blocking a booking it should allow, or allowing one it should block, and either outcome destroys trust in week one.

The second is delegate identity. The same person appears across five years under a maiden name, a nickname and two employer records, and certificate history has to attach to a human rather than to a booking. Get that wrong and reissuing a lost certificate becomes a search.

Verify every open framework balance with the client before cutover, in writing, and treat that as a commercial task rather than a data task. Resolve delegate identity before loading history. Then run in parallel: load the next six months of events, keep the spreadsheet alive for two to three weeks, and have the coordinator compare them daily. That comparison is what surfaces the unwritten rules, which is the real content of this migration.

Why do the accounting and awarding body integrations break after launch?

Accounting looks like a solved problem until you look closely. Xero and Sage are different problems, and Sage 50 and Sage Intacct are different problems again. What breaks after launch is rarely the connection. It is credit notes and amendments. A delegate transfers to a later cohort, a reseller invoice is consolidated across two months, a framework drawdown is reversed. Each of those has to produce the right document in the ledger, and a system that only knows how to raise an invoice will leave your finance team correcting by hand within a fortnight.

Awarding body returns break differently. Each body has its own format, its own timetable and its own idea of what a valid record looks like, and a portal accepting a spreadsheet upload is a different piece of work from one with a proper interface. Bodies change their submission requirements on their own schedule with no notice to your developer, and the failure surfaces as a rejected return at the moment your delegates are waiting for certificates.

Ask for the named system and the named file rather than a general claim about integrations. Build returns so the output format is configuration your own staff can adjust rather than code, retain every submitted file and its response, and put a calendar reminder against each body's published requirements. Budget each additional body separately, because none of them share a format.

What happens when attendance and certification rules are not covered?

Delivery ends and the second job begins. Attendance has to be captured against the register, because a delegate who missed the second afternoon cannot be certificated under most awarding body rules. Results go to the body in its format. Certificates are generated, numbered, issued, and reissued six months later when somebody loses theirs. Continuing professional development hours need to be attributable per delegate.

Systems that treat attendance as a tick against a booking leave the compliance judgement with a trainer under time pressure at the end of a long day, and that is where certificates get issued to delegates who did not meet the hours. It is a quiet risk until an awarding body audit finds it, at which point the question is about your process rather than that one delegate.

Capture attendance in the room on a tablet, at session level rather than course level, and let the system block certification automatically when hours fall below the threshold for that qualification. Generate certificates with a verifiable reference, and give delegates self service access to their own records, which quietly removes a support burden nobody counts. This is unglamorous work and it is precisely where a custom build earns its keep, because the requirements are specific to the bodies you report to and no packaged vendor will build them for you.

Should you build custom or configure what you already own?

Configure if you deliver fewer than roughly 150 events a year, sell mainly direct, and your instructor pool is small enough that allocation is genuinely obvious. Arlo is excellent at catalogue, ecommerce, waitlists and the delegate experience. accessplanit is strong on the administrative machinery a training business needs. Administrate scales well for a conventional public and closed course mix. Buying the same thing through a build is an expensive way to arrive at a worse version of it.

Configure first even at higher volume if your reseller and framework processes have never actually been set up in the tool you already pay for. A meaningful share of the providers who ask us about building are running a modern platform with a manual process bolted alongside it because nobody finished the implementation.

Build when two or more of these hold. Instructor allocation depends on a qualification matrix with expiry dates only one person understands. Resellers or framework clients account for more than a third of revenue and reconciliation happens in a spreadsheet. You report to more than one awarding body and returns take a person more than a day a month. You operate across currencies or entities. Or you deliver practical training with vehicles, plant or lab equipment carrying their own availability and servicing rules, which is where generic resource booking stops fitting. The plain test is whether the honest answer to who decides if a course runs is a person rather than a process. If it is, you are one resignation away from a bad quarter.

How do hidden costs get into the quote?

Awarding body count is the line that hides the most. Each return is its own small integration, none share a format, and a quote showing accreditation reporting as a single deliverable has priced one body. Name them all in the first meeting and ask for a per body figure.

The second is reseller portals. Each partner wants their own branding, their own price basis and their own settlement cycle, and what looks like one portal is a configuration surface that grows with every partner. Start with two or three and add the portal once the commercial model is proven.

The third is multi entity tax treatment. Multi currency alone is manageable. Delivering through subsidiaries with different VAT treatment on training services is a genuinely different piece of accounting work, and it is invisible in a feature list.

The fourth is the discovery work of documenting rules that currently live in a coordinator's head, particularly substitution rules and the real cost of each trainer and venue combination. That is your time rather than the developer's, and it is the most common cause of schedule slip in this category.

What separates a build that works from one that fails here?

Builds that work are measured on one operational number from the first month live: how many events reached their decision window with a viability call recorded, and how many were transferred rather than cancelled late. Everything else in the system supports that. Builds that fail are measured on modules delivered, and the coordinator quietly keeps her spreadsheet because it still answers the Tuesday morning question faster.

The second differentiator is whether the coordinator was treated as the domain expert rather than as a user to be trained. The rules that matter are unwritten, and they only emerge when someone sits with her through a real allocation week. Providers who already keep a clean course template library move noticeably faster, because half that work is done.

The third is honest phasing. The calendar, allocation, booking and invoicing release ships in 10 to 16 weeks and is used on day one. Reseller and framework channels are typically four to eight weeks each afterwards. Trying to launch all three channels together is how a 14 week project becomes a 30 week one.

Finally, settle ownership before kickoff. You should own the repository, the hosting accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from any developer who hedges on that.