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.

Rooms

Rooms are shared spaces that only people you approve can book — a meeting room, a studio, a desk, a practice room. Unlike a service, the visitor does not book your time for something you offer; they reserve the room for as long as they need it, within the rules you set.

Who can book: flags

A flag is a label you give people — Employees, Management, Members. One person can carry several flags, and a room lists the flags allowed to book it; any one of them is enough. A room with no flag can be booked by your team only.

Invite people on Rooms → Access: paste their email addresses, pick the flags and send the invitation. There is no password — they sign in with a one-time code sent to that address.

A signed-in visitor who opens a visible room they cannot book yet can ask for access. The room’s responsible people approve (which gives them the room’s flags) or decline, and the visitor gets an email either way.

For a coworking space, or a room anybody may use, switch the room to Anyone who signs in. Keep in mind that anyone can sign in with any email address.

Visible or hidden

A visible room shows its photos, description, capacity, hours and rules to anyone with the link, but booking still needs signing in and a flag. A hidden room answers “not found” to everyone who cannot book it, so even a leaked link reveals nothing. There is no public list of all rooms: people reach a room through your booking page or its own link. You can switch visibility straight from the Rooms list.

Key settings

• Hours — when the room can be booked, per weekday, with several ranges a day if needed. Your team can book outside them.
• Preparation and cleanup — minutes the room stays blocked before and after every booking (0 = none).
• Time grid — how often a booking can start and end, for example every 15 minutes.
• Rules for visitors — the longest booking, the minimum break between one person’s own bookings (so two 2-hour bookings back to back cannot get around a 2-hour limit) and how many days ahead. They apply only to what visitors book themselves.
• Confirm automatically — on: the booking is confirmed at once. Off: it waits until a responsible person confirms or declines it.
• Shared calendar — off, titles, or titles with names. It decides what the people who may book the room see on taken times; nobody else ever sees it.
• Responsible people — team members who hear about new bookings, cancellations and access requests, and decide them. With nobody chosen, admins are told.

How a visitor books a room

On the room page the visitor signs in, picks a day in the calendar, then a free start time — taken times stay in the grid, greyed out — and finally the length, what the booking is for and an optional note. Each step has its own address, so reloading the page keeps their place. Their room bookings appear under My bookings, where they can cancel until the booking starts.

Working with room bookings

Rooms → Calendar shows the week for one room or all of them, with the bookings waiting for confirmation on top. Click an empty time to book for someone (by email) or to block the room internally; click a booking to confirm, decline, move, rename or cancel it. Your own bookings skip the rules for visitors and the hours, but can never overlap another booking. A booking can repeat every workday, every week or every two weeks for up to a year — dates that are already taken are skipped and listed. The Visitors page has a Rooms tab with each room’s bookings, and the All visitors list shows everyone’s flags.

Automated messages

Each room chooses which message template goes out when: the booking waits for confirmation, is confirmed (with a calendar file attached), is declined, is cancelled by the visitor, is cancelled by you, is moved to another time, and a reminder a set number of hours before. Your first room gets ready-made templates you can edit.

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.

Claude & ChatGPT (MCP)

Micali.online runs an MCP server. Connect it once to Claude or ChatGPT and you can ask about your bookings in ordinary language — “who hasn’t paid for Saturday?” — without opening the app at all. The assistant runs on your own AI subscription, sees only what you can see yourself, and can be cut off from your profile at any moment.

How to connect

Four steps, about a minute, and there is no key or password left lying anywhere afterwards.

1. Copy the address

   In the app open Profile → AI connections and copy the address with the Copy button. It is https://mcp.micali.online — the whole address, with nothing after it.

2. Add it as a custom connector

   In Claude or ChatGPT, open the connector settings and add a new custom connector, pasting that address as its URL. Nothing else is needed — no API key, no client id, nothing to register with us first. Anything else that speaks MCP connects the same way: Claude Code, Codex, Cursor.

3. Choose manager or guest, then sign in

   Our own sign-in page opens. Pick Manager to work on an account you run, or Guest to see your own reservations. Type the email address you already use in Micali.online and enter the 6-digit code that arrives. It is the same sign-in as the app: the assistant never sees your code, and you never hand it a password.

4. Ask something

   The connector appears in the assistant’s tool list and is ready. A good first question is a boring one: “what have I got on this week, and who still hasn’t paid?”

What you can ask as a manager

The assistant is given thirty-seven tools and chooses between them itself, so there are no commands to learn. What is worth knowing is the outline of what it can reach:

• Events and dates — the list, with how full each date is, and the whole setup of one event: capacity, deadlines, payment, confirmation.
• Bookings — who is signed up for a date, with contact details and the confirmed / paid / attended state. Can be narrowed to one date, or to only the unpaid or unconfirmed ones.
• Waiting list — who is queued for a free seat, longest wait first.
• Guests — search by name, email or phone, and then one person’s profile with their memberships and recent bookings.
• Membership plans — what you sell, at what price, with what limit, and how many people hold one right now.
• Services and appointments — what you offer, and who has an appointment booked in a given period.
• Rooms — the rooms and who can book them, the bookings in a period and the ones waiting for confirmation, access flags and the people who carry them, and access requests. It can also set up a room, book it for someone once or repeatedly, confirm, decline, move or cancel a booking, give people a flag with an invitation, and approve a request.
• Booking forms — the extra questions guests answer, field by field, and building or rewriting one from a description.
• Feedback questionnaires and their results — the survey sent after an event or an appointment, the score per question, and every individual answer with who gave it and what it was about.
• Bookings waiting to be confirmed — guests who filled the form but never clicked the link in their email, and confirming one on their behalf.
• The people who manage the account — who they are and what role they hold, inviting someone, changing a role, removing them.
• The account setup itself — name, contact details, address, timezone, language, formats, booking subdomain, social links.
• Changing the state of a booking — confirmed, paid, attended.
• Cancelling a booking on a guest’s behalf.
• Creating and changing what you offer — events and their dates, services, membership plans, forms, questionnaires. Not only reading the setup but writing it: “set up a beginners’ course, Mondays at six for eight weeks, twelve places” is one request.

Twenty-two of the thirty-seven only read; fifteen can change something. The split matters because your assistant asks you before running anything in the second group, and never asks for the first — so questions stay quick and changes stay deliberate.

In practice it answers questions like “how many places are free next week?”, “has she any visits left on her pass?”, “who missed last Friday’s class?”, “mark Peter’s Saturday as paid”, “add three more dates to the Tuesday course”, “what did people say in the feedback last month?”. It finds the account, the event and the booking for itself — you never have to name an identifier.

What a guest can ask

Guests connect in exactly the same way, choosing Guest on the sign-in page, and get five tools of their own:

• the organisations they are registered with,
• their own reservations — events, appointments and room bookings, upcoming ones by default,
• their memberships, with visits used and visits left,
• a search for dates they can book, including how many places are free,
• cancelling their own booking — an event booking respecting the deadline the organiser set, a room booking any time before it starts.

How to disconnect

Access you cannot withdraw with one button is not access worth granting. Every connection is listed on your profile with the day it was made and when it was last used.

1. Open the list

   Profile → AI connections, the same place the address is. Guests have the same section on their own profile.

2. Press Disconnect

   The Disconnect button next to the assistant you want to cut off, then confirm in the dialog.

3. It is gone immediately

   That one connector loses access at once. Everything else stays untouched — the app in your browser stays signed in, and so does every other assistant you have connected. You can add the same one again later; it simply goes through the sign-in once more.

A connection you forget about ends by itself. The access token lasts five hours and the assistant renews it silently, but renewing stops after 90 days.

What the assistant deliberately cannot do

Letting an AI reach guest data is a decision that deserves visible edges. These are ours.

• It never sees more than you do. Every single call re-checks that you really administer that account. There is no “currently open account” it could lean on, and therefore no way to talk it into someone else’s data.
• Team members are switched off for now. A team member sees only the events and services assigned to them, and that limit would have to be rebuilt inside each of the twenty-eight tools separately. Until it is built in, the connector refuses their sign-in with a clear reason rather than handing over a half-correct view.
• Anything that cannot be undone is declared destructive. The protocol lets each tool state whether it only reads and whether its effect can be undone, and Claude and ChatGPT ask you before running anything in the second group. Cancelling a booking is marked destructive — it deletes the row, messages the guest and offers the freed place to the first person waiting — and so are deleting an event, a service, a plan, a form or a questionnaire, and removing someone from the account. Those tools also instruct the assistant to read back what is about to go, in words, and wait for an explicit yes.
• It obeys the same rules you do. The tools that change something do not carry their own version of the rules — they run the very same code the app runs when you click the button. So an admin who is not a root admin cannot rename the business through the assistant either, nobody can remove their own access, deleting an event still writes to everyone booked on it, and a new manager still gets the ordinary invitation email.
• We never see your conversation. The assistant runs on your subscription and talks to you directly. On our side we see only the individual tool calls that arrive — the same thing we would see if you were clicking around the app. The text of your questions and its answers never reaches us.

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.

Awaiting confirmation

Bookings a visitor filled in on your public pages while signed out. Nothing is reserved until they open the link we emailed them — this page is where you see what is still in flight, how much of it never arrives, and where you can step in when the visitor cannot.

How a booking ends up here

A visitor who is not signed in fills in the whole thing — the slot, the seats, their contact details, any form you attached — and is not asked for a code first. Submitting it parks the booking and sends them a single-use confirmation link. Until they open that link nothing exists in your account: no visitor, no booking, no form answer, and no seat is held. That is deliberate — someone typing a stranger’s address can never fill up your event.

The link lasts 24 hours, or until the slot starts, whichever comes first. Opening it proves the address, signs the visitor in and creates the booking through the ordinary rules — capacity, waiting list, signup deadline, your approval — so they get the same answer they would have got booking signed in. If they hold a membership the event accepts, that is the moment they are asked which one to spend.

A visitor who is already signed in never comes through here. They book directly, and there is nothing left for them to confirm.

Nobody has to wait for the email either. Signing in to your booking page shows a Waiting for your confirmation card listing everything parked under that address, each with a Confirm button. Confirming there and opening the mail afterwards anyway is harmless — the link simply reports that it is already confirmed.

What the page shows

Open Awaiting confirmation in the sidebar. Four numbers sit at the top, and the first three are also filters:

• Waiting for confirmation — the link is still valid and the visitor can still use it.
• Never confirmed — the link expired unused. This is the number worth watching: it is interest you had and did not keep.
• Confirmed — became real bookings.
• Confirmation rate — the share of links that were used. Only links that have run their course are counted, so the ones still in flight do not drag it down all day.

Below them is a bookings-per-day chart: every booking your account took, with this funnel drawn inside it. A booking made by a signed-in visitor, or one you added yourself, never passes through the funnel, so the two inner lines are always a slice of the taller one. The type filter narrows both; the text search narrows the table only, so looking one person up does not redraw your volume as theirs.

Admins and root admins only — the same bar as your visitors list, because until the link is opened these contact details are not proven to belong to the person who typed them.

Confirming for a visitor

The mail went to spam, the link lapsed unread, or they rang the desk instead. Confirm for them sits on every row that is not confirmed yet — expired ones included, which is mostly why the button is there — and books it exactly as the link would have. The rules still decide the outcome: if the event is full the visitor goes on the waiting list, if it needs approving it lands in your approvals, and if the deadline has passed nothing is booked and you are told why. Confirm for them

One thing differs from the visitor’s own click: no prepaid plan is spent, because nobody was asked which one to use. Attach one to the booking afterwards if it should count against a plan.

Every booking made this way records the admin who confirmed it, and the row shows their name.

Knowing it happened

When a booking is parked, a notification arrives in the bell straight away — team members see it too, even though they cannot open this page. It links to the event or service the visitor was aiming at, because there is no booking to link to yet.

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.

A booking button on your website

Put a booking button on your own website. It floats in a corner of every page, and a click lets visitors book your events and services right there — or takes them to your booking page.

Setting it up

Open Website widget in the side menu (root admins only). Choose the button text, its color, the corner it sits in, what a click does and the language of the booking window, try it in the preview, and copy the code.

Paste the code into your website just before the closing </body> tag, on every page where the button should appear. Most website builders (WordPress, Wix, Webflow, Squarespace…) have a place for custom code or an HTML block.

Your own button. Any link or button on your website with the data-micali-open attribute opens the booking window as well, and a developer can call MicaliWidget.open(), MicaliWidget.close() or MicaliWidget.toggle(). The widget code has to be on the page for this to work. If you would rather show only your own buttons, turn on Hide the floating button: the code then draws no button in the corner, and the booking window opens only from your buttons.

A button after the booking. On the Website widget page you can add a button that the booking window shows once a visitor sends a booking — with your own text, color and JavaScript. Nothing runs by itself: your code runs on your website only when the visitor clicks the button (for example to open your payment), and the window then closes. For developers, the page also receives micali:booked and micali:action events with the booking’s kind, id, name and start time — never the visitor’s personal details. With the booking page instead of the window, the booking happens on Micali.online and your website does not see it.

What a click does

• Booking window — a window opens on your page with a calendar: events by date, services by procedure, day and time. The visitor fills in their details and the booking form, and confirms.
• Booking page — opens your Micali.online booking page in a new tab, with everything on it, including memberships and rooms.

What the visitor gets

Visitors are not signed in inside the window, so a booking made there works like one made on your booking page without signing in: it becomes valid once they open the link we email them, and they pick any memberships on that confirmation page. Until then it waits under Awaiting confirmation.

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 set up a room people can book

For root admins and admins. The goal: the people you invite can sign in and book the room.

1. Open the Rooms page.

   From the app menu, choose Rooms and click New room.

2. Describe the room.

   Enter the name, the description, where it is and how many people it holds. After the first save you can add photos; the first one is the cover.

3. Set when it can be booked.

   Add the hours for each weekday, the preparation and cleanup minutes, and the time grid.

4. Set the rules for visitors.

   Choose the longest booking, the break between one person’s bookings and how many days ahead people can book. Leave a field empty for no limit.

5. Choose who can book.

   Pick one or more flags (you can create one right there), decide whether bookings are confirmed automatically, and choose the responsible people and the shared calendar.

6. Invite the people.

   On Rooms → Access, paste their email addresses, give them the flag and send the invitation. People who already book with you can simply be given the flag.

7. Share the link.

   Copy the room link from the Rooms list, or let people find the room on the Rooms tab of your booking page. Switch on Visible to everyone if people without access should see the room too.

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.