Cancellation policies
Write your terms once, attach them to services, and override them per session.
A cancellation policy is a named set of terms: a label, a free-cancellation window, and the wording players read. You write it once and attach it wherever it applies.
Policies live under Services, on the Cancellation policies tab.
What a policy is made of
Name. Short, for you, not for players: "Standard 24h", "Squad term", "Court paid upfront". This is what you pick from when attaching a policy, so make it recognisable at a glance. Up to 60 characters.
Free cancellation window. How many hours before the session a player can cancel without being charged. There are presets for 24, 48 and 12 hours, plus No free cancellation and a custom value between 1 and 168 hours.
The presets carry the reasoning: 24 hours is the most common choice, 48 gives you more protection and suits sessions you would struggle to refill, 12 is flexible and suits drop-in sessions, and no free cancellation suits a court you have already paid for.
Policy wording. The prose players actually read, up to 1000 characters. The window gives them the number; this gives them the rest, for example what happens after the window closes or how to ask for an exception.
Attaching a policy
Attach one to a service and every session running off that service carries it.
Override it on an individual session when that session needs different terms. A session with its own policy stops following the service.
If neither the session nor the service has a policy, players see nothing about cancellations, which in practice means they email you to ask.
They are shown, not enforced
This is the part worth reading twice. A cancellation policy is displayed to players. Arvald does not act on it.
Nothing is deducted automatically, no refund is calculated for you, and no booking changes state because a deadline passed. When a player cancels within your window, you decide what to do and issue the refund yourself. When they cancel outside it, you decide that too.
This is deliberate. A policy engine that computes partial refunds against tiers and exceptions gets complicated fast and gets it wrong in the cases that matter, and you would still be overriding it. So the policy is the thing you point at when you make the call, not the thing that makes the call.
Editing and archiving
Editing a policy applies immediately to every service and session using it, including sessions that are already booked. If you want new terms to apply only going forward, create a second policy rather than editing the first.
Archiving a policy takes it out of the picker so you stop attaching it to new things. It does not detach it from anything already using it: services and sessions on an archived policy keep showing those terms. You can restore an archived policy at any time.
You can have up to 20 policies per brand. If you are approaching that, you are probably using policies where you meant to use the wording field.