Features
Everything below is live in the product today. Roadmap work sits in its own section under its own heading, so nothing comes as a surprise in the demo.
Group classes and one-to-one sessions are built on the same calendar, and instructor clashes are visible on it.
They are two different booking types but they live on one calendar. Building them on separate screens meant chasing clashes by eye.
The template capacity drives the weekly pattern; a single session can carry a different number. Left blank, it inherits the template.
A booking is session by session. Booking today never quietly consumes next week.
When a class fills up, the member joins the queue. When a cancellation lands, the next member is promoted into the class — the queue is not moved by hand.
The window is genuinely enforced: cancel outside it and the entitlement is consumed, cancel inside it and the entitlement returns. This is not a written policy — the system applies it.
Repeating (series) bookings are deliberately absent; the reason is in the scope section below.
Entitlements are always counted: a package is set up as "N sessions, valid for M days". There is no open-ended access.
A member out of group sessions cannot join a class on private entitlements, and the reverse does not work either. Merging the pools would let a member consume something other than what they paid for.
The expiry date moves out by the number of frozen days. Unfreeze early and the unused days come back. The annual quota, and which packages can be frozen at all, is the studio’s decision.
The remaining count is the last line of a ledger. Every movement is recorded with who made it, why, and the resulting balance — including the opening entry written during onboarding.
Marking attendance creates the entitlement movement: mark a member present and the entitlement is consumed; mark them absent and the entitlement is kept or consumed according to the rule. Nobody counts remaining sessions by hand at month end.
An unmarked attendee is a third state and looks like one — it is never silently treated as present.
Price lives only on the PACKAGE and the class package; every sales line is a package. Services and appointment types do not carry their own price.
One line carries both the money and the entitlement, so "what did this member pay" and "how many sessions do they have left" are read from the same source.
Motice records the payment; it does not process it. Online card collection is in the scope section.
Commission is defined as a fixed amount or a percentage, and it accrues the moment the entitlement is consumed — it does not wait for month end. The monthly breakdown is read per instructor.
Calculation and breakdown are live today. Closing the period and paying the instructor through Motice, along with payroll, is on the roadmap.
Members book, cancel and check their remaining sessions themselves. The phone stops ringing for "is there a spot" and "how many sessions do I have left".
No app-store download is needed; members come in through a portal invitation. iOS and Android apps are on the roadmap.
There are four fixed system roles: business admin, front desk, instructor and finance. Individual permissions are assigned with an audit record.
An instructor sees only their own schedule and the attendee list for their own class. They cannot reach the admin panel, payment records, or another instructor’s schedule.
Each studio’s data is separated with PostgreSQL row-level security. Isolation is not left to a filter in application code — a coding mistake cannot open the neighbouring studio’s data.
Every sensitive change is recorded with who made it, when, and the value before and after. "Who changed this payment record" is a query, not a guess.
When the Motice support team signs into your account, that lands in the same ledger. A record like this is the only thing that shows a vendor is not quietly walking in.
Sales, member, instructor and booking reports. Utilisation is read per CLASS and per INSTRUCTOR.
Sales and payment records come out of a report; there are no file versions circulating on three phones to reconcile.
There is no report by hour of day — see the scope section.
This section is here on purpose. These are things the product does not do today — some are planned, some are deliberate decisions.
Planned, not live today. You can ask about timing in the demo.
These are decisions, not gaps. An absence with a reason beats a silent one.
The product has no capability in these areas; if you use another tool for them, it stays there.
This list moves with the product; the published version always matches the list in /en/llms.txt.
The list above says what Motice does; the pages below set it beside what other vendors publish about themselves. Every line’s source and the date it was read sit at the foot of those pages.
Each comparison also states where the other product is stronger — a table that comes out entirely in our favour makes a reader question the table.
Every point above is shown on a live screen in the demo. We walk through it with your class types and your package setup.
Request a demo