All answers›Online Tutoring Platforms

What is tutoring business management software, and what does it actually need to do?

Tutoring business management software is the operational tool that runs a small tutoring company end-to-end: a shared roster of students and tutors, admin-side scheduling with the policy enforcement the operator sets once, a parent-facing portal parents actually book through, structured post-lesson feedback that gets to the family on a schedule, and messaging that keeps the business in the loop rather than each tutor and family having a separate side conversation. The seven jobs it actually has to do are student roster, teacher roster, admin and parent scheduling, policy enforcement, communication, lesson feedback, and reporting + calendar sync. Small tutoring companies converge on one of three shapes: a stitched-tools stack (Zoom + Google Sheet + Calendly + Google Drive + WhatsApp, held together by the founder — cheap, and it breaks once there are more tutors than the founder can coordinate by hand), a per-seat solo classroom (every tutor buys their own solo-tutor subscription and the business has no admin over them — weak on brand, oversight, and a shared library), and a purpose-built multi-tutor management platform where scheduling, roster, messages, feedback, and the branded classroom all live in one admin dashboard . Koala for Business is one platform in that third category: a branded classroom on your own domain, plus an admin dashboard for scheduling, students, tutors, messages, and lesson feedback, plus the option to drive Koala from your existing booking system through the /v1 API if that suits you better. This page walks through the seven jobs the software has to do, where each shape is the right pick, how Koala for Business handles each job specifically, and — as importantly — the things it deliberately doesn't do, so you know whether the shape fits before your team scopes a rollout.

The seven jobs it actually has to do

"Tutoring business management software" sounds like one product; it's actually seven workflows the operator needs to hang together, and the sharpest way to tell one vendor from another is which of the seven they treat as a first-class problem versus which they hand-wave as "you can probably use a spreadsheet":

  • Student roster. Each family added by the operator (not by the family self-serving into your business), keyed by parent email, with the children under that parent. Every student visible in your reports has a stable identifier. Students can be set inactive without being deleted (families come back), and their upcoming lessons handled cleanly when they do. You can export the whole roster to a CSV any month you want it, because your accountant will eventually ask for it.
  • Teacher roster. Each tutor added by the operator, with a Live vs Review state so a new hire's profile is reviewed before it's shown to families. A per-tutor pay-rate field the operator sees but the tutor doesn't — as a reference figure the ops team uses when reconciling hours to invoices at month end, not as a payroll system. A per-tutor availability calendar the tutor maintains, expressed in weekly slots plus one-off exceptions. A way to disable or re-enable a tutor without deleting them (leave, seasonal breaks, contract changes).
  • Admin and parent scheduling. An admin can book a lesson for a family — one-off or a weekly series — after picking the right tutor, lesson length, and student. A parent can book against the same availability from their side. Both sides see conflicts before they confirm. The tool tells the operator when a tutor is next free rather than making them scan a wall of empty slots. Recurring bookings work as one action, not "book the same slot 12 times manually."
  • Policy enforcement. Minimum booking notice, minimum cancellation notice, whether teachers can cancel, how far ahead parents can book, how far ahead teachers publish availability, grace period before a tutor counts as late, timezone, currency of record. Set them once in Settings; the platform enforces them everywhere so your operator isn't relitigating a late cancellation in a chat window every week. Policy without enforcement is a paragraph in an onboarding email that parents ignore.
  • Communication. Two shapes of conversation: business ↔ tutor and business ↔ parent family. Both shared across all your admins so nobody misses a message when the on-call admin changes. Each conversation carries state (needs action / resolved), an owner, and internal notes admins leave for each other. Broadcasts to some or all tutors when there's a policy change. Attachments when a parent needs to send an IEP or a homework photo. Direct tutor ↔ parent messaging is a deliberate no at most small tutoring companies — you're the business, not a marketplace, and every conversation that skips your admin is one that undermines your brand.
  • Lesson feedback. After every lesson the tutor writes a short structured note the family (optionally) sees. Every note has a state — Due, Overdue, Submitted, Submitted Late — so an operator can see at a glance which tutors are falling behind before a parent complains. Feedback is one of the two things the family actually experiences from the platform between lessons (the other being the parent portal), and it's what separates a company that runs to a standard from one where each tutor does their own thing.
  • Reporting + calendar sync. Schedule views the operator can filter — "Needs Attention", "teacher no-show", "student no-show", "teacher late", "Completed" — so a Monday morning ops review is a filter rather than an afternoon. Rosters and teaching time you can export when it's time to reconcile invoices and pay. Bookings and cancellations syncing to each tutor's and each parent's connected calendar so the family sees "Tuesday 4pm — Reading with Ms. Sharma" in the calendar app they already use.

Any tool that only covers three of these forces you to stitch the other four together yourself, and stitched integrations are what your operators spend their time on when they should be recruiting families and coaching tutors. The one-tool version of these seven is the point of buying a management platform in the first place.

The three shapes small tutoring companies land on

Small tutoring companies converge on one of three tool patterns for the management side. Each is a real, working shape at some size — but the seams are different, and knowing where each breaks is what stops you buying the wrong shape twice:

  • Stitched-tools stack. Each tutor on their own Zoom or Google Meet account + a shared Google Drive for lesson materials + a spreadsheet or Google Calendar for the team schedule + Calendly or Acuity or SetMore per tutor for parent bookings + WhatsApp / Signal / email for parent conversations + a separate invoicing tool. Every piece is free or nearly free; every piece is familiar; every piece is loved by somebody. The stack fails as the team grows because there is no place to see the whole business at once — the operator becomes the human integration between Zoom, the spreadsheet, five Calendly links, three WhatsApp threads, a Drive folder that only they can navigate, and an invoicing tool that has no idea whether a lesson actually happened. The hidden cost is the founder's time, spent on unpaid coordination that grows with every tutor and family you add.
  • Per-seat solo classroom. Every tutor buys their own paid seat on whatever solo-tutor classroom platform the company standardizes on. Each tutor gets a strong classroom and a competent scheduler that came with it (Koala Pro is one option in this category, alongside others; the solo-tutor scheduling explainer covers this half in detail). Every family gets a consistent lesson experience within a single tutor, and the company's tech stack finally rhymes across tutors. Where it stops scaling: there is no shared admin over tutors (you can't see the whole company's schedule or attendance in one dashboard), the branded-classroom question is unsolved (families still see the platform's name and not yours), there is no shared lesson library (Tutor A's Reading Level 3 activity has to be rebuilt from scratch by Tutor B), and each tutor's messaging with the family is their own — you have no way to review a tutor–parent conversation without asking the tutor to forward it.
  • Purpose-built multi-tutor management platform. Roster, admin scheduling, parent portal, policy settings, messaging, lesson feedback, and the branded classroom all live in one admin dashboard, with the classroom on your subdomain (or your own domain) and your logo on it. Several vendors build management software for the tutoring vertical, and they don't all cover the same jobs: some are scheduling and billing tools that expect you to bring your own classroom, others bundle the classroom in. Feature sets differ and drift, so check each vendor's current docs against the seven jobs above rather than trusting a listicle. Tradeoffs: it's a real commitment (a contract, a monthly minimum, and a launch project rather than a signup form), and you're tied to that platform's shape rather than to individual per-tutor choices. A full LMS is a different category again: it assumes graded assignments and formal cohorts rather than the 1-on-1 recurring shape most tutoring companies actually run.

Two shapes worth naming as adjacent but different, so this page doesn't over-claim which decision you're making:

  • Booking system + classroom via API. A tutoring company that already runs a booking system it likes doesn't have to swap it for a management platform — the classroom can hang off the booking system via an API instead. That's a real fourth shape and it's covered in does an online tutoring platform have an API. If your booking system is where your ops team spends its day, keep it and drive the classroom from it; don't try to replace both halves in one project.
  • CRM for the sales / marketing pipeline. "Management software" and "CRM" are different tools with a small overlap. See When you need a CRM instead below.

Where each shape is the right pick

A short decision rule that holds up in practice:

  • Stitched-tools stack is fine when you have one to three tutors, everybody's in one time zone, families found you through the founder's own network, and every tutor happens to like the same tools. If you have never had two families ask about the same weekly slot in the same hour, don't over-build.
  • Per-seat solo classroom is right when your tutors are effectively subcontractors doing their own thing under a shared brand (each of them wants their own scheduler, their own materials, their own working style), when shared branding isn't yet worth a contract, or when your business is really "a strong founder plus a few tutors who fill overflow" rather than a company with a shared standard of teaching. Cheapest way to run before you're ready to commit to a shape.
  • Purpose-built multi-tutor management platform is right when you can name at least three of the seven jobs above that are actively costing you time or losing you families. Almost always: policy enforcement (you're relitigating late cancellations in DMs), communication (parents don't know who to email when their tutor is off), and feedback (parents don't hear from tutors between lessons unless they ask). The other four (roster, scheduling, reporting, calendar sync) are usually secondary but compound once the primary three are handled.
  • Booking system + classroom via API is right when your existing booking flow is the business — families found you through it, your operators know it cold, and re-platforming both halves at once is more risk than you want. Keep the booking flow; make the classroom appear underneath it. The API path is documented at business.teachwithkoala.com/docs/api and walked through in the API explainer.
  • Full LMS (Google Classroom, Moodle, Canvas) is right when you're actually running graded cohorts with assignments and units and a curriculum — a school or an established tutoring center with formal QA. Overkill for a small tutoring company running 1-on-1 recurring slots.

How Koala for Business handles the admin side specifically

If you're evaluating Koala for Business for the third shape — Koala as the management platform — here's the shape of what your admins get, grouped by the seven jobs above. Every claim here is a Business admin dashboard feature; when your tutors log in they still get the classroom (with every Koala Pro teaching feature turned on regardless of subscription tier), and your families still get the branded classroom room, on your subdomain, with your logo:

  • Student roster. Admins register each student by name and parent email before the parent ever signs in. Only the emails you registered can access your business's parent portal — a family that finds your Student Portal link somewhere and tries to sign up unprompted is turned away, which is the design your ops team probably already wanted. Each student gets an auto-generated number (1001, 1002, …) that your admin can change to whatever scheme you already use (many companies switch to their internal student IDs on day one); the number appears wherever a teacher sees the student, including on their lesson reports. An admin can mark a student Inactive (upcoming lessons are cancelled after a warning, so you don't ghost the family), or turn off booking access (they stay on the roster but can't book new lessons — useful when a family is behind on billing you handle outside Koala). Admins can also control which teachers a given student is allowed to book with, and export the whole roster to CSV whenever their accountant asks for it.
  • Teacher roster. Admins add teachers to the business, and each teacher's profile goes through Review before it goes Live to families — so a new hire isn't accidentally on the parent portal before their bio is written. Admins can record a private per-hour or per-lesson pay rate for each teacher which the teacher can't see. Be clear on what this field is and isn't: it is a reference figure your ops team uses when reconciling teaching-time reports to your existing payroll process; it is not payroll and Koala does not calculate, run, or transmit payroll on your behalf. Teachers set their own weekly availability plus one-off unavailable times from their own Koala portal, and your admins can see and adjust it from the dashboard. The business defines the lesson lengths it offers (30 / 45 / 60 minutes, or whatever your model uses) and the break between lessons, and those apply to all your teachers so a family isn't confronted with one tutor offering 25-minute slots and another offering 55. Business teachers book through the business, not through a personal booking link, so families always experience your brand rather than a per-tutor URL that could rotate as your staff changes.
  • Admin and parent scheduling. From the schedule view, an admin picks a student, picks a lesson length from your business's own lesson types, and books one lesson or a weekly recurring series. Before confirming, the admin sees every date in the series with any conflicts marked, so a family's two-months-out booking doesn't surprise you halfway through. "Find Availability" shows when a chosen teacher is next free, so your operator isn't scanning a wall of empty cells to find a slot. Admins can override notice rules for a single booking (the lesson records that the rule was overridden, so an audit later shows who bypassed policy and when). Parents book from the Student Portal against the same availability, and they can book recurring weekly lessons themselves. Cancellations record who asked for the cancellation and why (family emergency, tutor illness, admin closing the slot), so the same lesson doesn't get re-argued a month later. Admins can also keep private notes on a lesson that the tutor and family never see — useful for "family paid two weeks late; watch the pattern" annotations your ops team keeps to themselves.
  • Policy enforcement. Settings expose the toggles your business needs to set once: minimum booking notice, student cancellation notice, teacher cancellation notice (and whether teachers can cancel at all), how far ahead students can book, how far ahead teachers set availability, a grace period before a teacher is counted as Late, your timezone and currency, whether lesson feedback is required and by when, and whether parents can see recordings at all. Every enforcement then happens inside the platform: a parent past the cancellation deadline is told to contact the business rather than being able to unilaterally cancel; a teacher inside the cancellation notice window (or at a business that doesn't let teachers cancel) goes through the admin team instead, and an admin who books inside the notice window has that override recorded on the lesson. Policy without enforcement is a paragraph in an email; here it's a rule the platform applies, and any deliberate exception is recorded rather than negotiated in DMs.
  • Communication. All your admins share one inbox. Each teacher has one conversation with the admin team; each parent family has one conversation, and a parent's message says which child it's about. Conversations carry an owner, a Needs action state, and a Mark resolved action so your on-call admin can see the queue at a glance. Admins can edit or withdraw a sent message and the other side can see that it changed — no silent revisions. Private notes and @-mentions let admins hand a thread off to a colleague without cluttering the family's view. Broadcasts go to one teacher, several teachers, or all of them for policy changes. Attachments work both ways for the inevitable homework photo, IEP, or invoice PDF. Parents and teachers do not message each other directly. That's a deliberate design choice, and it's the one your operators will thank us for the first time a tutor and a family disagree about a make-up lesson — the business stays in the loop, which means the business stays in control of the relationship. If you want a marketplace where tutors and families connect directly, this isn't the shape; if you want a business, it is.
  • Lesson feedback. After each lesson the tutor submits structured feedback that the family (optionally, per your policy) sees. Every feedback note is tracked as Due, Overdue, Submitted, or Submitted Late, so your ops lead can see on a Monday morning which tutors are behind on their write-ups without asking each one. Timely, structured feedback is one of the two things families experience from your business between lessons; leaving it unstructured is one of the fastest ways an otherwise good tutor loses a family.
  • Reporting + calendar sync. The schedule view filters by Completed, Needs Attention, teacher and student no-show, and teacher late — so a weekly ops review is a filter, not a spreadsheet export. Bookings and cancellations sync to each teacher's and each parent's connected calendar, so the family opens the calendar app they already use and sees "Tuesday 4pm — Reading with Ms. Sharma" without having to remember to check your portal. The teacher and student rosters both export to CSV whenever you need them. Notifications about lesson bookings, cancellations, feedback, and messages are in-app for admins, teachers, and parents — designed so an admin's dashboard is the single place your ops team lives during a workday.

Two Koala-specific angles worth naming, because they're the pieces most stitched-tools stacks can't cover no matter how carefully they're wired:

  • Copy Activities. The single hardest operational problem in a multi-tutor business is that lesson content and pedagogy drift across tutors — Tutor 1 teaches one way, Tutor 4 teaches another, and six months in one family has quietly churned because their new tutor's lessons feel generic. From your admin dashboard you can copy lesson activities from one teacher to another in three steps (pick the source teacher, pick the activities, pick the recipient teachers), which is how you keep a shared "how we teach at our company" library that every new hire actually teaches from rather than a Notion doc titled the same. Covered in more depth on how do you run an online tutoring business with multiple tutors?.
  • The /v1 API is there when you need it. If your business already runs a booking system that families are used to, you can keep it and drive Koala from it via the standard /v1 API instead of using the admin scheduling described above — same account, different path. That's the fourth shape from earlier. It's not either / or in one direction; it is a choice you make once about where the source of truth lives.

What Koala for Business explicitly doesn't do

Every management platform trades some features for others; the honest read on what we deliberately don't ship matters more than the feature list, because these are the pieces that will bite your operator on Day 1 of rollout if we don't name them up front:

  • No email or SMS reminders or booking confirmations. Notifications are in-app; the only email a family gets is a lesson report a teacher or admin chooses to send. If your business needs SMS or email reminders as its family-facing communication channel, that's on your side to ship — either as a job that reads bookings out of your integration with us and sends via your existing email provider, or (if your operations really run on families reading email in their inbox) as a reason to keep your existing booking system and drive Koala from it via the API. This is one of the two most common surprises B2B leads arrive with; naming it here is the fastest way to keep the rollout conversation short.
  • No parent billing, invoicing, payments, or payroll. Business accounts do not include a payments module for family invoicing, and — as above — the per-tutor pay rate is a reference figure the ops team sees, not a payroll pipeline. Your existing accounting stack stays your accounting stack; Koala gives you the teaching-time and attendance data to reconcile against it (through the schedule filters, the CSV exports, and the /v1 /teachers/teaching-time endpoint for a monthly ops pull) but does not run the money.
  • No no-show fees or penalties. No-show is an attendance label on a lesson — it tells your ops team the student didn't join — and the schedule filters make no-shows easy to spot. It is not a policy engine that charges the family or docks the tutor. Your no-show policy (fee, forfeited credit, one-free-warning) is a business decision you enforce outside Koala; the platform tells you what happened but doesn't decide the consequence.
  • No direct parent–teacher messaging. By design, as above. This isn't a coming-soon; it's a design choice that keeps your business in the middle of every family conversation. If you want a marketplace of tutors, this is not the shape.
  • No public API endpoints for scheduling, students, or messages today. The public /v1 API described in the API explainer covers lessons, teachers, sessions, and recording webhooks — the pieces most tutoring companies drive from an existing booking system. It does not expose the new admin scheduling shape, the student roster, or the messaging inbox as endpoints. If your integration needs those, either use the admin dashboard for the pieces the API doesn't cover, or scope a custom engagement (which is a separate paid piece of work, priced individually — not part of the standard Business plan). The same "standard is included, custom is separate" line covered on the API explainer applies here.
  • No claim that Koala is "the best" management software for your business. Whether it's the right pick is a function of your team size, whether you want the built-in admin path or the API-behind-your-booking-system path, whether an in-app-only notification model works for your families, and whether the classroom's teaching features are the ones your tutors actually need. Describing what we do and don't do — as above — is the honest way to help you make that call; a "we're the best" pitch would be marketing noise, and it also happens to be the exact class of claim we've committed not to publish.

When you need a CRM instead

"CRM for tutoring business" is often typed by an operator who really wants management software, and vice versa; the two words overlap in casual usage but they're different tools, and buying the wrong one hurts fast:

  • A CRM is a sales and marketing tool. Its job is the leads pipeline before somebody becomes a customer — inquiries from your contact form, follow-up sequences, first-lesson-booked conversion tracking, family-referral attribution — and the long-term relationship history after they are. Companies at the "we get more inquiries than we can respond to well" stage need one. HubSpot, Pipedrive, Salesforce, and Copper are examples of the category.
  • Management software is an operations tool. Its job is the running of the lessons that already exist — roster, scheduling, attendance, feedback, messaging with families you already teach — after the sale has happened. Koala for Business (and the other platforms in the multi-tutor management category above) sit here.
  • The overlap is real but narrow. Both categories store contact details. Both send some form of communication. Some tutoring-specific management platforms include lightweight CRM-shaped features (a leads inbox, a "first lesson booked" trigger) that are enough for a company doing most of its acquisition through referrals rather than paid ads. Some CRMs have appointment-booking add-ons that could look like management software from a distance but don't run lessons.
  • Practical rule. If your bottleneck is "getting new families in the door", start with a CRM (or with better content-and-referrals discipline before you buy a tool at all — see how to start an online tutoring business). If your bottleneck is "running the families we already have without dropping balls", start with management software. Very few small tutoring companies need both at once; those that do usually add the CRM later, once the ops half is stable.

Koala for Business is management software, not a CRM. If you have Salesforce and a booking system already, and you want the classroom underneath both, the /v1 API path is probably the shape.

Common failure modes to avoid

  • Over-specifying policy on Day 1. New operators want to set every notice window, cancellation rule, and grace period before their first tutor logs in. Start with the shortest defensible policies (24-hour cancellation, 12-hour booking notice) and tighten as you see real patterns. Over-specified policy on Day 1 becomes a stack of admin overrides on Day 30, and each override is a private negotiation your platform can't help you track.
  • Not registering parent emails first. Koala for Business's parent portal admits only emails you registered. That's the design; it means an operator has to add each family before the family can sign in. Businesses that plan to "let parents self-register" and hand-wave the invite step spend the first two weeks unblocking families instead of running lessons. Register first, share the portal link second.
  • Assuming email reminders exist. As above — notifications are in-app. If your families won't check the portal, that's a real business issue and it needs a real solution (better onboarding, a shift to families who will, or an integration that sends email from your side reading Koala data). It is not a bug you can wait for us to fix; it is a design choice you're accepting or rejecting.
  • Treating the pay-rate field as payroll. It's a reference figure, not a payroll pipeline. Whatever you use for payroll today keeps doing that job; the rate field is there so your ops team can reconcile teaching-time reports to your existing payroll without maintaining a second spreadsheet.
  • Trying to route tutor↔parent messages through the platform. The platform routes tutor↔admin and parent↔admin, deliberately. If your business model is "connect independent tutors directly to families and take a cut", management software isn't the shape you want; a marketplace platform is.
  • Not planning the classroom rollout separately from the admin rollout. The management platform and the branded classroom are one product for your admin but two experiences for tutors and families. Plan the tutor-side classroom training separately (Copy Activities, the shared library, the classroom's teaching tools) from the admin-side onboarding (roster, policies, scheduling flow). Skipping the tutor training is the fastest way to have a great admin dashboard nobody trusts because the tutors don't know how to teach on it yet.
  • Cross-jurisdiction data handling without checking your rules. A tutoring company running lessons for students in the EU or UK is handling personal data of minors — the standard local rules around consent, retention, and processing purpose apply and vary by country. Talk to a lawyer familiar with education technology in the jurisdictions you operate in; this is not a topic a page like this can conclude for you.

How to decide, in one paragraph

If you're small enough that the founder can hold the schedule in their head, keep the stitched-tools stack — you'll know when it breaks. If each tutor prefers their own tools, put each of them on a per-seat solo classroom and get everyone on the same one so at least the tech stack rhymes. If your operator's week is going on integrating tools by hand, or if you can name three of the seven jobs above that are actively costing you families, you're at the shape where a purpose-built management platform pays back — evaluate two or three (Koala for Business is one; the tutoring-vertical category has others) against the seven jobs and the specific hard lines above. If your existing booking system is where your operators already live, don't replace it — drive the classroom from it via the /v1 API. If your bottleneck is getting families in the door rather than running the ones you have, you probably want a CRM before you want management software.

If you're considering Koala for Business specifically, the honest starting point is a conversation — the setup is a real project (30-day contractual launch, branded classroom on your own domain, 24/7 live support for your tutors and families, dedicated Customer Success Manager via Slack, 100-active-hour monthly minimum) and we'd rather scope it against your actual team size and workflow than have you self-serve into the wrong plan. Apply at business.teachwithkoala.com/apply or write to koala@teachwithkoala.com with a sentence or two about your team size and where the stitched stack is currently breaking, and we'll walk through whether the fit is right before the pricing conversation.

Related answers

More answers on this topic