Manual booking approval: ownership and decision deadlines

A customer selects a time and submits their details, but the organiser still needs to check whether the required service configuration can be prepared. Manual booking approval separates receiving a request from confirming delivery. To avoid holding up customers and capacity, the process needs a defined decision, someone on duty and a substitute. The following equipment demonstration example works through three status messages and the actual limit for responding.

Define the decision that justifies manual approval

Start by explaining what cannot be established simply by selecting an offer. At our fictional demonstration centre, a customer requests a portable equipment presentation and an employee checks whether the selected configuration is ready before confirming. The decision therefore has a specific subject: equipment readiness for this service. Do not introduce manual approval merely so the team can inspect every booking without defining what it is assessing.

Write the confirmation condition in one sentence, such as: “We confirm after checking kit completeness and whether it can be prepared before the demonstration starts”. Separate this assessment from questions customers should resolve by reading the description. If every request needs an explanation of basic scope, improve the offer first. Approval should not replace information about what is being booked. For a confirmation condition that depends on the state of a vehicle, such as paint correction, see the guide to car detailing online booking. In a restaurant, such a condition might cover groups of nine or more and a check of the room and the kitchen, as in the guide to restaurant table bookings online.

Define a negative outcome too: inability to deliver means this request cannot be confirmed, while an alternative requires separate agreement. Do not promise an automatic switch of configuration or time. Record who can offer another arrangement and when they need the customer's agreement. The online booking system guide provides the broader context of accepting bookings.

Assign duty coverage and a substitute for requests

The responsible person should know not only that they handle bookings but also when they review pending requests. Define routine duty coverage, a substitute and a handover for unfinished cases. If the decision depends on information from the equipment area, name the person who checks kit readiness as well. The table below is an organisational example rather than an automatic assignment of tasks by the system.

↔ Scroll the table sideways to see all columns.

At the end of a shift, hand over specific pending requests with their decision deadlines. Saying “there are a few bookings left” is insufficient when one starts tomorrow morning and another in three days. The substitute should read the current state, check what is missing and take over the agreed actions. Do not rely on the memory of a person who has already left work.

Compare responsibility arrangements with the guide to assigning customer enquiries. For bookings, retain a separate decision list and a check of time remaining before delivery. Do not assume assigning a conversation automatically confirms an appointment or assigns someone to every pending booking. The team must be able to identify the decision owner during breaks and absences too.

Calculate the deadline against the service start

The configured approval period runs from receipt of the request, but it cannot extend beyond the booked service's start. In Meetlead, the deadline is the earlier of two moments: the end of the configured period or the start of delivery. Two requests using the same setting can therefore allow different actual response times. Do not tell a customer they have a full two-hour wait if their demonstration begins sooner.

Consider a fictional 120-minute limit. A request submitted at 10:00 for a 15:00 demonstration has a 12:00 deadline; a request at 10:00 for an 11:00 demonstration has an 11:00 deadline. Both use the actual service start rather than the reception shift's end. The approval period is neither a working-hours counter nor a promise that someone will collect the case after the centre closes.

When choosing the limit, compare the review routine with the nearest starts you allow. If staff inspect requests once per day, a short limit does not create another shift. Change the operating arrangement or the rules for accepting times. The setting should express an existing ability to respond rather than conceal the lack of someone available to decide.

Remember that pending requests occupy capacity

Pending approval does not mean an empty proposal that leaves availability untouched. In Meetlead, a pending request consumes offer capacity while it waits. This matters when there are few places or only one available unit. Do not encourage customers to submit multiple similar requests to “improve their chances”, because each may affect availability.

During daily review, distinguish confirmed delivery from requests still needing a decision. A missing time does not necessarily prove every place has a confirmed participant. It can result from pending requests that need handling according to their current state. Do not increase capacity to bypass that situation temporarily without checking why it arose.

If no decision is made before the deadline, the request can expire and is not a confirmed booking. Do not treat that as a waiting list or a queue of people ready to take a released time. Contacting the customer and agreeing a new arrangement remain separate actions. Keep internal information about the configuration concise, following the guide to internal customer service notes.

Separate receipt, confirmation and expiry

Before time selection, make it clear that the customer is submitting a request requiring a check. After receipt, an appropriate example message is: “We received your request for a 15:00 demonstration; the time still needs confirmation”. Only after a positive decision should you say “Your 15:00 demonstration is confirmed”. These texts should leave no need to guess whether the customer should already make the journey. Complete templates for both messages, including place, party size and how to make changes, are in our guide to the booking confirmation message.

Prepare a separate explanation for an expired request: “No decision was completed before the deadline; this request is not a confirmed appointment”. Do not imply expiry automatically moved the person to a later time. If reception proposes another appointment, they read current availability and agree the change. The customer must understand which specific request each message concerns.

In Meetlead Bookings, you configure manual approval and its waiting period for an offer. Match the service description to that mode, then inspect the summary shown after form submission. Do not make all communication depend on a separate phone call that may never happen. The public booking process should explain the request's conditional nature from the outset.

Practise three outcomes before opening bookings

Before publication, run three controlled scenarios: quick confirmation, inability to deliver and leaving a request until expiry. Read the current status and customer-facing availability for each. Define the expected outcome first so you can distinguish a faulty instruction from a misunderstanding of the setting. Include handing one case to a substitute, rather than having the configuration author perform every action alone.

After the exercise, check whether staff can explain the shortened deadline for an imminent start. Ask reception about a 10:00 request for 11:00 with a two-hour approval limit. Their answer should account for the 11:00 beginning instead of promising a wait until noon. If answers differ, correct the common instructions before customers hear conflicting rules.

Finish preparation with a short set of essentials: criterion, coverage, substitute and three messages. Then assess how scope and price units are presented; the guide to per-person or per-booking pricing covers that next step. Confirming an appointment does not itself define how it is charged. Manual approval should resolve whether a specific request can be delivered within a known time, while the other information remains clear independently of that decision.

The distinction between a request and a confirmed appointment is explained in Wix Bookings' manual approval documentation. The deadline and capacity rules discussed here describe Meetlead's current behaviour.

Questions about pending approval

Does a request waiting for approval occupy places? Yes, in Meetlead it consumes capacity while pending. It is not a list of interested people that leaves capacity free.

Does the customer always get the full configured waiting period? No. The deadline is earlier if the service starts before that period ends. A decision cannot wait until after delivery begins.

Does expiry mean a new appointment? No. An expired request is neither confirmation nor an automatic move; any new arrangement needs separate handling.