Booking handoffs: who owns the next step?
Assign booking enquiry owners, record decisions, and plan escalation across shifts and channels so the next person knows what to do.
Who this guide is for
Studio owners, reception teams, and service teams who share enquiries across shifts, channels, or approval roles.
Two people have read the enquiry. Each assumes the other is answering. The client has a question about a booking, reception needs a decision from the studio manager, and the next shift starts without knowing who promised what. This is an ownership problem before it is a reply-speed problem. A useful booking handoff names the person responsible, records the decision still needed, and tells the next person when to act. Start with one shared rule: an enquiry always has a current owner until another person explicitly accepts it.
Give the enquiry one owner and one next action.
A shared inbox makes a conversation visible; it does not decide who is responsible. Assign one person to move each active enquiry forward. Others can contribute, but the current owner checks that the next action happens and keeps the client informed. When work changes hands, the receiving person should acknowledge the handoff rather than discovering an old message by accident.
Record enough context for the next person to work: the client and booking reference, the request, what has already been agreed, the outstanding decision, the next action, and its due time. Keep facts separate from assumptions. “Client requested a later start; manager approval pending” is more useful than “probably fine.” Do not describe a requested change as confirmed before the authorized person has agreed.
Use simple working labels your team understands, such as waiting for the client, waiting for an internal decision, ready to confirm, and closed. These are examples of an operating agreement, not a claim that a particular software status exists. The label should explain the blocker; the owner field should explain who is responsible for resolving it.
Escalate a blocked decision without passing the client around.
Some requests need authority the current owner does not have: changing an agreed scope, making an exception to availability, or approving a commercial adjustment. Define who can decide and what information that person needs. Escalating a decision should not automatically make the client responsible for finding the approver. The current owner can remain the client’s contact while a manager supplies the answer.
A useful handoff note might read: “Client asks to move Friday’s portrait session to a longer slot. Current owner: reception. Decision needed: manager to confirm duration and availability. Next action: reception sends the agreed options after approval. Review by: Thursday afternoon.” This is an illustrative example. Adapt the roles and deadline to your actual service, and check the calendar before offering a change.
Agree what happens if the approver is absent or the review time passes. Name a backup role and a point for a second review. Tell the client when you expect to update them without promising a result you cannot authorize. A clear escalation path is more useful than several colleagues sending separate “we are checking” messages.
“A handoff is complete when the next owner knows the decision, the next action, and when it is due.”
Make the next shift able to continue the same conversation.
Before a shift change, review open enquiries by owner and blocker. For each one, check whether the client is waiting for your team or your team is waiting for the client. Include the last meaningful update and any commitment already made. The incoming person should be able to explain the next step without asking the client to repeat the original request.
Keep the same reference when an enquiry moves from a social message to email or a booking record. Record the decision in the shared client context rather than leaving the only answer in a private chat. Share only the details needed for the work and respect existing access permissions. This guide concerns continuity across people and channels; a service-specific booking link can still handle the straightforward scheduling part.
At the end of the week, review a small sample of unresolved handoffs. Look for missing owners, unclear approval authority, overdue actions, and requests marked complete before the client received an answer. Improve one recurring gap before adding another notification. A reminder can draw attention to a task, but it cannot decide who should own it.
A handoff another person can accept
- Owner: name the current contact and the person accepting the next action.
- Decision: record the client’s request, agreed facts, blocker, and authorized approver.
- Follow-through: set a review time, a backup role, and the update the client should receive.
Make ownership visible before adding automation.
Use the client record to keep relevant booking context together, and agree how your team records responsibility and the next action. Test the agreement on one enquiry that crosses a shift or needs approval. If the receiving person can continue without reconstructing the conversation, the handoff is working. Then consider reminders for the review points you have defined, while keeping responsibility with a named person.
Common questions
Who should own a booking enquiry when several staff members are involved?
Assign one current owner to coordinate the next action and client update. Other staff can contribute or approve decisions. Transfer ownership when the receiving person explicitly accepts the handoff.
What belongs in a booking handoff note?
Include the client or booking reference, request, agreed facts, outstanding decision, current owner, next action, review time, and approver where needed. Keep assumptions distinct from confirmed changes.
When should a booking request be escalated?
Escalate when the decision needs authority the current owner lacks, a review time passes, or the usual approver is unavailable. Define a backup role while keeping one clear contact for the client.