A booking request is not the same as a confirmed lesson. For a solo tutor, the useful tracker is the small place where a request becomes a decision: who is asking, what time they want, what lesson it is for, whether the package context is clear, and what reply still needs to happen.
The short answer: a booking request tracker for solo tutors should show student, requested time, lesson type, package or payment context, conflict check, reply status, and the next action. If those details are visible together, the tutor can confirm faster without relying on memory, scattered messages, or a half-updated calendar.
The tracker separates a request from a confirmation
The most useful distinction is simple: requested, waiting, offered, confirmed, rescheduled, or declined. A calendar only shows time. A request tracker shows whether that time has actually been accepted and what still needs to be checked before it becomes part of the teaching week.
That matters because tutors often receive requests through more than one channel. One student emails about Tuesday, another sends a message after a lesson, and a parent asks verbally whether Thursday might work. Without a request state, those conversations can look like availability when they are really unfinished decisions.
Booking request tracker fields
Keep the tracker small enough to use during a normal week. It is not a student file, a contract, or an accounting system. It is a working surface for deciding whether to say yes, ask a clarifying question, offer another time, or pause the request.
| Field | What it answers | Decision it supports |
|---|---|---|
| Student and contact | Who is the lesson for, and where should the reply go? | Prevents confirming the wrong person or losing the thread. |
| Requested time and duration | What slot is being requested, including timezone if relevant? | Shows whether the time is open, too tight, or already promised. |
| Lesson type | Is this regular tutoring, a trial, a consultation, exam prep, or a makeup lesson? | Helps match the request to the right preparation and length. |
| Package or payment context | Is there an active package, a pending payment, or a one-off lesson? | Keeps credits and payment status close to the scheduling decision. |
| Reply status | Has the tutor replied, offered alternatives, or confirmed the slot? | Prevents a request from sitting half-answered in a message thread. |
Worked example: Tuesday request with a nearly full package
For example, a tutor receives a Tuesday 17:00 request from an existing student. The calendar has the slot open, so the fast answer looks like yes. The tracker adds the missing context: the student has one lesson credit left, the requested lesson is ninety minutes, and the normal package lesson is sixty minutes.
That changes the reply. Instead of confirming immediately, the tutor can answer with a clear option: Tuesday 17:00 is possible for a sixty-minute lesson, or the student can buy another package before booking a longer session. The request is not blocked, but it is not ready to confirm until the lesson length and credit balance match.
A second example is a new consultation request. The requested time is free, but the student has not provided the subject, level, or goal. The tracker marks the request as waiting for context. The next action is not schedule cleanup; it is a short reply asking for the missing details before the tutor promises the slot.
Use status labels that match real tutor work
Status labels should describe the next move, not just decorate the tracker. Requested means the tutor has seen a possible lesson but has not checked it. Waiting means the tutor needs information from the student. Offered means the tutor proposed a time or alternative. Confirmed means both sides can treat the lesson as booked.
Rescheduled and declined are worth keeping too. They preserve history without turning a message thread into detective work. If a student asks why a lesson moved, the tutor can see whether the original request changed because of timing, package balance, illness, travel, or another constraint.
Keep package and payment context close
For tutors who sell lesson packages, the scheduling decision is often tied to credits. A student with five available credits is different from a student with one reserved credit and a pending payment. The tracker does not need to solve accounting, but it should make the operational question visible before the tutor confirms the next lesson.
The same applies to manual payment records. If a tutor accepts bank transfer, cash, or another offline method, the tracker can show paid, pending, or not yet recorded. That label is not tax advice and it is not a payment processor. It simply tells the tutor whether the booking request belongs in the normal confirmation flow or needs a payment-status check first.
Protect student details while tracking enough context
A request tracker should collect the minimum context needed to run the week. The UK ICO explains data minimisation as keeping personal data adequate, relevant, and limited to what is necessary, and its guidance is a useful reference point for tutors thinking about student information: ICO data minimisation guidance.
Security habits matter as well, especially when a tracker includes names, contact details, payment notes, or lesson history. The FTC gives small businesses plain guidance on reducing the amount of sensitive information they keep and protecting what remains: FTC guide to protecting personal information. A tutor who handles minors, sensitive learning needs, or local compliance questions should get qualified advice rather than treating a booking tracker as a legal policy.
Where Bookedly fits in the request flow
Bookedly is meant for the part of tutoring admin where schedule, student context, packages, payment records, and reschedules need to sit together. A simple calendar link can show available time, but it usually does not show whether a student has credits left, whether a previous request is still pending, or whether a reschedule changed the package balance.
That does not make every spreadsheet wrong. A very small tutor schedule can survive in a calendar and notes for a while. The pressure appears when the tutor has enough active students that booking requests, package balances, and replies start living in different places. At that point, a tracker earns its keep by making the next confirmation decision calmer.
After the first week, prune the tracker
The best tracker is not the one with the most fields. After one week, review which fields actually changed a decision. If tutor notes never affect confirmation, move them out of the request view. If payment status changes replies every week, keep it close. If timezone only matters for online students, show it only where it applies.
The goal is a tracker a tutor will keep using between lessons. It should answer the practical question quickly: can this request be confirmed now, does it need another reply, or is there a schedule, package, payment, or student-context reason to pause first?
