Motora
Franchise Operations Platform
Request
Assign
Deliver
Verify
Settle
Lesson #4821
Instructor substituted
Lesson #4822
Cancelled inside notice window
Lesson #4823
Partial session · 40 min
A connected operating platform bringing learners, instructors, franchisees, and central operations together across scheduling, service delivery, and financial workflows.
- Product Manager
- Product Research · Workflow Design · Execution · Financial Operations
- Lesson Lifecycle Management
- Service Wallet & Financial Reconciliation
Everyone agreed a lesson happened. Nobody agreed on the details.
A lesson could be booked centrally, rescheduled by phone, delivered by a substitute instructor, and settled a week later against a balance the learner didn't recognise.
Because the lifecycle wasn't recorded consistently, reconciliation became an argument: who was owed what, and for which lesson.
A franchise network is four businesses pretending to be one. The learner books a service, the instructor delivers it, the franchisee owns the local operation, and central operations owns the standard.
Motora's job was to hold one shared version of what happened, so that scheduling, delivery, and money stopped being three separate stories about the same lesson.
Follow one lesson end to end.
I traced individual lessons across every actor and every system touchpoint. The gaps were always at the edges: substitutions, no-shows, partial sessions, cancellations inside the notice window.
Instructors described the same events differently than the office did. That difference was the product problem.
One lesson lifecycle, verified at the point of delivery.
We defined a single lifecycle from request to assignment to delivery to verification, with verification happening where the service actually happened rather than back in the office.
Once verification existed as a real event, financial workflows could hang off it instead of guessing.
Wallet as a consequence, not a feature.
The service wallet was built as a ledger of lifecycle events rather than a standalone balance. Every adjustment traced back to a lesson state.
Reconciliation for franchisees and central operations then became a reading exercise rather than an investigation.
Decisions I’d defend.
Verify lessons back in the office
Verify at the point of delivery.
- Capture happens where the truth is
- Financial workflows hang off a real event
- Reconciliation stops being an argument
Ship a wallet as its own feature
Derive the wallet from lifecycle events.
- Every adjustment traces to a lesson state
- No silent corrections
- Trust across four parties
Instructors are working between sessions, often on a phone, often outdoors. Their part of the lifecycle had to be a handful of unambiguous actions, or the data would degrade and everything downstream would break.
Franchisees needed room for local scheduling reality; central needed non-negotiables around cancellation, pricing structure, and verification. We separated configuration from policy so the two could evolve independently.
Any change to a delivered lesson or a balance kept a visible trail. Trust across four parties is easier to build with an audit trail than with a clean-looking number.
Shipping reality.
We sequenced by lifecycle rather than by user type, so a thin end-to-end path worked before any one role got a full feature set.
The hardest engineering conversation was time: notice windows, time zones for central reporting, and what 'today' means for an instructor finishing a late session.
What it taught me.
Operational products succeed or fail at the point of capture. Everything else is derived.
When money depends on a workflow, the workflow needs to be boring and explicit.