Network or in-house: handing over programme responsibilities
Build a partner programme handover: task owners, accepted deliverables, incident rehearsals and a reversible exit, with two worked scenarios and templates.
Choosing a network or running a partner programme with your own team leaves an operational question unanswered: who receives tomorrow’s creative request, detects a missing event and tells partners that something has changed? A promise to “manage the programme” can leave substantial work without an owner.
This guide helps advertisers transfer responsibilities between their team and an external provider. The deliverables are an agreed responsibility card, a handover pack, an acceptance record and a return plan. The general comparison of approaches covers the initial choice. Here the question is whether your chosen arrangement survives exceptions. This is neither another platform ranking nor a general lead-review procedure.
Apply the method to permitted products after checking the relevant country, traffic source and onboarding conditions. Both scenarios are fictional rehearsals, not customer case studies or examples of offers available in AffiliateCore. Check commercial terms in your account and the provider’s current proposal.
- 1. Separate technology, partner access and staff work
- 2. Assemble the starting pack before discussing the handover
- 3. Create a responsibility card for each boundary
- 4. Accept the pack instead of merely forwarding files
- 5. Rehearse exceptions before moving live work
- 6. Worked scenario: transferring part of the work to a network
- 7. Worked scenario: bringing work back in-house
- 8. Agree exit and return arrangements before starting
- 9. Check readiness through actions
1. Separate technology, partner access and staff work
Do not assign “everything” to the network. An arrangement may combine access to partners, software and account-management work. Confirm each component separately. An in-house programme can also use external software: owning partner relationships does not require building your own tracker.
Awin describes self-management and team-support options. PartnerStack describes a platform and partner discovery. These primary sources were checked on 20 October 2026. A service category does not establish your service scope, country eligibility or required integration. The templates below are our editorial method, not these companies’ official requirements.
For a first implementation option, prepare an advertiser proposal for our CPA network, AffiliateCore. Agree the product, allowed sources and actual onboarding process first. Having an account does not establish dedicated management, automatic transfer of agreements, partner migration or incident handling under this guide. Keep the documents in your own working tool unless another process has been confirmed.
2. Assemble the starting pack before discussing the handover
Name an internal programme owner, a technical contact, a partner-communication owner and a person authorised to accept changes. Give each a deputy with the necessary permissions. A small team may combine roles, but each task still needs an identifiable person. “Marketing” or “support” without an addressee is insufficient.
Prepare the product and market description, current terms, allowed sources, material inventory, event map and open questions. For an existing programme, include current partner agreements and outstanding obligations. Share access only with people who need it. A demonstration pack should contain no customer contacts, secrets or payment details.
At the first meeting, follow one specific creative through the process: who receives the request, who may approve a product claim, where the version lives and who informs the partner? Repeat the exercise for an event-delivery failure. If people name different repositories or decision-makers, the flow is not ready to transfer. Leave with a discrepancy list and owners, rather than an oral assurance that everything is supported.
3. Create a responsibility card for each boundary
Use separate cards for partner onboarding, creative review, technical incidents, terms changes, reconciliation and termination. Do not compress these into one line called “programme management”.
Responsibility-card template:
- Task and the event that starts it: ___
- Scope being transferred; work retained by the advertiser: ___
- Executor, acceptance owner and deputy: ___
- Required inputs and applicable terms version: ___
- Deliverable that can be demonstrated: ___
- Evidence location and authorised viewers: ___
- Agreed response time, starting event and time zone: ___
- Escalation recipient and action while waiting: ___
- Conditions for stopping, restarting and returning the task: ___
For example, the network gathers placement information and forwards the request, while the advertiser decides whether a particular product claim is acceptable. This is an illustrative allocation requiring agreement. Acceptance requires a link to the approved creative version and acknowledgement from the recipient. “The manager read it” does not prove that the partner received that version.
Ask whether a deputy could continue without access to the original owner’s private conversation. If not, add the decision reference or missing access. Do not substitute a shared administrator account for appropriate permissions.
4. Accept the pack instead of merely forwarding files
Create an inventory with object name, version, owner, permitted recipient, transfer method, readability check and unresolved question. Give each object a state: accepted, needs completion or outside the handover. These are states in your own register, not promised platform buttons.
The recipient should open the current material, explain its purpose and complete a related practice task. A file called “final” without an effective date is not enough. Preserve history because existing placements may refer to earlier agreed terms.
Handover-message template: “We are transferring [task] from [time and time zone]. The applicable version is [link]. Open requests are in [register]. Until acceptance is confirmed, [person/role] remains responsible. Please confirm access and complete [check]. Questions go to [contact]; escalation goes to [contact].”
Agree separately which data may be transferred at all. Access to a service’s partner directory does not establish permission to export contacts and invite them elsewhere. Check applicable agreements and processing grounds. If permission or a transfer method is unresolved, exclude that data from the rehearsal and keep the task open.
With your proposal prepared, you can register as an AffiliateCore advertiser. Use the pack when preparing your offer; product eligibility and the actual onboarding process require separate confirmation.
5. Rehearse exceptions before moving live work
Run a tabletop exercise with fictional cards, without payable fake conversions or messages to real partners. Technical tests should use only a previously agreed safe environment. If none is available, keep the exercise document-based.
Ask the executor to handle a routine creative request, a missing-event report and a landing-page change. Watch more than the answer: who learns about the problem, who may pause the affected route, where is the history kept and who authorises recovery? A completed rehearsal produces a repeatable handover with recipient acknowledgement.
Do not expect a network to repair your form if that work is outside its agreed scope. Do not assume that the developer owns partner communication merely because they fix the fault. Defer acceptance if the task bounces between parties, nobody acknowledges receipt or diagnosis requires excessive personal data.
6. Worked scenario: transferring part of the work to a network
Starting point. A company provides an ordinary class-booking service. Its product team retains control over claims and the landing page. Under the fictional agreement, an external provider receives partner requests and coordinates materials. For an AffiliateCore implementation, the advertiser first discusses its proposal and the available working process; dedicated support is not assumed.
Materials. The programme folder contains a “request a demonstration” brief, approved wording, allowed-source descriptions and a technical escalation card. The advertiser’s manager decides product claims, an engineer owns the form, and the agreed coordinator handles partner messages. Coordination is transferred; authority to change terms on the advertiser’s behalf is not.
First run. A fictional partner requests approval for an article about preparing a timetable. The coordinator finds the current brief, submits the draft to the acceptance owner and returns the approved version with its effective date. The request is accepted because the recipient confirms that specific material. A subsequent request changes the promise to “guaranteed full classes”. It is rejected as an unsupported claim, with a request to use approved wording. This is rejection of a creative, not an accusation of partner fraud.
Exception. During the rehearsal, the form stops displaying confirmation. The coordinator records an incident with a technical identifier and the failing step. The engineer reproduces it in the authorised environment. The programme owner decides to pause the affected route and appoints someone to communicate that decision. The coordinator neither labels every enquiry poor quality nor changes final conversion decisions.
Correction and acceptance. The engineer supplies evidence of the fix, the acceptance owner repeats the agreed check, and the coordinator prepares the recovery notice. The first run reveals that the deputy cannot view the incident register. Handover is rejected until access is corrected and the rehearsal repeated. A working form does not resolve an ownership gap.
Decision. Continue when both parties can see the history and the deputy can complete the same route. Expand scope only after separately accepting the next task type. If the provider only collects requests, do not silently add creative approval or authority to change product promises.
7. Worked scenario: bringing work back in-house
Starting point. A document-organisation software provider already has partner relationships and an internal manager. It wants to take daily coordination back from an external service while retaining available software. This changes the operating model; it does not prove a need to replace tracking or move every partner to another network.
Materials. The owner prepares an open-request register, approved material versions and an access map. Each open item includes its original agreement, current owner and next action. Confirm data-transfer rights and permission for continued communication before copying anything. Without that confirmation, the affected part stays with the previous provider pending a decision.
Copy-based check. In an internal practice register, the manager receives a request to update a product screenshot. They find the owner, obtain approval and prepare a response. The request is accepted. A different request asks for the full partner contact list to be sent to a new contractor. That request is declined until necessity and authority are established. Use anonymised codes and a task list for the exercise instead.
Cutover exception. After the fictional handover boundary, a message arrives about a creative approved earlier. Under the agreed procedure, its previous owner continues the matter. The new manager can see the open-task reference and does not create an independent second decision. The arrival time of a message does not cancel the earlier agreement. If the technical system also changes, agree treatment of late events separately before switching, not retrospectively.
Correction and acceptance. The rehearsal reveals that an export contains a final decision but no reference to the material version. The new manager cannot explain the decision to the partner. Acceptance of this part is declined. The previous provider adds permitted supporting evidence, then the team repeats a sample check covering a routine and a disputed request. Guesswork cannot replace missing history.
Decision. Transfer only the accepted scope. Stop routing new tasks to the old process according to the agreed boundary while retaining an owner for open matters. If the new manager cannot recover the basis of a decision, return the affected task to its former owner and record that action. Expand when the internal team can operate without hidden daily help from the previous provider.
8. Agree exit and return arrangements before starting
An exit plan is useful both for network arrangements and for in-house programmes using external software. It does not confer a unilateral right to copy data or end obligations. Agree who informs participants, which materials remain available, who handles old requests and how access closure is confirmed.
Transition-decision template: “Scope to transfer: ___. Accepted objects: ___. Excluded objects and reasons: ___. Boundary for new tasks: ___. Open obligations and owners: ___. Return trigger: ___. Return authoriser: ___. Prevention of parallel decisions: ___. Completion evidence: ___.”
Do not remove the previous owner’s access before the successor has accepted the necessary permitted materials and open tasks. Afterwards, remove unnecessary permissions through the agreed process and verify that the new owner can work. Data retention and deletion follow applicable requirements and agreements, not an arbitrary period suggested here.
9. Check readiness through actions
Before handover, confirm that every task has an owner and deputy; the recipient checked the current version; service boundaries are written down; incidents cannot disappear between parties; terms changes are agreed before application; open items retain owners; exit and return have been rehearsed; and unverified rights or features have not been treated as available.
Your practical assignment is to complete a material-handover card and a technical escalation card, then ask the deputy to work through both scenarios. If questions remain ownerless, reduce the transfer scope and repeat acceptance. A successful rehearsal establishes readiness within the tested scope, not future traffic quality or commercial performance.
Bring your agreed proposal and responsibility list to the AffiliateCore advertiser account and confirm the available offer workflow. Do not treat the handover register, contract review or external-team procedure as built-in features. For the separate task of handling enquiries already received, use the lead-review guide.