Implementing an agency tool with named ownership and a workable exit

Implementation is complete only when the agreed workflow works, authorised users can operate it, records can be recovered and the old route is safely retired. A successful login is not acceptance. Set evidence for sign-off before configuration starts.

What to take away

Name a client owner and agency counterpart, and record scope, exclusions and inventory before configuration starts.
Design roles around work, test joining and departure, and give service accounts named owners.
Draw an example record from source to report to prove the data path and reconciliation.
Acceptance should cover functions and controls the implementation can prove, not campaign response.
Handover needs the account inventory, role list, test evidence, known defects and exit export.

Give the change an owner and boundary

Name a client owner and agency counterpart. Record the product edition, accounts, channels, territories, integrations and processes in scope. List exclusions, including historic data or teams that will remain on another system.

Scope and inventory setup

Name client owner and agency counterpart
Record product edition, accounts, channels, territories
List exclusions and historic data
Inventory accounts, tags, feeds, audiences
Inventory creative, reports, orders, credentials
Decide migrate, archive or remain active

Build an inventory of current accounts, tags, feeds, audiences, creative assets, reports, open orders and credentials. Identify the legal owner and operational administrator of each item. Decide what will migrate, what will be archived and what must remain active during a controlled overlap.

Design access before inviting users

Create roles around work rather than copying broad permissions from an old account. Separate routine operation, approval, billing, administration and recovery where proportionate. The NCSC's SaaS security guidance raises authentication, logging, integration and incident-readiness questions for UK organisations.

Test joining, role changes and departure. Store recovery contacts outside a single employee's mailbox. Remove temporary implementation access once it is no longer required, and check that service accounts have named owners.

Prove the data path

Draw an example record from source to report. Include tags or imports, processing, platform fields, agency transformations and the advertiser's system of record. If Google Ads conversions form part of the design, its tracking documentation describes several supported action types. The implementation team must still document the chosen settings, attribution limits and reconciliation.

Where the tool stores or reads information on a device, consult the ICO's storage and access technologies guidance. Give a qualified reviewer the real purposes, consent route and vendors. A test event firing correctly does not establish lawful use.

Run acceptance scenarios

Use representative but appropriately controlled data. Test a new campaign, a rejected asset, a budget amendment, a tracking failure, an export and an invoice query. For every scenario, save the expected outcome, actual result, tester, date and defect decision.

LinkedIn's instructions for exporting Campaign Manager reports show the publisher's available report routes. If that product is in scope, test the required export in the proposed account because fields and access can depend on configuration.

Do not use campaign response as a software acceptance criterion. Early performance is affected by the plan, creative, market and many other factors. Acceptance should cover functions and controls the implementation can actually prove.

Train around decisions

Train users on the work they own: approvals, naming, change records, troubleshooting and escalation. Give finance and analysts their own procedures rather than a buyer's interface tour. Retain a short operating record with screenshots only where permission and security rules allow.

Set review points after launch. Examine access logs, defects, missing records and manual workarounds. A workaround that becomes routine may change the risk or cost assumed during procurement.

Research disclosure and handover

This implementation guide was prepared by desk research on 5 September 2026. No tool was configured, account inspected or migration observed, and no vendor has a material relationship with the draft. The named project owner must adapt the controls and record real test results.

Handover should include the account inventory, role list, configuration decisions, test evidence, known defects, support contacts and exit export. Keep the launch on hold until blocking faults have owners and the required privacy, security and commercial reviewers have approved the implemented design.

Before you act

Name a client owner and agency counterpart.
Record product edition, accounts, channels and integrations in scope.
List exclusions such as historic data or other teams.
Build an inventory of accounts, assets, orders and credentials.
Test joining, role changes and departure.
Set review points after launch.

Common questions

What should be in place before configuration starts?

Set evidence for sign-off before configuration starts, because implementation is complete only when the agreed workflow works, authorised users can operate it, records can be recovered and the old route is safely retired. A successful login is not acceptance, so the owner and boundary must be agreed first.

How should access be designed before inviting users?

Create roles around work rather than copying broad permissions from an old account. Separate routine operation, approval, billing, administration and recovery where proportionate. Test joining, role changes and departure, store recovery contacts outside a single employee's mailbox, remove temporary implementation access and check that service accounts have named owners.

What must handover include?