When a studio needs more than an embedded booking calendar
An embedded calendar can be enough when the booking service behind it supports your studio’s rules and gives the owner usable records. Consider a change when a required step falls outside that flow. First write down the rules, then compare how an existing tool, a connection or custom work would handle them.
An embed describes where the interface appears. It does not, by itself, tell you which ticket, payment or booking rules the service supports.
Write the rules before choosing the tool
Start with the decisions you make for a real class booking. The table is an illustrative requirements checklist, not a claim that every studio needs every feature. Mark what is essential, what is optional and what an owner can reasonably handle manually.
On a narrow screen, scroll the table sideways to read both columns.
| Requirement | What should the tool demonstrate? |
|---|---|
| Class capacity | How is a place reserved, and what happens when the session is full? |
| Pass eligibility and validity | Which classes can a pass cover, how are remaining credits shown, and what happens after expiry? |
| Purchases and visits | Can you distinguish a card or cash purchase from using an already purchased credit? |
| Changes and cancellations | What happens to the place, payment and credit when a booking changes, and who can make corrections? |
| Language and sign-in | Can a student understand the path and keep their chosen session through account access? |
| Owner records | Can the owner see a roster, attendance and payment status, including cash still due or received? |
Make cancellation and correction rules explicit
Confirm the studio’s policy before configuring it. Ask how a refund, returned credit or owner adjustment appears in the records. A cancellation and a refund can be different actions; the tool should make their effects understandable.
Compare four ways to meet those rules
- Use a hosted tool as supplied. If its standard journey fits, a booking link may be sufficient. Check the student path and owner records together.
- Configure and embed a suitable tool. Put a supported interface on your website and configure the available rules. Check where students go next, including sign-in and payment.
- Connect suitable tools. When separate tools each do their part well, investigate a supported connection. Define which record controls each decision and who resolves failed transfers.
- Build a focused custom layer. Consider this when a specific essential rule remains unmet. Define the missing behavior and continuing support before committing to development.
These approaches can overlap. Configuration may solve the problem; an embed alone may leave it unresolved. Ask for a demonstration against your requirements rather than choosing by the appearance of the calendar.
What Migiwa’s booking flow illustrates
For Migiwa Yoga Space, the previous booking service already handled card payments. Cash and paper ticket books sat outside that flow. The useful question was how the studio’s booking and owner records should work together.
The delivered Japanese and English paths keep a selected session in view through sign-in. Students can see ticket credits, validity and eligible classes, with ticket, card and cash choices in the booking flow. Buying a ticket book and using a credit remain distinct events. The owner has a calendar, rosters, attendance, payment records and cash logging.
Those are examples of one studio’s requirements. They do not establish that your studio needs custom software. The linked case labels its screen dates and illustrative availability; signed-in ticket and owner screens use seeded demo data.
Prove one complete booking journey
Ask a provider or project team to walk through a representative booking using test data: choose a session, sign in, apply an eligible payment or pass, receive confirmation, then find the matching owner record. Check what the student sees when the session is full or the pass is ineligible.
Include an owner correction or cancellation under your confirmed rules. Write down which steps work, which require a workaround and who performs it. This gives you a concrete way to compare options and agree what a project must deliver.
Name who supports the result
Before accepting a proposal, identify who owns the accounts and data, changes class or pass rules, handles failed connections and provides support. Ask how records can be exported, what backups cover, and how recovery would be handled. Clarify which ongoing fees and changes belong to which agreement.
Separate project and continuing costs
Ask which subscriptions, payment fees, hosting, maintenance and future changes apply to the proposed approach. Confirm current terms with the relevant provider. Our guide to the responsibilities behind a website quote covers the broader scope comparison; a systems project needs its own agreed scope and fee.
Bring your existing tools and a short rule list
If the wider handoff is unclear, start with our guide to website and workflow changes. For a booking discussion, bring the tools you use, one journey that works and one that gets stuck, plus the rules the owner needs to enforce.
We can help plan booking and business systems around those requirements. Tell us where your current booking flow gets stuck.