What do tutors use first in a tutor CRM?

The first jobs are rarely the 'advanced' ones. Tutors usually need schedule, student records, payment visibility, and a reliable place for lesson history before they care about fancy reporting.

What did early OBRI usage teach you?

That tutors don't buy a CRM because they want a CRM. They adopt software when schedule, payments, and lesson memory stop staying aligned across chats, calendar, and sheets.

Is a tutor CRM mostly about features?

Not really. The core value is connecting everyday jobs that tutors already do manually: who teaches when, what happened last lesson, and who still owes money.

Who is OBRI best for?

Independent tutors with a growing roster who want one system for students, scheduling, homework, and payment tracking without agency-level complexity.

How We're Building a CRM for Tutors and What Real Usage Taught Us

In short: Building a CRM for tutors taught me that tutors do not start with "I want software." They start with friction: reschedules that break payment tracking, lesson notes buried in chat, and Sunday-night admin that grows faster than the student list. The first version of a tutor CRM only works when it removes that friction before it asks people to adopt a whole new system.

I build OBRI, and one of the most useful things about building for tutors is that the category is practical. People do not reward buzzwords for long. They reward anything that saves a real hour, prevents a real mistake, or keeps one more parent message from turning into a search across five tabs.

That changes how you think about product and content.

What did we assume tutors wanted first?

At the start, it is easy to imagine that "software for tutors" means dashboards, automation, exports, or a long checklist.

What we kept seeing instead was simpler:

Who am I teaching this week?
Who still owes me money?
What happened in the last lesson?
What homework is still open?

That sounds obvious now, but it matters. A lot of tools are built from the top down: reports first, admin structure first, agency workflows first. Independent tutors usually feel the pain from the bottom up. They do not wake up wanting analytics. They wake up wanting their schedule, payments, and lesson memory to stop disagreeing.

What do tutors actually use first?

The early usage pattern is not "explore every feature." It is selective:

they create or check a student record;
they look at the lesson schedule;
they verify payment status;
they return to lesson history or homework only when the week gets busy.

That matches what we now say more directly across the site: a tutor CRM is not magic. It is one place for recurring lessons, student context, and admin that used to live in disconnected tools.

This is also why pages like Why tutors don't actually need a CRM matter. The honest framing is stronger than pretending every tutor needs a platform from day one.

What did we get wrong in the mental model?

One mistake is assuming that tutors choose software the way companies choose software.

Companies often shop by feature matrix. Tutors often shop by threshold pain:

the spreadsheet still works, until it drifts;
Google Calendar is fine, until make-ups and money diverge;
chat is convenient, until lesson context disappears in scrollback.

That means product copy and product design both have to respect the stage someone is in. If you oversell complexity to a tutor with three students, you lose trust. If you under-solve the integration problem for a tutor with twenty students, you lose usefulness.

What does real usage say about the "first jobs"?

The safest thing I can say from our current setup is not a fake survey number. It is a workflow truth:

tutors adopt systems in the order their admin breaks.

Usually that order looks like this:

schedule starts drifting;
payment visibility becomes inconsistent;
lesson notes and homework become hard to find fast;
parent or student self-serve becomes valuable only after the first three hurt.

That is why our strongest educational content tends to work when it explains the operational problem first:

The product exists on the other side of those problems. It is not the opening line.

Why does this matter for how we write and build?

Because content and product should describe the same truth.

If the product is built for independent tutors, the content should sound like someone who understands independent tutor work:

not "workflow orchestration";
but "who paid, what moved, what was assigned."

If the product is built around recurring lessons and student context, then the articles should answer those practical questions first. That is also why founder-style pages are useful for AI search: they can hold product truth, trade-offs, and first-hand reasoning in one place.

What are we seeing in the current funnel?

The strongest safe insight is this:

new users are arriving from a mix of Direct, ChatGPT, and Google;
the homepage is still the main landing surface for signups;
search visibility exists, but a lot of search traffic is still shallow or early;
product interest is real before checkout is real.

That is not yet a grand SaaS story. It is a practical one. People are discovering the product, testing the fit, and using the site as a decision aid before a payment machine is fully formed.

For a founder, that changes what you optimize:

clearer positioning before more features;
honest educational pages before louder sales copy;
fewer vague promises, more operational clarity.

What has building for tutors changed in our product decisions?

A few things became clearer over time:

1. "All-in-one" only matters if the first three jobs are connected

Many tutors can tolerate missing exports or advanced automations. They cannot tolerate schedule, money, and lesson context splitting apart every week.

2. Browser-first is not a weakness when the work is admin-heavy

Much of the value is checking, updating, and reconciling information. That is closer to operations software than to a consumer mobile habit.

3. Honest fit improves trust

Some tutors should stay on a spreadsheet longer. Some agencies need heavier systems. Saying that out loud improves the chances that the right tutors trust the product when they are actually ready.

The takeaway

Building a tutor CRM taught me that the first product is not the interface. It is the model of the tutor's week: recurring lessons, exceptions, payment state, and what happened with each student.

The first content lesson was the same as the first product lesson: start with the real job. Do not lead with abstract software language. Lead with the moment a tutor says, "I can still teach like this, but I cannot keep organizing it like this."

That is the point where software becomes useful. That is also the point where honest content becomes believable.