Bring these four things to an evaluation
- An anonymised example of this week’s timetable
- The prices and rules for two commonly sold passes
- A recent leave, make-up or refund problem
- One real user from office staff, teaching and finance
1. Turn a feature wish list into three specific problems
Ask each role to describe repetitive work, how often it occurs, who receives the handover and what an error causes. Choose three requirements for this evaluation and leave the rest on a later list.
Swipe the table sideways to see every column.
| Current problem | Task to test | Evidence of a fit |
|---|---|---|
| No follow-up after a trial class | Assign an owner, a next action and an outcome | A colleague can continue the conversation |
| Make-up classes and pass balances disagree | Record leave, make-up attendance and credit use | Every balance change has a corresponding record |
| Month-end payment reconciliation repeats work | Trace an order to payment, pass and later changes | Office staff and finance reach the same conclusion |
2. Follow one sample learner through the whole process
Let an advisor demonstrate once, then ask employees to operate the system themselves. Use sample or anonymised data and record where help is needed. Watching a workflow is different from completing it.
- Record the enquiry source, owner and trial booking, then the trial outcome.
- Set up the learner’s class and pass; check payment, validity, eligible classes and bonus-credit rules.
- Assign a teacher and room, make a booking, mark attendance and check one credit deduction.
- Find the attendance, pass and payment history from the learner record and ask finance to review it.
- Note every place that needs duplicate entry, an external spreadsheet or missing information from another role.
3. Test three situations where plans change
A normal workflow is easy to demonstrate. Exceptions expose gaps. These are suggested evaluation tasks, not a claim that every product handles them identically. Agree your own rules before testing.
- Leave and make-ups: how is the original class recorded, where is the replacement booked, and can duplicate deductions be avoided?
- Incorrect attendance: who may reverse it, are the relevant credits restored, and can staff review who made the change and why?
- Transfers or refunds: confirm what is supported, then reconcile pass changes, payment handling and action history. A success message alone is not enough.
4. Let every role check its own work
Do not limit evaluation to the owner’s dashboard. Have every role complete a real task and record whether it works now, needs configuration, needs development or is unsupported. Confirm scope and acceptance conditions for anything that needs development.
Swipe the table sideways to see every column.
| Role | What to check |
|---|---|
| Office staff | Teacher, room and learner schedules; whether colleagues can find the latest change |
| Teachers | View classes, mark attendance and add class notes on the device they actually use |
| Finance | Trace orders, payments, refunds and pass changes; distinguish period activity from current balances |
| Managers / owners | Location access, staff permissions and the definitions behind reports |
5. Confirm total cost, migration and implementation ownership
Compare providers using the same number of locations, staff roles and required services. An entry price may not describe your full setup. If prices are not public, request a written scope based on the same requirements.
- Which apps, features and services are included, and which cost extra?
- Who prepares, imports and accepts historical data? How are records that cannot be imported retained?
- Who configures classes and pass rules, and how is staff training delivered?
- What is checked before go-live, and who owns unresolved issues?
- What changes when you add locations, change a workflow or stop using the service? How are records handed back?
6. Decide from test results
Put your three essential requirements next to the observed results. Record the reviewer, date, open issue and next owner for each one. If credit, payment or access issues remain, keep the trial small and resolve them before planning a launch.
- Avoid comparing menu counts without completing the underlying work.
- Avoid an owner-only demonstration that frontline staff never try.
- Do not treat “we can customise it” as an available feature without acceptance criteria.
- Finish with a reviewable trial record and go-live conditions, not just a positive impression.
Questions from studio teams
Does a single-location studio need a complete management system?
Look at coordination and reconciliation work, not size alone. If one or two people reliably handle bookings, payments and handovers, your current approach may still fit. If each transaction must be re-entered across chats, spreadsheets and apps, test one workflow to compare.
Do we need to import every learner before evaluating software?
No. Use a small amount of sample or anonymised data to check core workflows and rules. Agree a separate scope, reconciliation method and launch date for a live-data migration.
trainingOS
Put one workflow to the test in trainingOS.
trainingOS covers enquiry follow-up, scheduling, bookings, attendance, class credits, orders, payments, refunds and role-based access. Use the 30-day assisted trial to evaluate one connected workflow with your team.
This checklist is an evaluation method, not a promise of saved time or revenue growth. Confirm special billing, cross-location rules, historical-data migration and custom requirements during the trial and implementation review.