Welcome to Micali.online

User roles

Every person who interacts with Micali.online falls into one of these roles. Roles control what someone can see, edit, and approve.

What each role can do

Account

An account represents a company or organisation that owns the booking setup — the salon, the studio, the clinic. Each account has its own public subdomain (for example yourname.micali.online) where visitors land to make a booking.

An account holds all the pieces a visitor interacts with: the memberships they can buy, the services and procedures they can book, the events they can sign up for, and the forms they fill in along the way.

Where replies go

Set a reply-to address on the account and every message Micali.online sends on your behalf carries it, so a visitor who simply hits reply reaches the inbox you actually read. Leave it empty and replies go back to whatever address the mail was sent from. It is one setting for all your templates, not something to repeat on each one.

Colours

There are 28 colour themes. An account picks one for everybody, and any individual can override it for themselves — your own choice wins over the account’s, and the account’s over the standard one. It changes the app you and your team work in; it does not restyle your public booking page.

Events

An event is a time slot — or a series of time slots — that visitors can sign up for. Use events for classes, group sessions, workshops, performances and any other reservation that is tied to a fixed start time.

Template events vs. classic events

Events come in two flavours:

• Template event — a reusable blueprint. Templates are never shown to visitors; they exist so you can spin up many real events with the same settings (capacity, form, messages, etc.) without re-entering everything.
• Classic event — a real, bookable event. A classic event can be created from scratch or linked to a template, in which case it inherits the template’s configuration.

Key settings to know

• Capacity — how many visitors can join one slot, and whether each visitor can bring “friends” (extra entities). Set minimum and maximum participants. Capacity is counted in seats, not bookings: one visitor bringing two friends takes three of them.
• Signup deadline — the latest moment a visitor can book. If left empty, bookings stay open until the event starts.
• Auto-confirmation — whether reservations are accepted instantly or wait for admin approval.
• Allowed memberships — restrict who can book by limiting the event to specific memberships. If you leave this empty, anyone can book.
• Waiting list — when the event is full, new visitors can be placed on a waiting list and notified automatically when a slot opens up.
• Messages — pick which message templates are sent for booking confirmation, payment reminders, cancellations, attendance reminders, and waiting-list updates. Each event has its own slot for every purpose, so you can mix and match templates per event.
• Responsible person — the team member who owns the event. They are the one Micali.online writes to when something needs attention, they are who %responsible_person% resolves to in your messages, and they are pre-selected to handle conversations about it. An individual date can name someone else, which is how you cover a colleague’s week without touching the event itself.
• Attachments — files that travel with the event, up to 8 MB each. They are stored exactly as uploaded: nothing is resized or cropped, so a floor plan or a scanned form stays readable.

Services & procedures

Services are for one-to-one bookings where the visitor picks a time that works for them. Think of a hair salon, a private lesson, a consultation, or a treatment.

How services and procedures relate

• A service is the container — the offering as a whole (for example, “Hair Salon Downtown”). It has a name, description, location, address and timezone.
• A procedure is one specific thing you can book inside that service (for example, “Haircut — 30 minutes”, “Colouring — 90 minutes”). A service can have many procedures.
• Availability is the calendar of time windows when visitors can choose to book. You set these per service.
• Slot spacing decides how often a booking can start inside those windows — every 5, 10, 15, 20, 30, 60 or 120 minutes, 15 by default. It is one setting for the whole service: what a visitor is offered and what you can book them into are the same grid, so nothing can be booked by you that they could not have booked themselves.

On the public page, a visitor first picks a service, then a procedure, then an open time slot — and finally fills in any required form.

Automated messages

Each procedure can be wired to four message templates — one for the moment a booking is created, one for confirmation, one for denial, and a reminder before the appointment. Choose the templates per procedure so different services can speak in different tones.

Memberships

A membership is a pre-paid plan that a visitor purchases — a punch card, a monthly subscription, a season pass. Use memberships to bill in advance and to control who is allowed to book certain events.

What a membership defines

• Price & currency — what the visitor pays.
• Usage limits — maximum number of uses and/or maximum duration in days. Leave a limit empty, or set it to 0, and it counts as unlimited.
• Availability window — when the membership can be purchased (available_from and optional available_to).

How memberships gate events

By itself, a membership is just a product visitors can buy. To use it as a gate, link it to one or more events as an allowed membership. After that, only visitors holding that membership can book the event.

By default a credit is only spent once someone confirms the visitor actually turned up — the seat waits on the present switch in the visitor list. Two settings can waive that, at two different levels: the plan can say this membership always consumes a credit, and an individual event can say this event consumes a credit even without attendance. Either one on its own is enough.

So a no-show costs the visitor a credit when the plan or the event says it should, and costs nothing when neither does — in which case the credit simply sits there until a manager marks the visitor present.

Following one visitor’s membership

Open a visitor’s membership and you get the list of every booking that has spent a credit from it, with the date each one was counted. When someone asks why they have three visits left instead of four, that list is the answer.

You can also change the allowance for that one person without touching the plan everyone else is on — give a replacement class after a cancellation, or correct a miscount. Set their starting number, or add and subtract from it as you go; each change is recorded with who made it, so an adjusted balance can always be explained later.

How a membership gets used

When a visitor with a valid membership books something the membership covers, it is applied for them by default — they do not have to remember to pick it, and you do not have to attach it afterwards. Applying it is not the same as spending it: the credit is reserved at that moment and only counted once attendance is settled, by the rules described above.

Automated membership messages

Memberships can trigger four message templates:

• After each usage — confirm that a credit was spent and how many remain.
• Before the end date — a heads-up a configurable number of days before the membership expires.
• On expiry — sent when the membership ends.
• Low remaining uses — sent when the visitor’s remaining credits drop below a threshold you set.

Forms

A form is the set of questions a visitor answers while booking. Build it once and attach it wherever you need the answers — an event, a service, a membership, or each individual participant on a reservation.

What you can ask

Each field has a label, a type and an internal name. The available types are:

Text and long text, number, choice (radio buttons or a dropdown), and date, time or date & time.

Forms for each participant

When a booking can include companions, an event can ask for the details of every participant rather than just the person booking. That form must contain a field named name — it is what identifies each participant in your lists.

Returning visitors don’t retype

When someone who has answered a form before books again, their last answers to that same form are filled in for them. It is matched on the form, not on where they answered it — so two events sharing one form pre-fill from each other, and the most recent answer always wins.

An old answer is only reused if it still fits the field as it is defined today. A field that has since been removed or renamed, a choice that is no longer on the list, a number now out of range — all start empty instead. Carrying such a value silently would be worse than a blank: the visitor would see nothing in the box while the stale answer was still submitted.

Message templates

A message template is a reusable piece of text that the platform sends to visitors at the right moment — booking confirmation, payment reminder, attendance reminder, expiry warning, and so on. Define a template once at the account level and reference it from every event, service procedure or membership that should use it.

One template, three channels

Each template has slots for an email version (subject + body), an SMS version (subject + body) and a push notification (title + body). Fill in one, two or all three — at least one of them must be present when you save.

What you leave blank is simply not used:

• If the email body is empty, no email is sent when this template is triggered.
• If the SMS body is empty, no SMS is sent when this template is triggered.
• If the push body is empty, no push notification is sent when this template is triggered.

Alongside the text, each template carries a send email and a send SMS switch, both on by default. Turning one off keeps the wording exactly as you wrote it but stops that channel going out — useful to pause SMS for a month without retyping it later. You can flip them straight from the templates list. Push has no switch: it always goes out when the template has push text, because it is the only channel that reaches a visitor who has given you neither an email address nor a phone number.

A channel also needs somewhere to land. Email is skipped for a visitor with no email address and SMS for a visitor with no phone number, no matter how the switches are set.

Placeholders you can use

Templates support simple variables that get replaced with real data at send time. You can put any of these inside subject or body, on either channel:

Placeholders that don’t apply to a particular message (for example, %event_name% in a service reminder) are simply left empty.

Where templates are used

Most of the time a template is picked up automatically from the entity that triggers the message. Here is the full list of slots.

On an event

• Booking created — sent the moment a visitor submits a reservation.
• Confirmation — sent when the reservation is confirmed (manually or automatically).
• First-time confirmation — sent instead of the usual confirmation when this is the visitor’s first booking for the event, so newcomers can get a warmer welcome than regulars.
• Payment missing — payment reminder, with one or two configurable lead times (first and second reminder, in hours before the event).
• Attendance reminder — sent a configurable number of hours before the event.
• Cancellation — sent when the visitor cancels.
• Account cancellation — sent when an admin cancels the visitor’s reservation.
• Waiting list — added — sent when the visitor is placed on the waiting list.
• Waiting list — promoted — sent when a slot opens up and the visitor is allowed to book.

On a service procedure

• Booking created — sent when the visitor submits the request.
• Confirmation — sent when the appointment is approved.
• First-time confirmation — sent instead of the usual confirmation when this is the visitor’s first booking for the service.
• Denial — sent when the request is rejected.
• Reminder — sent before the appointment.

On a membership

• After each usage — sent every time a credit is spent.
• Before end date — sent a configurable number of days before the membership expires.
• On expiry — sent when the membership reaches its end date.
• Low remaining uses — sent when the number of remaining credits falls below the threshold you set.

AI

Micali.online can answer your questions about the app, help you write, and generate the messages your visitors receive. All of it is optional and none of it sends anything to a visitor without you seeing it first.

Ask AI

An assistant inside the app that knows both how Micali.online works and what is in your own account, so you can ask “how do I stop this event appearing publicly?” or “which of my memberships expire this month?” and get an answer about your setup. The conversation is private to your account and kept for seven days.

Which AI does the work

A root admin picks the connection under AI in the account settings. There are two ways to run it:

• Your own key — paste an API key from ChatGPT or Gemini. You pay your provider directly, and there is no charge from Micali.online for it.
• Built in — use Micali.online’s own connection with nothing to set up.

A key you paste is stored write-only: the app will show you a masked preview and can reveal it back to you, but it is never handed out through the API. You can test the connection before saving and see how much you have used.

Writing assistant

Next to most longer text boxes — an event or service description, your business description, a chat reply to a customer — sit two buttons. Polish improves what you have already written; Generate writes a first draft from a short brief. Both show the result in a dialog for you to accept or reject, so nothing is ever silently overwritten.

AI-written visitor messages

A message template can carry a prompt instead of fixed wording, on any of its channels. The text is then written fresh at send time from the prompt plus that booking’s details, so every visitor gets something specific rather than one sentence with their name slotted in.

Keep the static text filled in as well. It is the fallback: if generation fails, or the account has no AI connection, the static wording is sent instead and the visitor never notices.

Public vs. Active — what each flag means

Events, services and memberships share two on/off switches. They look similar but they answer two different questions.

Combinations and what they mean

Webhooks

Webhooks let Micali.online notify your own systems the moment something happens inside an account — a new visitor, a booking, a membership payment. Configure one or more listener URLs per account, pick the events you care about, and Micali.online posts a JSON payload to each URL whenever they fire. Perfect for syncing bookings into a CRM, triggering downstream automations, or building dashboards on top of your reservation data.

Who can configure them

Only root admins can create, edit and delete webhook listeners. Admins and team members cannot see or change them. Webhooks live alongside the other integrations — open Connectors → Webhooks to manage them.

Events you can listen to

Each listener is bound to a single event type. Add several listeners — even pointing at the same URL — to receive more than one event type. The catalog of currently emitted events is:

• visitor.created — a new visitor signed up in the account.
• visitor.updated — an existing visitor profile was updated.
• event_booking.created — a visitor booked an event slot.
• event_booking.confirmed — an event booking was confirmed (manually or automatically).
• event_booking.cancelled — an event booking was cancelled.
• service_booking.created — a visitor booked a service slot.
• service_booking.confirmed — a service booking was confirmed.
• service_booking.cancelled — a service booking was cancelled.
• membership.assigned — a membership was assigned to a visitor.
• membership.paid — a visitor membership was marked as paid.
• membership.ended — a visitor membership reached its end date.

What gets sent

Each delivery is a single HTTP POST to your URL with a JSON body. The following headers always accompany the request:

• Content-Type: application/json — the body is always JSON-encoded.
• User-Agent: micali-webhooks/1.0 — identifies the sender.
• X-Micali-Event: <event_type> — repeats the event type so you can route without parsing the body.
• Authorization — present only when you configure authentication on the listener (see below).

Payload shape

All payloads share the same envelope:

• event — the event type (same value as the X-Micali-Event header).
• occurred_at — ISO-8601 timestamp of when the trigger ran.
• resource — the kind of object inside data: event_booking, service_booking or visitor_membership.
• data — a snapshot of the resource, including its public ID, current status flags, and the visitor’s contact details (email, first and last name, phone). Event and service bookings also include the linked event or service/procedure block; membership payloads include the membership name and public ID.

Identify objects across deliveries by their public_id — that’s the stable, human-shareable identifier we use everywhere else in the platform.

Authentication

Pick an authentication scheme so your receiver can verify the request originated from Micali.online:

• None — no Authorization header is sent. Use only when your endpoint is otherwise protected (signed URL, IP allow-list, private network).
• Basic — username and password are sent as the standard Authorization: Basic ... header.
• Bearer token — the token you provide is sent as Authorization: Bearer <token>. Stored encrypted at rest and never returned by the API once saved.

Delivery and retries

Delivery is asynchronous and runs through the platform’s background job queue. If the receiver returns a non-2xx status (or the request fails outright), the job retries with exponential backoff — starting at 60 seconds, doubling each time, and capped at one hour between attempts. After ten failed attempts the delivery is marked as failed and dropped. Listeners that are disabled or deleted between the trigger and the actual delivery are silently skipped.

Getting started

The fastest way to go from an empty account to a bookable page is to let the setup interview build it for you.

The setup interview

A root admin of a new account is offered an interview that asks about the business in plain language — what you offer, whether people come in groups at a fixed time or book their own slot, how long things take, when you are open, who works with you — and then creates the whole setup in one go: services and their procedures, opening hours, events and their dates, your business name and category, your public subdomain, your address on the map, whether bookings need approving, which reminders go out, and invitations for your staff.

You do not have to finish in one sitting. Your answers are saved as you go, so closing the tab and coming back later picks up where you stopped. You can also dismiss the interview entirely and build everything by hand — it is offered once, not enforced.

What to check afterwards

The interview leaves everything switched on and ready, but two things are worth a look before you send anyone the link: open your public subdomain in a private browser window to see exactly what a visitor sees, and skim the message templates it seeded so the wording sounds like you.

If you started in a demo

The demo you can open from the website without signing up is a real, working account with a short life — it is deleted once it expires, along with anything you set up in it. Confirm your email address and it becomes an ordinary account instead, keeping everything you have already built. If you have spent an evening arranging your week in a demo, do that before you close the tab.

Signing in

Nobody at Micali.online has a password. Everyone signs in with a code sent to their email, and managers can add a faster way on top of that.

Managers

Enter your email address, and a short code arrives by email. Type it in and you are signed in for the session. If you were heading somewhere specific — a link from a notification, say — you land on that page rather than the dashboard.

The four-digit PIN

Once you are signed in you can set a PIN for the browser you are using. From then on that browser only asks for the four digits instead of the emailed code, for 30 days. It is per browser: setting a PIN on your phone does nothing for your laptop.

Three wrong guesses and the browser stops being trusted — it goes back to asking for an emailed code, and the PIN alone will not get in. The 30 days are counted from when you set it up and are not extended by using it.

Add it to your home screen

Both the manager app and your visitors’ booking page can be added to a phone’s home screen, where they open like an app. This is also what makes push notifications possible on iPhones — there, notifications only work once the page has been added to the home screen.

Visitors

Visitors sign in the same way, with a code to their email, on your own subdomain. A visitor who has never booked with you before is simply created on the spot the first time they sign in.

The dashboard

The first screen after signing in, in three views. The tabs remember which one you chose, so pick the one that matches how you work.

• Calendar — a full week laid out as a grid, with every event and service slot in place and overlapping ones side by side. You can page through weeks and make the rows taller or shorter to fit a dense day.
• Agenda — a simple list of what is coming up, one slot after another. This is the one that works best on a phone.
• Overview — summary cards: what is next, what needs confirming, recent form answers.

Working straight from the calendar

Clicking a slot in the calendar does more than open it. On a slot with room you can book a visitor into it there and then; on an empty one you can share it, open its visitor list, or remove that time entirely if you are not running it.

Managing bookings

Everything after a visitor has signed up: adding people yourself, approving them, moving them, and recording who actually turned up.

Adding someone yourself

Not every booking arrives through the public page — people phone, or catch you in person. Add them by email address: if that address is already one of your visitors it is matched to them, and if it is new the visitor is created. You can set how many seats they take, add their companions, and fill in the form answers on their behalf.

Approving and declining

If the event or procedure does not confirm automatically, new bookings wait for you. Approving one sends the confirmation message; declining sends the denial message, where the procedure has one set. A booking made by someone with no earlier booking can send a different, warmer message than the one your regulars get.

Moving a booking

Plans change, and a visitor should not have to cancel and rebook. An event booking can be moved to another date of the same event or to a different event entirely; a service booking can be moved to another slot or another procedure. Capacity at the destination is re-checked as the move happens, and the seat it frees goes to whoever is first on the waiting list.

Marking who turned up

Once a date has started, every confirmed booking asks one question: did this person come? Answering it is not just record-keeping. Present is what spends a credit from a membership, unless the plan or the event is set to count the booking regardless of attendance; Did not attend gives the seat and the credit back. Until you answer, the credit sits reserved and the visitor’s remaining count does not move.

There are several places to answer it — from a whole class in one tap to a single booking, or from the membership side:

• The bookings list. Open Visitors → Events, pick the event and look at the confirmed bookings of a past date (the reminder email links straight there). A Presence column appears as soon as the date has started — it is not there for future dates, because there is nothing to answer yet. Each row has a green tick for present and a red cross for did not attend; tap the answer that is lit to take it back. Present Did not attend
• Everyone present. The header of each date has an Everyone present button. It fills in only the bookings that have no answer yet, so anyone you already marked as absent stays absent. Everyone present
• A selection. Tick the rows you want and use Mark selected present or Mark selected absent — handy when most of the class came and a few did not.
• From your phone. On the dashboard, the Agenda view shows a small Attendance pill on every event that has started — amber with a count while answers are missing, green once everyone is answered. Tap it and a panel lists the confirmed bookings with the same present / did-not-attend buttons and an Everyone present shortcut, so you can take the register while people are still in the room.
• One booking. Open the booking from the list (the pencil icon) and use the Was present switch on its detail page, next to the visitor’s form answers and notes.
• From the membership. Open Memberships, pick the plan, then the member — the number in the usage column opens their Membership usage page. Every accepted booking waiting on attendance is listed there with a Confirm presence / Did not attend pair, and the members list shows how many of each member’s bookings are still waiting. This is the same answer as everywhere else, just grouped by member, which is the natural place when you are checking how many credits someone has left. Confirm presence Did not attend

Admins can answer for any event. A team member can answer only for the events they are responsible for — everywhere else the buttons are greyed out.

You do not have to remember. When an event has finished and bookings are still waiting on attendance, Micali.online emails whoever is responsible for that date with a link straight to the right list — and only for the bookings where confirming actually changes something.

Payment

Bookings carry a paid flag you switch yourself; Micali.online does not take the money. What it will do is chase it: an event can send a payment reminder once or twice before the date, and only to visitors who are confirmed, still unpaid, and not covered by a membership.

Taking the list elsewhere

Bookings export to a CSV file, for events and for services, so you can hand a register to whoever needs one, add up a month in a spreadsheet, or keep your own copy. It is the list as you have filtered it, not a fixed report.

Sharing your events & services

Every event, service and prepaid plan has its own public address, and so does your booking page as a whole. Hand it out as a link or print it as a QR code — whoever opens it lands straight on the page where they can book.

The address of everything you offer

Your booking page lives on your account’s subdomain — the name you chose on the Account page, followed by .micali.online. That one address is where visitors browse everything you have made public:

• https://yourname.micali.online — all upcoming events.
• https://yourname.micali.online/services — all services and their procedures.
• https://yourname.micali.online/memberships — the prepaid plans visitors can buy.

Visitors switch between these with the tabs at the top of the page, and a tab only appears when there is something public behind it. This is the address to put on your website, in your email signature or on the sign at the door — anything you publish later shows up there without the link changing.

One event, service or prepaid plan

The Events, Services and Prepaid plans lists show a row of small buttons at the right-hand end of every row. The share button is the one with three connected dots:

Clicking it opens a small window with both things you might need:

• The link — click it once to select all of it, or press Copy to put it on the clipboard. It looks like https://yourname.micali.online/events/AbCdEfGhIj.
• The QR code for that same link, with Download QR code to save it as a PNG image you can drop into a poster, a flyer or a slide.

Template events have no share button — a template is never shown to visitors. Share the real events you create from it instead.

What the visitor gets

The link opens that event, service or plan directly on your booking page, with its dates or procedures ready to pick — there is nothing to search for. It stays reachable for as long as the item is both public and active; switch either off and the link has nothing to book until you switch it back on.

Sharing a date & time

Sometimes you want to send someone a specific slot — “this Thursday at six” — instead of your whole schedule and a hope they pick correctly.

Every place you can share a single slot gives you both a link and a QR code, ready to print or send:

• On an event’s schedule, next to any upcoming date.
• On the visitors screen, where you can pick any upcoming date of an event — including one nobody has booked yet.
• On a service, where you choose the procedure, the day, and the time from the same availability your visitors see.
• On the calendar and the agenda, straight from the slot itself.

What the visitor gets

The link opens your booking page already on that exact slot, with the other dates out of the way, so there is nothing to choose and nothing to get wrong. If the slot is full they are offered the waiting list for it instead.

Your visitors

Everyone who has ever booked with you, plus anyone you have added, in one list you can search, import into and mail.

Importing a list you already have

Upload a CSV and say which column is which — Micali.online does not care about the column order or what the file calls them. Addresses already in your account are linked rather than rewritten, so importing a list that overlaps with your existing visitors will not overwrite anyone’s details.

The import runs in the background and reports what it did, so a large file does not tie up the screen. There is a ceiling of 500 newly added visitors per day, which is deliberate: it is high enough for a real customer list and low enough that a mistaken upload cannot run away with itself. Anything over the limit is reported back rather than dropped, and re-importing the same file the next day picks it up.

Mailing lists

A mailing list is a saved group of visitors you can write to again and again. Fill it by picking people by hand, or by choosing events and services and a period — everyone who booked those in the last fortnight, the last year, or ever.

Writing to them

You can mail a saved list, everyone on an event, or your whole account. Each message is sent individually, so one bad address cannot hold up the rest, and anyone without an email address is skipped — the count of those is shown before you start writing, not after you send.

The blacklist

Some people you would rather look at twice before letting in — the serial no-show, the one who books six places and brings one. Add their email address to the blacklist, with a note to yourself about why.

The list is keyed to the email address, not to the person’s record — so deleting the visitor and having them sign up again with the same address does not clear it.

Messages with visitors

A conversation is a thread between your team and one visitor. Either side can start it, and everything said stays attached to that person rather than scattered across whoever happened to answer their email.

How a thread starts

A visitor can write to you from their own booking page — about a reservation, or about nothing in particular. You can also open a thread yourself from their row in the visitors list, which is the right way to ask one person a question without turning it into an email everybody gets.

Who answers

Anyone in the account can read and reply, team members included. A conversation can be assigned to a particular person, and there is a mine filter showing what is assigned to you or what you have already replied to — so on a busy day two people are less likely to answer the same visitor twice.

Keeping the list short

Threads can be closed once they are dealt with and reopened if the visitor writes again, which keeps the list to what still needs a person.

Feedback questionnaires

Ask the people who came what they thought, automatically, once the event or appointment is behind them.

Setting one up

Write the questions, attach the questionnaire to an event or a service, and say how long after the slot ends it should go out — immediately, the next morning, a few days later, whatever suits. Give it a name for your own use; visitors never see that, only the questions.

What the visitor gets

An email with the first question in it. Answering that one opens the rest on a page of its own — with no sign-in, no password, nothing to remember. The less you ask of someone at that moment, the more answers you get back.

One per booking

Each booking is asked exactly once, and the send is recorded. Somebody who comes to your Tuesday class every week is not asked to rate it every week.

Reading the answers

Responses collect against the questionnaire, so you can read them together rather than one email at a time. You can also send yourself a test copy first and see the whole thing exactly as a visitor will.

Getting help

For questions this guide does not answer, or when something looks wrong in your account.

Opening a ticket

Admins and root admins can raise a ticket from inside the app, which is better than emailing because it arrives with your account attached — nobody has to ask you which business you are, and we can look at the actual setup you are describing.

How it goes on

A ticket is a conversation, not a form: replies from our side land in the same thread and you are notified by email, so the whole exchange stays in one place instead of fragmenting across a mail chain.

How to create an event and publish it

For root admins and admins. The goal: a visitor can land on your public page and book a slot.

1. Open the Events page.

   Sign in to the app, choose the right account in the top bar, and open Events from the main menu.

2. (Optional) Create a template first.

   If you’re going to run the same kind of event repeatedly, create it once as a template — capacity, form, messages and so on. New classic events can then inherit from it.

3. Create a new classic event.

   Click New event, give it a name and description, set capacity (max participants, whether they can bring friends) and pick the booking form.

4. Add one or more event dates.

   For each occurrence set the start time and, if needed, the signup deadline. Without at least one upcoming date the event cannot be booked.

5. Restrict to memberships (optional).

   If only members can attend, add the required memberships under Allowed memberships. Leave empty to let any visitor book.

6. Pick the messages.

   Choose templates for payment reminders, cancellations and the attendance reminder. Make sure the matching connector (SMTP, SendGrid or Twilio) is configured at the account level.

7. Turn on Active.

   This makes the event live inside the account. It still won’t reach visitors until the next step.

8. Turn on Public.

   Now the event appears on your public subdomain. Open the subdomain in a private browser window to verify everything looks right.

How to create a service or procedure and publish it

For root admins and admins. The goal: a visitor can choose a procedure and book a free time slot.

1. Open the Services page.

   From the app menu, choose Services. The list shows everything that belongs to the active account.

2. Create the service.

   Click New service, enter the name, description, location, address and timezone. The timezone is important — all availability windows are interpreted in it.

3. Add procedures.

   For each thing a visitor can book, create a procedure with a name and duration. Optionally set preparation time before the procedure and clean-up time after it so the calendar doesn’t double-book.

4. Set availability.

   Define the recurring time windows when bookings are allowed (for example, Mon–Fri 9:00–17:00). Only slots inside an active availability window can be booked.

5. Pick the booking form (optional).

   If you need information from the visitor at booking time — phone, allergies, notes — attach a form to the service.

6. Turn on Active on the service and on each procedure.

   An inactive service hides everywhere; an inactive procedure stays in the database but doesn’t appear in the booking flow.

7. Turn on Public on the service.

   Visitors now see the service on your public subdomain, with the available procedures and the next open slots.

How to create a membership and publish it

For root admins and admins. The goal: a visitor can buy a membership and use it to book events.

1. Open the Memberships page.

   From the app menu, choose Memberships.

2. Create the membership.

   Click New membership, give it a name and a short description that explains what the visitor gets.

3. Set price, currency and limits.

   Enter the price (in the smallest currency unit), the currency, the maximum number of uses and/or the duration in days. Leaving a limit empty means it is unlimited.

4. Define when it can be purchased.

   Set available from (when it appears on the public page) and optionally available to (when it disappears). Useful for seasonal or limited-time offers.

5. (Optional) Link it to events.

   If the membership should unlock specific events, open each event and add the membership under Allowed memberships.

6. Turn on Active.

   The membership is now part of your account. Existing memberships of returning visitors keep working even when this is off.

7. Turn on Public.

   Visitors see the membership on your public subdomain and can purchase it. Confirm by opening the subdomain in a private window.

How to create a message template

For root admins and admins. Templates live at the account level — write them once and reuse them on any event, service or membership.

1. Open the Message templates page.

   From the app menu, choose Message templates inside the active account.

2. (Optional) Seed the defaults.

   If this is a fresh account, click Seed defaults to create a starter template for every supported slot in the account’s language. You can edit any of them afterwards.

3. Create a new template.

   Click New template and give it a clear, internal name — for example, “Yoga class — payment reminder”. The name is only shown to your staff.

4. Write the email version.

   Fill in the email subject and email body. Use placeholders like %visitor_first_name% and %event_start_at% wherever you want personalised values. Optionally set a sender name.

5. Write the SMS version (optional).

   If you also plan to send this as SMS, fill in the SMS body. Keep it short — SMS providers charge per segment.

6. Save the template.

   You need at least the name plus an email body or SMS body. The template now appears in the dropdowns on every event, procedure and membership form.

7. Attach the template where you need it.

   Open the relevant event, service procedure or membership and pick the new template in the appropriate slot — for example, Attendance reminder on an event. Save and you’re done.