Writing a Standard Operating Procedure for Ad Account Preparation
Preparing an advertising account is operational work, not a shortcut around platform rules.
- Sections8
Editorial team Spend Ledger
Why document the preparation process
Preparing an advertising account is operational work, not a shortcut around platform rules. A written standard operating procedure (SOP) helps a team handle that work consistently, make responsibilities clear, and give a newcomer a reliable path to follow. It can also reveal where preparation depends on an assumption, an approval, or an instruction that may change.
The procedure should describe the team’s approved way of preparing an account for legitimate business use. It should not imply that preparation guarantees approval, access, delivery, or performance. Platform decisions remain with the platform, and its current terms, policies, verification requirements, and help instructions take precedence over an internal document.
An account may be prepared internally or obtained through an external arrangement. In either case, treat it as a work tool and make sure its ownership, permitted use, access, and responsibilities are understood before work begins. Do not use a purchased or agency-provided account to avoid a restriction, bypass a verification step, or conceal who is responsible for the advertising. If an account’s status or origin is unclear, pause and resolve that issue through the appropriate official channels.
A useful SOP is specific enough to guide action but not so rigid that it repeats outdated platform instructions. It should explain the team’s process, identify the points where current platform guidance governs, and provide a clear route for questions and exceptions.
Define where the process starts and ends
Begin by stating what event starts the process. This might be an approved request to prepare an account for a particular business, campaign purpose, or operating team. Describe what information must be available before anyone begins. For example, the request may need to identify the responsible business, the people who need access, the intended advertising activity, and any required internal approvals.
Next, define what the procedure covers. Account preparation may involve confirming the account’s relationship to the business, reviewing access, recording relevant settings, checking billing readiness, and confirming that the intended use fits current platform rules. State what is outside scope. Campaign strategy, creative review, ongoing optimisation, and account recovery may belong in separate procedures, unless the team deliberately includes them.
Define the end point in practical terms. “Ready” should mean that the required checks have passed and the account is ready for the next authorised workflow. It should not mean that an advertisement is approved, that spending will be available, or that the account will remain in good standing. Those outcomes may depend on platform review and changing circumstances.
Also explain how to handle an incomplete request. The responsible person should know whether to return it for missing information, hold it for clarification, or escalate it. A clear stop condition prevents staff from treating uncertainty as permission to proceed.
Assign owners to the work
List each action with an owner, rather than assigning the entire process vaguely to “the team.” Depending on the organisation, responsibilities may sit with an account administrator, a business owner, a finance contact, a compliance reviewer, or a manager who approves the request. Use role names that match the organisation’s actual structure, and explain who covers a role when its usual owner is unavailable.
For every step, specify who performs it and who confirms completion. Some checks may be completed by the same person; others may require independent review. The SOP should make that distinction explicit, especially for decisions involving business identity, payment responsibility, permissions, or policy concerns.
Set out how access is granted and reviewed. People should receive only the access needed for their duties, through the platform’s supported permission controls. The procedure should say who can approve access changes and who is responsible for removing access when a person’s role ends or changes. Avoid informal credential sharing, undocumented ownership changes, or access arrangements that conflict with platform instructions.
If the account is supplied through an agency or another business arrangement, document the relationship before preparation proceeds. Record who owns or controls the account, who may administer it, who is responsible for billing and advertising activity, and how access can be changed or ended. Put relevant responsibilities in writing. If the arrangement does not clearly permit the intended use, stop and seek clarification rather than assuming the account is available for any purpose.
Write the steps as observable actions
A newcomer should be able to follow the SOP without guessing what a vague instruction means. Use plain verbs such as confirm, review, record, request, and escalate. For each action, state what information is needed, where the responsible person should look, what evidence should be retained, and what happens if the check cannot be completed.
A practical sequence often begins with reviewing the approved request and confirming that it is complete. The assigned owner then verifies that the account is connected to the correct business or authorised arrangement, checks who has access, and confirms that the intended use is allowed under current platform rules. The relevant billing contact can review whether the approved payment setup is in place, without recording sensitive payment details in a broadly accessible procedure or log.
The next actions may include checking business information, required disclosures, account settings, and any permissions or prerequisites relevant to the planned advertising. The SOP should not copy platform requirements from memory. Instead, it should direct the owner to the platform’s current instructions for the specific requirement, then explain how the team records that it was reviewed.
For every step, define what “done” looks like. “Check billing” is ambiguous; “confirm that the authorised billing arrangement is available and that any platform prompts have been addressed or escalated” is more useful. Do not invent settings, interface labels, or platform processes. If the platform changes its interface, the procedure should remain understandable because it describes the outcome to verify, not a possibly outdated sequence of clicks.
Keep records proportionate to the task. The team may need to note the account identifier used internally, the responsible owner, the checks completed, any unresolved issue, and the relevant approval. Store records in an approved place, limit access appropriately, and avoid collecting personal or financial information that the process does not require.
Define the checks that establish readiness
Create a readiness checklist that separates mandatory checks from conditional ones. A mandatory check must pass before the account can be marked ready. A conditional check applies only when the relevant feature, arrangement, or platform requirement is involved. Each item should have a clear pass, fail, or not applicable outcome, with an explanation for the last option.
The checks may cover whether the request is authorised, the business relationship is clear, access is appropriate, required business details are consistent, billing responsibility is understood, and the planned use has been reviewed against current platform policies. Include a check for unresolved restrictions, warnings, or verification requests. If any are present, follow the platform’s instructions and use its official appeal or support channels where appropriate. Do not try to sidestep a restriction by changing identities, moving activity to another account, or hiding links between accounts.
Readiness also requires a defined route for failed checks. The owner should record the issue, pause the process where necessary, and direct it to the person or official channel that can address it. The SOP should distinguish between a correctable internal gap, such as missing approval, and a platform-controlled decision that the team cannot resolve itself.
A completion record should show who performed the checks, who reviewed them where required, and what remains open. If a required item is unresolved, the account should not be labelled ready. Avoid treating a lack of visible problems as proof that every requirement has been met.
Let current platform instructions govern
Platform policies, terms, verification processes, billing rules, and help guidance may change. An internal SOP should therefore point to the relevant official policy and help areas by their general purpose, rather than reproducing detailed requirements that could quickly become stale. The current instructions on the platform govern whenever they differ from the internal procedure.
Make this rule visible at the point where staff need it. For example, a section on identity checks should direct the owner to the platform’s current identity or business verification instructions. A section on access should defer to the platform’s supported permission model. A section on payment should follow its current billing guidance. The team should not infer permission from an old approval or from a process that worked for a different account.
When a platform request is unclear, the owner should pause and consult the official help or support channel. Preserve a concise record of the question and the response or guidance received, subject to the organisation’s recordkeeping rules. Do not ask staff to improvise a workaround, submit inaccurate information, or use documents that do not genuinely represent the business or responsible person.
If requirements differ across account types or jurisdictions, make the SOP tell staff to identify the applicable case and check the platform’s current instructions. Avoid turning one team member’s interpretation into a universal rule without review.
Include an exception and escalation path
No procedure can predict every account state. Give staff a safe way to handle unusual circumstances: pause the affected action, document what is uncertain, and contact the named internal owner or official platform channel. State who can decide whether work may continue after an internal issue is corrected. Make clear that internal approval cannot override a platform decision or policy.
Examples of matters to escalate include an unclear account owner, a mismatch in business information, an unexpected verification prompt, a restriction, a billing issue, or an access request that seems inconsistent with the agreed arrangement. The examples should help staff recognise when to stop, not offer methods for getting around the issue.
For externally sourced or agency-provided accounts, escalation should include reviewing the written agreement and confirming that the account’s use is authorised. If the supplier or agency cannot establish the relevant rights and responsibilities, do not treat possession of access as proof of permission. Resolve the arrangement transparently and use official channels where the platform’s process requires them.
Document the status of an exception without exposing unnecessary sensitive information. The record should make it possible for the next person to understand what has been paused, who is handling it, and what must be confirmed before the process resumes.
Maintain the SOP and provide a plain-text skeleton
Assign someone to own the document. Review it when the platform changes a relevant policy or process, when the organisation changes its account arrangements, or when staff identify a step that is unclear or repeatedly missed. Record what changed and communicate material updates to the people who use the procedure. Remove superseded copies from routine use so staff do not follow conflicting instructions.
A practical skeleton can use these plain headings:
- Purpose and scope
- Start condition and end condition
- Roles and approvals
- Required information
- Preparation steps
- Readiness checks
- Exceptions and escalation
- Records and access
- Platform instructions that govern
- Review and revision history
Keep the language direct, use the same terms consistently, and test the draft with someone who was not involved in writing it. Ask them to follow the process and identify where they would need to guess. Revise those passages before adopting the document.
A dependable SOP does not make platform outcomes predictable. It gives the team a transparent, repeatable way to prepare an account for authorised use, recognise when a check has not passed, and respond to changes without relying on informal habits.