Who this is for: studio operators (admin panel) · Product: Podyx V2
An admin booking is one you create on the client's behalf. Someone calls, walks in, or negotiates something over email, and you put it into the system yourself. It keeps every booking inside Podyx, which is what makes your calendar, your reporting and your invoicing trustworthy.
ℹ️ This is the full reference for the admin booking form. Sessions and the In-app Calendar both open the same form — what you can set is identical wherever you start from.
⚠️ Read Customer self-service first if you book on clients' behalf. Clients can now reschedule, cancel and buy add-ons on the sessions you created for them, including sessions already on your books. There is a per-session switch to turn that off.
🎥 Watch the walkthrough
🔧 Where to create one
Four places, all leading to the same form:
From the Sessions tab
From inside an individual session
From a client profile
Straight from the calendar, by clicking an open slot
💡 Start from the calendar when the time matters most and you are looking for a gap. Start from the client profile when the person matters most and you already know who you are booking for.
🛠 What you can set
Who and what
The client's email
The setup being booked and the base service
Recording seats, duration, and date and time
Additional services and file delivery method
Customer self-service — whether the client can manage this session themselves. On by default; see below
Money
A price override, when you have agreed something different
A promo code
Billing details
Whether to send a payment link, and how long it stays valid — see How long the payment link stays valid below
Whether to issue an invoice
Context
A note, which appears in the session details afterwards
Any guests attending
How the form is ordered. Date and time sits directly under Base service, both on New Booking and when you edit an existing session, so the form reads in the order you actually fill it. The picker shows itself while nothing is chosen yet, rather than looking like a filled field with nothing in it.
Prices the form will not take. If you type a price the form cannot use — a negative number, or a figure far too large — it is refused as you type, with the error shown on the field itself. You find out there and then instead of at the point of saving.
Where errors appear. Error messages show at the top centre of the form, clear of the Save button. If you have ever pressed Save, seen nothing happen and assumed the form had frozen, that was a message sitting over the button.
Day rates. A session booked at a day rate is named as that rate on New Booking, and it keeps that name through later edits — so an admin booking shows the same named rate the client would have seen. See Base Services for how day rates work.
🔑 Customer self-service on sessions you created
Clients can now reschedule, cancel and buy add-ons on sessions the studio booked for them, exactly as they can on sessions they booked themselves. Until now, a session you created was yours to manage and the client had to call you to change anything.
⚠️ This applies to sessions already on your books, and it is on by default. There is no studio-wide switch. If you book on clients' behalf precisely so they cannot move things — a negotiated slot, a session built around a specific engineer, a booking you are holding as a favour — go and untick Customer self-service on the sessions that matter, now rather than later.
Two places to control it:
On New Booking — untick Customer self-service as you create the session.
On the session page — flip it on or off at any time afterwards.
What the client still cannot do, even with self-service on:
Reschedule, unless rescheduling is enabled in your settings. Your existing rescheduling rules still govern everything.
Move a session with a payment link still out. The link has to be dealt with first.
Cancel a session paid in cash or outside Podyx. They can move it, but cancelling it from their profile is refused — because there is no payment for Podyx to reverse.
💡 The honest trade-off: leaving self-service on removes a pile of phone calls about moving a session by an hour, which is most of what those calls are. Turning it off is for the bookings where the arrangement, not the slot, is the thing you agreed. Decide per booking rather than as a blanket policy, since that is the only way the switch works anyway.
⏳ How long the payment link stays valid
When you tick send a payment link, the form shows Payment link valid for. You choose an amount of time in minutes, hours or days, and you choose which end of the booking that time is measured from.
Counting forward from the booking. The link expires a set time after you create the booking — for example, 2 hours after. If the client has not paid by then, the link dies and the booking cancels.
Counting back from the session. The link expires a set time before the session starts — for example, 48 hours before. The deadline sits just ahead of the session itself, however far away that is.
The second option solves a familiar problem. A session booked six weeks out used to have its payment link expire, and the booking cancel, long before the client had any reason to think about paying. Now you can hold the slot and put the deadline where the client expects it.
Which one to use. Count forward when the session is happening soon — it is a pay-now-or-lose-the-slot situation, and a short window protects a valuable slot from sitting reserved and unpaid. Count back when the session is weeks out — you are holding the slot in good faith and asking the client to settle up nearer the time.
💡 Nothing changes unless you want it to. The default is still 2 hours after the booking is created, so if you never touch this field your links behave exactly as they always have.
If the session is too close for a before the session starts rule to make sense — the deadline would already have passed — the form tells you while you are filling it in, rather than letting you save and fail afterwards. Shorten the window or switch to counting forward.
Every deadline is capped at 2 hours before the session starts, and the preview says so as you set it. A link that could still be paid while the client is walking through the door helps nobody, so the cap gives you a little time to see the payment land and prepare the room. Short-notice and retroactive bookings are exempt — a session you are creating for this afternoon, or one you are recording after the fact, is not forced against a cap it could never meet.
⚠️ A long window is still a real deadline. Counting back from the session means the booking can cancel the day before it was due to happen, so keep an eye on unpaid bookings as the date approaches.
Payment link valid for only appears when a link will actually be sent. If you untick the send box the field disappears, and if you tick it again your chosen setting is still there.
Your choices survive a price change. Adding a service or overriding the price mid-form can push the total past the credits the client has available, which turns the booking into one that needs a payment link. When that happens, Payment link valid for and your Send payment link choice both stay as you set them. You no longer have to notice that the form quietly reset them at exactly the moment the link started to matter.
🧾 The payment link card on the session page
Once the booking exists, the payment link has its own card on the session page. It tells you what the link covers, the amount due, and where the link has got to, on a status timeline: Sent → Opened → Paid → Expires. Extend, Force expire and Resend link all sit together on the same card, so you can act on what you are reading without going looking for the controls.
The timeline is the part worth checking, because it tells you whether the client has even opened the link. A link that was never opened is a different conversation from one opened three times and never paid. The first is almost always an email problem — it went to spam, or to the wrong address — and resending it, or reading the address back to the client, usually fixes it. The second is a client who has a problem they have not told you about: a card that will not go through, a budget that needs approval, second thoughts about the session. Those two situations need opposite responses, and the card is the only place that distinguishes them.
💡 Check the timeline before you chase. Ringing a client about an unpaid link they never received makes you look disorganised; ringing one who has opened it three times is a conversation they are probably relieved to have.
👉 Need to move a deadline after the booking exists? Use Extend on the payment link card — see Sessions for the session page itself.
💳 When the client's card is declined
A decline on a payment link you sent no longer costs the booking. The booking, its slot and its payment deadline are all kept, and the client simply pays with another card on the same link. This works whether you take payment through Stripe or Square.
That matters most for the bookings you take by phone. A client reading out a card that fails used to lose the slot you had just promised them; now the arrangement holds while they find a different card.
What happens around the decline:
The client is emailed straight away telling them the card was declined and the booking is still theirs.
A second email follows after a delay you configure — anywhere from 5 minutes to 7 days, 15 minutes by default — in Sales → Email notifications. Each of the three emails has its own switch, so you can run just the immediate nudge, just the follow-up, or all of them.
You are alerted if the card is declined again after that, so you know a booking is struggling before the deadline arrives.
⚠️ After 10 declined attempts the link stops taking cards, and you are told the client needs your help. That is your cue to contact them directly — at that point something is wrong with the card or the account, and no amount of retrying will fix it.
💡 If the deadline is close and the client is still sorting out a card, use Extend on the session page to buy them time rather than letting the booking cancel over a payment problem you already know about.
👉 See Automated Emails & Notifications for the three email switches and the follow-up delay.
🔓 What admin bookings can and cannot bypass
What you can bypass. When you book as an admin, the picker ignores the cutoff and buffer rules that apply to clients. So you can squeeze in a same-day session that your booking page would have refused, or place something inside a buffer window when you know the room is genuinely ready. You can also place a session inside your studio's own booking lead time.
What nobody can bypass. A session cannot be scheduled or rescheduled onto a time that has already passed. That applies to admins, to the customer's own picker, and to the API alike.
The slot picker does follow your studio's session increment, so you see the same available time slots the storefront sells. This keeps the grid consistent whether the booking is created by a client or by you.
⚠️ Useful power, worth respecting. The buffer exists because your turnaround does. Overriding it occasionally is smart, doing it habitually just moves the stress onto your day.
👋 The client is not registered yet
You can invite them directly from the CMS so they can sign up, then add them to an admin booking or a bundle. Nobody has to be turned away because they do not have an account.
🧠 Why it matters
Nothing lives outside the system, so your calendar and reports stay accurate.
You can say yes on the phone and take payment afterwards through a link.
A failed card no longer undoes the booking, so a bad card number costs a phone call rather than a slot.
You can see whether the link was opened, so chasing an unpaid booking starts from facts rather than guesswork.
Negotiated deals stay tidy, with price overrides recorded rather than remembered.
Fewer calls about small changes, since clients can move their own sessions unless you decide otherwise.
✅ Summary
Create admin bookings from Sessions, an individual session, a client profile or the calendar — all four open the same form. Clients can now reschedule, cancel and buy add-ons on the sessions you create, including ones already booked, so untick Customer self-service on the bookings you need to keep studio-managed. Set the session details, override the price if you agreed one — a day-rate session is named as that rate — and send a payment link with an expiry in minutes, hours or days (2 hours by default) rather than chasing money later. That expiry can count forward from the booking for a session happening soon, or back from the session start — say 48 hours before — for one that is weeks away, capped at 2 hours before the session begins. Your Payment link valid for and Send payment link choices hold even when a price change pushes the total past the client's available credits. On the session page the link has its own card showing what it covers, the amount due and a Sent → Opened → Paid → Expires timeline, with Extend, Force expire and Resend link alongside it — check whether the link was opened before you chase. If the client's card is declined the booking, slot and deadline are all kept on both Stripe and Square, the client is emailed immediately and again after a delay you set, and after 10 declined attempts the link stops taking cards and you are told to step in. Admin bookings skip client cutoffs, buffers and your booking lead time, but nothing can be scheduled into the past.
Related: Sessions · In-app Calendar · Clients · Booking Rules · Automated Emails & Notifications
