What is the difference between an ad account handover and an onboarding process?

Onboarding is the incoming side: gaining access, verifying the tracking setup and establishing what the account currently does. A handover is the outgoing side, and it produces something onboarding cannot generate on its own, namely the knowledge that was never written down anywhere in the platform. The two are complements, not mirror images, and an account can be onboarded badly even when access was transferred perfectly.

How long should an ad account handover document be?

Length is the wrong measure. Use the stranger test instead: could someone competent, with no way to contact you, make the next budget decision and explain the reasoning? A short document that clears that bar beats a long one that recaps how the platforms work. In practice most of the value sits in the naming decoder, the conversion definition dates, the test log, the policy history and the open risks.

Should the handover file include the account's policy and disapproval history?

Yes, and it is the section most often left out because it reads like an admission of past problems. Every restriction, appeal and disapproval episode teaches something about where the boundary sits for that specific business, and policy standing attaches to portfolios, ad accounts, Pages and domains rather than to campaigns. Without that history a successor can reorganise assets and trigger a repeat of something already resolved.

What should happen to tests that are still running when an account changes hands?

Decide explicitly for each one rather than leaving it to the successor. Record what is being tested, what the control is, the start date and how much data the test needs to be readable, then state whether it should be completed or stopped. Also log the tests already run and abandoned with the reason, because otherwise the next manager will spend budget rediscovering conclusions you already reached.

Who should own the ad account after a handover?

Ownership of the business portfolio and the Google Ads account normally stays with the advertiser, with any agency or contractor attached through partner or manager account links rather than personal user access. That arrangement is what makes a handover an administrative step instead of a negotiation. The specific terms belong in the working contract, so check what yours actually says before a separation is on the table.

Ad account handover checklist for teams

An ad account handover checklist is the written record the outgoing manager leaves behind when a Meta or Google Ads account changes hands, so the next person can run it without reverse engineering years of decisions. It is not the access transfer and it is not a final performance report. It is the pile of definitions, conventions, unfinished work and known landmines that currently exists only in one person's head, moved onto a page before that head stops answering messages.

Handovers rarely fail loudly. Logins move in a day, the file never gets written, and six weeks later the new manager pauses a campaign that was capped on purpose, or reads a conversion number that counts something other than what everyone assumes. Nothing throws an error. The account simply drifts, and the drift gets blamed on whoever arrived last.

The test that tells you the handover file is done

Length is a bad target. Use this instead: could a competent stranger, with no way to reach you, make the next budget decision on this account and explain the reasoning? If the honest answer is that they would call you first, whatever would have been said on that call belongs in the file.

That test rules a lot out. Your successor does not need your philosophy of creative testing or a recap of how lookalike audiences work. They need what is true about this specific account and invisible from inside the interface.

What belongs on an ad account handover checklist

Five categories cover almost everything that gets lost in practice. Write them in this order, because each one makes the next one readable.

The naming convention, written as a decoder

Every mature account has a naming system, and every naming system is self evident to whoever invented it. Do not just state the pattern. Decode it. If campaigns read like PMAX_TR_Q3_FeedA_v2, spell out what each segment means, which values are allowed in each position, and which segments are load bearing because a saved report or an automated rule keys off them.

Then flag the exceptions. Nearly every account carries campaigns that predate the convention and were never renamed, because renaming breaks every saved filter pointing at them. Name those campaigns explicitly, or a successor who assumes the convention is universal will build a report that silently drops them.

The conversion definitions your history was reported under

The incoming manager will verify the tracking setup themselves, and they should. Your job is the part nobody else can do: state what the numbers already sitting in the account actually counted.

For every conversion action that was ever primary, record what event fires it, whether it carries a value, which attribution model and lookback window it was reported under, and the dates that definition was in force. If any of that changed while you held the account, the change date is the single most valuable line in the document. Which model was applied quietly reshapes what every historical chart appears to say, a point covered in depth in multi touch attribution; for the handover you only need to record which one was running and when.

Record the target the account was managed against, and the inputs behind it. A break even ROAS derived from last year's margin is not a fact, it is a calculation with an expiry date, and a successor who does not know the margin behind the number cannot recompute it when costs move. Put the margin next to the target, or show how it was derived so the next person can redo the break even ROAS calculation themselves.

Tests that are still in flight

A handover almost always lands in the middle of something. List every test currently running: what is being tested, what the control is, when it started, how much data it needs before the result means anything, and what you would do with each outcome. Then say plainly whether it should be completed or stopped. Nobody trusts a result from an experiment they did not design, and that judgement is only available to you, and only right now.

Include the tests you already ran and abandoned, with the reason each one stopped. A successor with no memory of the account will otherwise re run them, spend real money learning what you already learned, and report it as progress. Designing tests well is its own discipline, handled in structured ad testing; the handover contribution is just the log of what has been tried.

Policy history and the account's scar tissue

This is the section outgoing managers skip, because writing it feels like an admission. Write it anyway. Record every disapproval, restriction, appeal and disabled account episode: what triggered it, how it was resolved, and what you changed so it would not repeat. If a claim in the ad copy had to be softened, or a product category sits close to a restricted line, that is knowledge with a real price tag attached.

Note which assets carry that history. Policy standing attaches to business portfolios, ad accounts, Pages and domains rather than to campaigns, so a successor who reorganises assets without knowing which one has survived an appeal can undo a fragile peace without seeing it happen.

Open risks, written as risks

Finish with what you would be worrying about if you were staying. A creative set carrying most of the spend and getting old. A landing page owned by a developer nobody has spoken to since spring. A feed that breaks whenever the catalogue is re exported. A payment card that expires soon and belongs to someone who has left. Each risk gets one sentence on what happens if it is ignored, and roughly when.

List what is automated, and by what. If budgets or bids move through platform rules, a script, or an external layer such as automated scaling, the file must name every system with write access and state what each one is permitted to change. A successor investigating a budget that moved overnight will otherwise go looking for a person who does not exist.

A definition change looks exactly like a collapse

Here is why those dates matter. Take an account holding spend flat at 60,000 TL a month. Through April, the primary conversion action was Lead, meaning any completed form. In May the outgoing manager switched the primary action to Qualified Lead, counting only the leads sales accepted.

April reported 300 leads, so cost per reported conversion was 60,000 divided by 300, which is 200 TL. May reported 120 qualified leads, so cost per reported conversion was 60,000 divided by 120, which is 500 TL. That is 2.5 times April, because 500 divided by 200 is 2.5. A successor reading that chart sees performance falling apart in a month they were not present for.

Now suppose the handover file records the one thing nobody else knows: historically, 4 in every 10 form fills were accepted by sales. Restate April under the new definition. 300 leads times 0.4 gives 120 qualified leads, and 60,000 divided by 120 is 500 TL, identical to May. Nothing degraded at all. The denominator changed, and the only artefact capable of saying so is the file you are being asked to write.

That is the whole argument for the document. The successor's instinct on seeing that chart is to rebuild the campaigns behind it. One line recording a definition change prevents a quarter of wasted work.

What the file cannot fix

Two things do not belong in a document. Access is one: it is an operational sequence rather than knowledge, so treat revocation and ownership confirmation as their own scheduled task, not a bullet buried at the end of a file. Judgement is the other, and it does not transfer. Your successor will make different calls than you would have. The file exists so those calls use the same information, not so they come out the same.

Hand it over in person, then step back

Send the file before the meeting and walk through it live, sharing your screen inside the account. Half the real value surfaces as asides while you scroll: the campaign you always check first, the report that misleads on Mondays, the stakeholder who opens the dashboard on Friday afternoon. Let the successor drive the second half, so the questions asked are theirs.

Then agree a short window, usually a couple of weeks, in which you answer questions but do not touch the account. Any longer and the handover never completes. Any shorter and the first billing cycle arrives with nobody able to explain it. When that window closes, the file is the record, and the account is theirs.