Imagine someone finds your service page, explains their project and sends an enquiry. Who has room to look at it?
That question is worth answering before you invite the next request. A useful funnel plan includes the moment you need to pause, the words a visitor will see and the conditions that let you reopen.
Start with one service and one enquiry route. By the end of this exercise, you will have a decision an owner can make, a short message for each state and a receiving process that still needs to be checked.
This is planning for a ClickFunnels AI project. It does not establish a built-in pause switch, capacity counter, waitlist or working integration. Check the current product and access boundary in the ClickFunnels AI agent guide before assigning implementation work.
Decide what “room for another enquiry” means
Choose a unit that matches the work. A new enquiry might need an initial review even if no appointment is booked. Counting booked jobs alone would miss that review workload.
Write down four things: the review window, the work already committed in that window, a realistic limit for that work and the person who can decide whether to accept more. Include a backup who has actually agreed to the role. An empty name is an unresolved task.
You do not need a universal number. You need a number or condition the responsible person can explain. If the work varies too much for a count, use an explicit owner decision and record its basis instead.
Work through four fictional cases
The following business, people and counts are invented. They illustrate decisions to plan, not tested behavior, customer results or ClickFunnels AI limits.
Pine Desk Garden Design sets an internal limit of three initial enquiry reviews per review window. Mina is the decision owner. Jules is the proposed backup. A review is not an accepted project, an appointment or a promised response time. The fictional limit must not be copied into another business without assessing its workload.
Scroll horizontally to compare all columns.
| Case | Known planning facts | Decision to plan |
|---|---|---|
| A01 | Two reviews committed out of three; Mina is available; receiving checks still unperformed | One nominal review remains. Plan to accept only after the owner confirms capacity and the receiving checks pass. |
| A02 | Three reviews committed out of three; no next window confirmed | Plan a deliberate pause for new enquiries. Do not invent a reopening date. |
| A03 | One review committed out of three in a proposed next window; Mina available; reopen check unfinished | Two nominal reviews remain, but keep the route paused until the missing check and owner decision are complete. |
| A04 | Zero reviews committed; Mina absent; Jules has not accepted backup responsibility | Keep the route paused. Empty capacity does not supply a responsible person. |
The arithmetic is simple: three minus two leaves one, three minus three leaves zero, and three minus one leaves two. The decision also depends on ownership and the receiving process. In A04, a count of zero committed reviews is not enough to reopen.
All four cases have execution status NOT RUN. “Plan to accept” is not evidence that a live form accepts or stores an enquiry.
Write the pause message before you need it
A deliberate pause deserves clear page copy. GOV.UK's service-unavailable pattern separates planned closure from a fault and recommends explaining the situation concisely, including a return time when it is known. Use that as a writing principle; its government-service examples do not establish your business's behavior. GOV.UK service-unavailable guidance
For the fictional A02 case, a proposed message is:
New garden-design enquiries are paused. We have not set a reopening date.
That is enough if there is no verified alternative. Avoid adding “email us instead” when that sends work to the same unavailable person. A new waitlist is also a new process: it needs an owner, a defined use for the information and a checked next step before being offered.
If there is a dependable contact route for people with existing enquiries, explain that separately. Do not make current customers guess whether their request was cancelled. Only promise a contact method or retained information after the responsible owner confirms it.
“Fully booked” would be inaccurate if the pause is caused by a missing reviewer. “Back tomorrow” would be inaccurate if tomorrow is only an internal check-in. Use the reason and timing you can support, without exposing private staffing details.
Separate page wording from the receiving process
Removing a button changes what a visitor sees. It does not by itself establish what happens to a form already open in another browser, an older link or another enquiry route.
MDN explains that browser-side form checks do not replace checks on the receiving side. The practical implication here is to ask the implementation owner how a deliberate pause will be enforced and verified, rather than treating visible copy as proof. MDN form-validation guidance
List only the routes this plan covers. For example: the new garden-design enquiry page and a known embedded copy of that same form. Keep support for existing customers and unrelated services outside the pause unless their owners explicitly include them. Intentional existing CF2 journeys are separate; this plan is not a reason to redirect them.
Decide how to handle the boundary case before changing state: someone loads the page while it is accepting enquiries and presses send after the pause begins. The receiver may need to accept that request for review or decline it clearly, depending on the approved process. Choose one policy and ask for it to be verified. Do not tell the visitor a request was saved if that result is unknown.
Use synthetic information and an authorized test environment for checks. Record the actual result; do not repeatedly submit when you cannot tell whether the first attempt was received. Leave unresolved behavior with a named owner.
Keep existing enquiries with their owners
Pausing new intake is not a decision to discard work already received. Before the change, identify the existing enquiry list in the system of record and confirm who handles it. Do not paste customer details into the planning worksheet.
Record the responsible role and the location of that record instead. If any enquiries arrive during the transition, reconcile them with the receiving owner and assign the next step. A page message alone cannot perform that reconciliation.
Reopen after evidence, not just a calendar reminder
Return to A03. Mina can plan an internal review on Tuesday morning, with an exact date and timezone recorded in the worksheet. That is a decision appointment, not a public reopening promise.
At that review, check capacity again, confirm an available owner, verify the intended receiving behavior and approve the current page copy. If those conditions are satisfied, the authorized owner can approve reopening. If one is missing, keep the pause and record the next question. A04 remains paused until responsibility is accepted even though its count is low.
After an authorized change, check the agreed routes and the boundary case. Record which state was expected, what was actually observed and who reviewed the result. If the page says enquiries are open but the receiving check fails, the owner needs to resolve that mismatch before relying on the invitation.
Download the enquiry pause and reopen worksheet. Start by naming the person who can accept the next enquiry. If that role is still blank, make confirming it your next task.