Capacity Planning for an Account Preparation Queue
Preparing advertising accounts is operational work with a start, a sequence of tasks and an outcome that may depend on outside review.
- Sections8
Editorial team Spend Ledger
Treat preparation as a queue, not a checklist
Preparing advertising accounts is operational work with a start, a sequence of tasks and an outcome that may depend on outside review. Treating it as a queue makes the work easier to plan: campaigns create demand, the team has limited capacity, and accounts move through stages at different speeds. The goal is not to prepare as many accounts as possible. It is to have suitable, compliant accounts ready when campaigns can use them, without leaving campaigns idle or accumulating accounts that have no clear purpose.
Start by defining what “ready” means for your organisation. It might include confirmed ownership and access, completed business information, an appropriate account structure, a valid payment arrangement, required verification, and an internal review of settings. Readiness should also mean that the account is permitted for the intended use under the platform’s current policies. A task being marked complete internally does not override a platform decision or guarantee that an account can advertise.
An account is a work tool, whether the organisation prepares it itself or sources it as a purchased good. Procurement does not remove the need to check that the arrangement is permitted, that ownership and access are clear, and that the account can be used for the intended business purpose. If a platform requires information or verification, follow its official process. Do not treat account sourcing or preparation as a way to bypass a restriction, limit or review.
Estimate demand from campaigns
Demand should begin with campaign plans, not with an arbitrary target for how many accounts to prepare. For each planned campaign, identify the account structure it requires, who will use it, when it must be available, and what conditions must be met before launch. Distinguish an account that is genuinely needed from a spare that is merely convenient. This prevents speculative preparation from consuming staff time and leaving the team responsible for unnecessary maintenance.
Build a demand view that connects each account request to a campaign or other documented business need. Include the expected start window, the required configuration, the responsible team and any known dependencies. If a campaign is tentative, label it as tentative rather than treating it as a firm request. Plans change, and an account prepared for a delayed or cancelled campaign can become idle inventory.
Demand can also arrive unevenly. Several campaigns may depend on the same team, business information or approval path. Grouping requests by those dependencies reveals workload that a simple account count would hide. Review the plan with campaign owners and ask whether the requested timing and structure are still current. When a campaign changes, update or cancel its queue item promptly.
Map the stages and their waiting time
Break preparation into stages that reflect the organisation’s actual process. Internal work may include collecting approved business details, confirming account ownership and access, setting up the required structure, configuring payment in an authorised way, and completing a quality review. External dependencies may include platform review, identity or business verification, or other decisions that only the platform can make.
For each stage, record who owns the next action, what information is needed, and what event allows the work to move forward. Separate active work from waiting time. An account awaiting a platform decision is not necessarily consuming the same staff effort as one awaiting internal setup, but it is still occupying a place in the pipeline and may affect the campaign date.
Waiting times are not fixed promises. They can vary with the nature of the review, the completeness of submitted information, requests for clarification and the platform’s own process. Use your team’s observed experience as a planning aid, not as a guarantee. Where the organisation lacks a reliable history, mark the estimate as uncertain and consult the platform’s current help and policy pages for applicable process information.
When a review is delayed or an account is rejected, use the official support or appeal channel where appropriate. First check the stated reason and correct any underlying issue. Do not submit altered information, create another account to escape a decision, or conceal relationships between accounts. Record the result and revise the plan using what the team has learned.
Calculate lead time with named variables
A useful planning formula is:
Required lead time = internal preparation time + external review time + contingency time
Here, required lead time is the time to allow between starting preparation and the campaign’s required-ready point. Internal preparation time covers work controlled by the team, including gathering information, configuration and quality checks. External review time covers waits for decisions or actions outside the team’s control. Contingency time is reserved for foreseeable rework, clarification requests, delays or a rejected submission that must be corrected through an authorised process.
Use the formula as a planning model, not as a promise that a particular account will be ready by a particular date. Estimate each component from relevant experience and current requirements. If the process or platform guidance changes, revisit the estimate. Do not collapse all waiting into one figure: separating internal and external time helps managers see whether a delay is a staffing issue, an information gap or an external dependency.
The campaign’s required-ready point should be defined carefully. It is not necessarily the launch date. The team may need time after preparation for campaign setup, review of access, billing checks or other authorised launch tasks. Include those activities in the campaign plan, rather than assuming that a prepared account is immediately usable.
Set capacity and protect against overload
Capacity is the amount of preparation work the team can complete while maintaining quality and handling its other responsibilities. Estimate it from available staff time, the work involved at each stage, and the effort needed to resolve exceptions. Do not calculate capacity solely from the number of accounts previously completed. A simple, repeatable setup and a case requiring additional documentation or review can demand very different amounts of attention.
Compare expected incoming work with capacity by stage. If demand exceeds the team’s ability to complete a particular task, the queue will grow there even if other stages have spare time. For example, configuration may be manageable while a single person responsible for business information checks becomes the constraint. Direct attention to the bottleneck: clarify responsibilities, improve the completeness of requests, or reset campaign expectations.
Maintain a controlled intake process. Requests should include a business purpose, an owner, the intended use, required access and timing, and any relevant approvals. Incomplete requests should be returned for clarification rather than silently entering active work. This protects the team from treating missing information as a preparation delay and makes the source of waiting visible.
Avoid keeping every request active at once. Prioritise according to confirmed campaign need, readiness of required information, and the consequences of delay. A transparent priority rule is easier to explain than informal escalation. If demand remains above capacity, tell campaign owners what can be supported and ask them to adjust plans or priorities.
Plan slack for rejection and rework
A queue with no slack assumes that every submission will be complete, every dependency will move smoothly and no account will need correction. That assumption is fragile. Contingency time provides room to address rejected or incomplete submissions through the platform’s legitimate processes without automatically disrupting every campaign.
Plan slack based on the risks visible in the work, not on an invented universal allowance. Consider whether the information is ready, whether the team understands the current requirements, whether the account’s intended use is clear, and whether the process depends on an external decision. When uncertainty is high, be more cautious about committing to a launch window. When a case is rejected, investigate the reason before deciding whether to correct, appeal, pause or cancel the request.
Slack should not become a hidden reserve of unassigned accounts. Its purpose is to absorb uncertainty in a known campaign plan, not to create a stockpile. Keep a clear connection between each prepared account and its approved business purpose. If that purpose disappears, review whether the account should remain active, be reassigned through a permitted process, or be closed according to applicable rules and internal policy.
Rejection risk is also a quality signal. Track recurring causes such as missing information, inconsistent details or unclear ownership. Use those patterns to improve intake and internal review. The response should be to fix the underlying process, not to repeat submissions with changed details or seek another account to avoid scrutiny.
Keep the queue visible and controlled
A shared queue should show each request’s status in plain language, such as awaiting information, in internal preparation, submitted for review, awaiting an external decision, ready for quality review, ready for campaign use, paused or closed. Use status definitions consistently. A status should describe the current state, not imply an outcome that has not been confirmed.
For each item, record the business purpose, responsible owner, next action, dependency, required-ready point and last meaningful update. Keep sensitive information in the organisation’s approved systems and limit access according to need. The queue itself should help people coordinate work; it should not become a repository of unnecessary personal or payment details.
Review stale items and resolve them with the campaign owner. A request can be paused because information is missing, a review is pending, or the campaign itself has changed. These are different reasons and should not be blended into a vague “in progress” status. Clear statuses help the team decide whether to follow up, wait, escalate through official support, or remove the item from the active queue.
Queue visibility also helps prevent duplicate requests. Before starting preparation, check whether the organisation already has a suitable, authorised account for the stated purpose. That is a process check, not a reason to share access improperly or disregard account-structure rules. Follow the platform’s requirements and the organisation’s controls when deciding whether an existing account can be used.
Report queue health to a manager
A useful report explains whether planned campaigns can be supported, where work is waiting and what decision is needed. Summarise incoming demand against available capacity, identify the stage creating the greatest delay, and distinguish internal work from external review. Include accounts that are ready, at risk of missing their required-ready point, paused or no longer needed, while preserving the business context for each status.
Report uncertainty honestly. A pending platform review is not a confirmed approval, and an internal estimate is not an external commitment. Explain the assumptions behind lead-time estimates and flag cases where information is incomplete or current platform guidance needs checking. If the team’s capacity cannot meet confirmed demand, make the gap explicit and present practical choices: adjust campaign timing, reduce or reprioritise requests, or allocate authorised staff capacity.
Close the report with actions, owners and next review points. Examples include collecting missing approved information, checking a platform’s official guidance, following up through its support channel, or asking a campaign owner to confirm whether a request remains necessary. Avoid reporting account volume as a success measure on its own. The healthier queue is the one that connects appropriately prepared accounts to real campaign needs, exposes delays early, and stays within platform rules.