# Appointments best practices > Most scheduling problems are not software problems. They are decisions taken once, badly, and then lived with for a year. (Apps: Appointments) - Page: https://dashboard.nizu.io/knowledge_base/view/259-appointments-best-practices - Part of: [Knowledge base](https://dashboard.nizu.io/knowledge_base/llms.txt) on NIZU — https://dashboard.nizu.io/llms.txt - Updated: 2026-10-25T11:50:03Z ## Appointments best practices Most scheduling problems are not software problems. They are decisions taken once, badly, and then lived with for a year. These are the decisions worth taking deliberately. ### Services #### Model a service as a promise, not a category A service is what the client is buying and how long you owe them. “Consultation 30 min” is a service. “Consulting” is a category, and it will produce bookings you cannot fulfil because nobody agreed how long they are. #### Set the duration to the whole commitment The duration is how much of the diary the booking consumes, so include the parts the client does not see: setup, notes, travel, the overrun that always happens. A 45-minute meeting that really costs an hour should be a 60-minute service, otherwise your day quietly overbooks itself. #### Keep the list short The first thing a client sees is a list of services. Five they understand converts better than fifteen they have to read. Retire the ones nobody picks set them to *inactive* rather than deleting them, so the bookings that already used them keep their history. #### Write the description for the client “A 30-minute call to understand what you need and tell you what it would cost” beats “Initial discovery session (Tier 1)”. The description is sales copy on a public page, not an internal label. #### Never leave a service without a provider A service with no assigned provider appears to be bookable and then offers no slots. It is the single most common “the booking page is broken” report. When somebody leaves the team, check every service they were assigned to. ### Hours and availability #### Set the company default first, override only the exceptions Fill in the workspace opening hours and closed days once, then leave every provider on *Company Default* except the people who genuinely differ. Filling in seven rows per person is work you will have to redo every time the office hours change. #### Use closed days for the pattern, holidays for the dates Saturday and Sunday belong in *Closed on*. The Christmas shutdown, public holidays and the day of the office move belong in **Holidays**. Putting a recurring day in as fifty individual holidays is a maintenance trap. #### Choose the slot length to match how you want the day to look The slot length is how often a new start time is offered. Fifteen minutes gives clients maximum choice and gives you a day full of awkward gaps. Thirty or sixty minutes produces a tidier diary and slightly fewer bookings. Pick the one that matches how you actually work, and revisit it after a month of real bookings. #### Leave yourself a wall, not a cliff If back-to-back bookings genuinely do not work for you, build the buffer into the service duration. That is more reliable than hoping nobody books the next slot. ### Payments #### Decide what a no-show costs you before you choose a policy If a missed appointment costs you an hour you cannot resell, require payment before the booking is confirmed. If it costs you very little, keep payment optional asking for a card up front always loses some bookings. There is no universally right answer, only the one that matches your economics. #### Use per-service payment for the exceptions The best of both: keep the workspace policy optional, and tick **Payment required to book** on the two or three expensive services where you have actually been let down. The cheap introductory call stays frictionless. #### Set the hold time to something a human can actually complete Fifteen minutes is generous for a card payment and short enough that an abandoned checkout does not cost you the afternoon. Very short holds cancel real clients who went to find their wallet; very long ones let one abandoned basket block a prime slot all day. #### Configure the gateway before switching payments on Appointments never asks for API keys of its own Stripe comes from *Settings → Payment Methods* and Mollie from the Mollie Payment Gateway App. A gateway that is ticked but not configured is simply not offered, which looks like a bug and is not. #### Add the Stripe webhook The return URL alone is not reliable: clients close the tab, lose signal, or pay on their phone and never come back. The webhook is what makes a payment land even when the browser does not. Copy it from the Payments tab into your Stripe dashboard. #### Test with the gateway in test mode, on a real slot Book it yourself, pay it, and watch the booking change state. Then let one expire on purpose and confirm the slot comes back. Those two tests catch nearly everything. #### Re-check rather than assume If a payment looks stuck, use **Re-check** on the Payments screen. It asks the gateway again. Never mark a card payment as paid by hand to tidy up a list *Mark as paid* is for cash and bank transfers, and using it otherwise destroys your audit trail. ### Calendar sync #### Connect the right account Connecting authorises whichever account is signed in to that browser. Someone with a personal and a work Google account will connect the wrong one at least once. Ask people to check the account name on the consent screen before approving. #### Get the Google app verified before you roll it out The Google Calendar scope is a sensitive scope. An unverified app works for a handful of test users and then stops, usually on the day you tell the whole team to connect. #### Treat the external calendar as the source of “busy” Once a provider is connected, the simplest way for them to block time is to put it in their own calendar it stops being offered immediately. That is easier to explain than editing their weekly hours for a one-off. #### Check the cron is running Reminders, releasing unpaid slots and retrying failed calendar syncs all ride on the platform cron. If the cron stops, none of them fail loudly they just quietly do not happen. Confirm it after any server move. ### Notifications #### Rewrite the email templates in your own voice The defaults are correct and generic. The confirmation email is often the first thing a new client reads from you, so it is worth ten minutes in *Settings → Email Templates → Appointments*. #### Set the reminder to match the cost of a no-show A reminder an hour before catches the person who forgot; a reminder a day before gives them time to reschedule so you can resell the slot. If no-shows hurt, use the longer lead. #### Send new-booking alerts to a place people watch Email is where notifications go to die. If somebody has to approve bookings quickly, the Telegram alert on every new booking is the one that actually gets seen. ### Permissions #### Remember the master switch **Access the App** gates everything else. A role with every other Appointments permission ticked and this one off can reach nothing, and the symptom is a “forbidden” page that looks like a bug. #### Separate seeing from changing Most providers only need to reach the App and see the diary. Keep *add and edit appointments*, *services*, *holidays* and *settings* with the people who own the diary, and keep *manage payments* narrower still it can mark money as received. #### Test with a non-admin account Administrators bypass every permission check, so an admin-only test proves nothing about what your team can actually do. Keep one ordinary staff login for this. ### Running the diary day to day #### Work from the dashboard, not the calendar The calendar shows shape; the dashboard shows what needs a decision. **Up next** and the *Pending* status tab are the working queue. #### Read Booking pressure weekly, not daily Its value is the pattern: which open days are still empty a fortnight out. That is the number to act on with an offer or a nudge and it is why closed days and holidays are drawn differently, so you are never chasing a gap that does not exist. #### Act on Provider load in both directions A provider at 90% will start delivering badly; a provider at 5% is capacity you are paying for and not selling. Rebalance by changing service assignments, which is faster than changing anybody's hours. #### Keep statuses honest Mark meetings **Finished** and no-shows **Cancelled**. Every figure on the dashboard, and every capacity calculation, is only as good as the statuses underneath it. A diary full of stale *approved* bookings from last month tells you nothing. #### Publish the link where clients already are The booking page only works if people reach it: your website, your email signature, your invoices, a QR code on the counter. Keep the branding and colour matched to your site so it does not feel like leaving it. ### Common mistakes - **A service with no provider assigned.** Looks bookable, offers nothing. - **Durations that ignore the real cost of a meeting.** The diary overbooks and the day runs late. - **Payments switched on before the gateway is configured.** The option is silently not offered. - **No Stripe webhook.** Payments made on a phone go missing. - **Recurring closed days entered as holidays.** Endless maintenance. - **Only ever testing as an administrator.** Permission bugs stay invisible until a provider hits them. - **Deleting a service instead of deactivating it.** Past bookings lose their context. - **Assuming the cron runs.** No reminders, no released slots, no calendar retries and no error either.