A Partnership Brief Template for Agencies Seeking Development Support

Use this brief to explain the partnership you need

A useful partnership brief explains your agency’s context, the work you expect, who handles delivery and client contact, how you expect to work together, and your technical, commercial and support expectations. It is for exploring an ongoing or repeatable agency-partner relationship, not a specification for one end-client project.

Use the brief to record what your agency knows and to flag uncertainty, likely demand and constraints. Work through the detailed prompts in the sections that follow with a prospective partner, leaving points that need discussion open until you have agreed them together.

This brief starts a conversation; it does not replace a project-specific scope that defines the requirements, responsibilities and approvals for each piece of client work.

Describe your agency and the work you expect

Give a prospective partner enough context to judge whether your agency’s work and preferred relationship are a practical fit. Keep this at agency level: outline the kinds of development support you may need, rather than trying to specify a particular client project before you are ready.

Complete these prompts before sharing the brief:

• Agency and offer: Describe what your agency does, the services it already provides and the types of organisations it serves. Explain where development work fits into your offer. For example, does your agency lead strategy and design, manage a client’s digital presence, or deliver a broader service that may need technical capacity?
• Work likely to need support: Name the kinds of work you may bring to a partner, such as websites, mobile apps, business software, integrations, migrations or ongoing maintenance. Add a sentence about the business need behind this work, such as extending an existing service or delivering a digital product for a client. Keep detailed requirements for a separate project brief.
• Pattern of demand: Say whether you expect support to be occasional, recurring or still uncertain. Describe any pattern you can reasonably identify, such as requests arising during larger client engagements or maintenance needs continuing after launch. Avoid presenting an estimate as a volume commitment if it has not been agreed.
• What your agency covers: Note which capabilities you already provide and expect to retain, such as design, client account management or project coordination. Identify the areas you may ask a partner to deliver. The division of responsibilities for a specific engagement can be agreed later.
• What a good fit enables: Explain what you want the relationship to make possible for your agency and its clients, such as taking on work that needs development capacity you do not currently have. Be candid about limits: capacity constraints, client expectations you need to manage, or services you do not intend to offer.

Discuss with a prospective partner: Ask what information they would need to assess a specific engagement. Use this discussion to share broad context and identify what further details may be relevant to a specific engagement. For that, you may need to share its objectives, requirements, constraints and decision-making process separately.

Before sending the brief, check that it describes your agency’s actual offer rather than an intended future service, and that the likely work is clear without implying a promise of work. This gives both sides a useful starting point for deciding whether to discuss a particular opportunity.

Set boundaries, delivery roles and client contact

Use this part of the brief to separate the work your agency will lead from the work you expect a development partner to lead. Treat undecided responsibilities as open points to resolve together, rather than leaving either party to assume the other will handle them.

1. Stages where we may need development support:

   Agency to complete: For each stage, mark “agency-led”, “partner-led”, “shared” or “varies by project”: discovery and requirements; design; development; testing; launch; maintenance; and support. Add a note where the expected contribution depends on the client or engagement.

   Agree together: Confirm what each stage includes for a particular engagement, and identify any work that is outside the proposed arrangement.

2. Who is responsible for each activity:

   Agency to complete: Describe who you expect to gather requirements, make technical recommendations, prepare estimates, manage delivery, check completed work and coordinate launch. For each activity, state whether your agency leads, the partner leads, both contribute, or responsibility is not yet decided.

   Agree together: Confirm who makes the relevant decisions and who supplies information or approvals. Do not treat one allocation as applying automatically to every project.

3. Client-facing arrangement:

   Agency to complete: Our preferred client-facing arrangement is “white-label”, “co-branded” or “direct partner contact”. State whether this preference may vary by client or engagement, and describe any existing expectations you need to preserve.

   Agree together: Decide how the arrangement will work for each engagement before the partner contacts the client or is introduced as part of delivery.

4. Communication, decisions and approvals:

   Agency to complete: Set out who will own routine client communication, provide progress updates, collect client approvals, record decisions and raise delivery risks. Name the agency role responsible for coordinating with the partner, if known.

   Agree together: Decide how the partner will share updates with the agency, how decisions and approvals will be recorded, and who should be contacted if work is blocked or the requested scope changes. Clarify who can approve a change and how it is brought to the client.

5. Meetings, contact and access:

   Agency to complete: Indicate whether you expect the partner to attend client meetings, communicate directly with client staff or access client systems. Note any engagement where these arrangements may differ.

   Agree together: Before any meeting, direct contact or system access, confirm the purpose, participants, boundaries and required permission with the relevant parties. Agree who will brief the partner and who will follow up with the client.

6. Approval responsibility and project detail:

   Agency to complete: Explain how your agency expects to review partner work and how client approval will be obtained and recorded. Mark any approval responsibilities that still need discussion.

   Agree together: Keep this brief at partnership level. Develop detailed requirements, acceptance criteria and technical specifications for each client engagement, including who drafts, reviews and approves them.

Before sharing the brief, fill in what your agency already knows and leave unresolved allocations clearly marked for discussion. The aim is to make the working relationship understandable without presenting project-specific responsibilities as settled in advance.

Explain how you expect the work to run

Describe the route you would like work to follow, from the first client enquiry to an agreed piece of development work and its delivery. Treat the points below as your starting preferences: confirm the actual process with a prospective partner rather than assuming it already works the same way.

1. Agency to complete — From enquiry to a defined brief: Explain what you expect to learn before involving a development partner. For example, note the client’s goals, intended users, required functions, existing systems, known constraints and any decisions still outstanding. Say what material you can provide, such as an initial scope, user journeys or existing technical information, and what you need the partner to help clarify.
2. Discuss and agree — The handover: Describe when you would like to bring the partner into the conversation and what information should pass across. Agree how the partner can flag missing information, dependencies or assumptions before the work is planned. Record who will take each follow-up action and where the latest brief will be kept.
3. Agency to complete — Planning and progress: State your preferred way to break work into stages or review points, how you would like progress reported, and what information your client needs from you. Name any client approval steps or other suppliers that could affect sequencing. Avoid promising a schedule until the scope, dependencies and approvals have been discussed.
4. Discuss and agree — Reviews and decisions: Set out how work will be presented for review, who will collect feedback, and how the parties will distinguish a correction from a new request. Agree who can approve work or decide priorities, how decisions and actions will be recorded, and what happens when feedback is incomplete or conflicting.
5. Agency to complete — Working arrangements: Note preferred communication channels and meeting patterns, who should be included in routine updates, and how you want urgent or blocked work raised. Identify any client processes or existing supplier arrangements the partner would need to accommodate.
6. Discuss and agree — Changes and planning impact: Explain how you want a proposed change to be described and assessed before anyone acts on it. Agree how the parties will record its effect on scope, priorities, dependencies or delivery planning, and who must approve the revised approach.

Open questions for the partner: Which parts of this workflow would you change, and why? What information do you need before estimating or planning work? How will you keep open decisions, actions and client-facing updates visible to both parties?

Keep preferences separate from confirmed working practices. After the discussion, update the brief with what both parties have agreed and leave unresolved points clearly marked for follow-up.

Set out technical and operational expectations

Agency to complete: List the systems and services that may affect the work, including the website or app platform, existing business software, integrations, hosting arrangements and any legacy systems. Note what is confirmed, what is only suspected and what a partner will need to assess. For a specific opportunity, explain where information currently sits and which systems need to exchange it.

Agency to complete: Describe the access that may be needed to assess or deliver the work. For example, identify whether the partner may need access to a code repository, hosting account, analytics, a content management system or a client’s existing software. State who controls each account and who can approve a request. Do not include passwords or credentials in the brief.

Agree together: Clarify how access requests will be made, approved, provided and withdrawn, and who to contact if access is delayed or appears broader than the work requires. If credentials or other sensitive information need to be shared, agree the appropriate method before sharing them. The partner should explain what access it needs to assess the work and why.

Agency to complete: Record security expectations already supplied by the client, along with any known restrictions on systems, information sharing or working arrangements. Mark requirements that have not yet been confirmed. Agree together: Ask the partner to identify what it needs to review before accepting the work and to raise any gaps or assumptions. Treat unknowns as matters to assess, not as evidence that a system or process meets a requirement.

Agency to complete: Say whether personal data may be involved, what types of information are expected, which organisations may handle it and at what point in the workflow. Avoid sending actual personal data with an initial brief. Agree together: Clarify who will work out and record the data-handling responsibilities before work begins. Check the relevant responsibilities with an appropriate source.

Agree together, where relevant: Set out how separate working environments will be managed, how credentials and project information will be shared, and what the partner must hand over at the end of its work. A handover might need to cover the systems changed, access arrangements, outstanding issues and information the agency needs to continue delivery. Decide who will check that the handover is complete and where the agreed records will be kept.

Open questions to resolve:

• Which systems or client requirements still need to be assessed?
• Who can approve access, and who handles access problems?
• Could personal data be involved, and who will clarify responsibilities?
• What must be handed back or documented before the partner’s work ends?

Raise commercial assumptions and ongoing support

Use this part of the brief to surface commercial preferences and support needs, not to assume that a rate, payment term or service level is already agreed. Separate what your agency can provide now from what you need to discuss with a prospective partner.

• Estimating — Agency to complete: Explain how you expect work to be estimated, such as by a defined piece of work or after an initial discovery phase. Say what you can provide, for example a client brief, existing designs, access to relevant systems, known requirements and a named contact for questions. Note what is not yet known.
• Assumptions and changes — Agree with partner: How will each estimate record its assumptions, exclusions and dependencies? If a client requests additional work, or new information changes the scope, who assesses the impact and seeks approval before work proceeds? What happens if neither party can estimate an item confidently at the outset?
• Invoicing and payment — Agency to complete, then agree: Describe the arrangement you expect, including who would invoice the client and who would invoice the agency. Explain how partner costs fit into your client billing process and when payment expectations need to be discussed. Confirm the actual invoicing process and payment terms together; do not treat this brief as agreement to terms.
• Likely pattern of work — Agency to complete: Say whether you are considering a one-off project, repeat projects or an ongoing relationship. If future capacity matters, discuss what would need to be agreed for planning it, and avoid presenting possible work as confirmed.
• Maintenance and support — Agency to complete, then agree: Describe what may need attention after launch, such as updates, defects, hosting or changes to the product. Who will receive a request from the client, record it, assess its priority and decide who acts? Agree how urgent issues are handled, what is included in any support arrangement and what remains outside it. Do not imply response times or coverage that have not been agreed.
• Dependencies and open points — Partner to explain; both parties to agree: Ask the partner to identify dependencies, exclusions or assumptions that could affect its approach. Record unresolved questions and who will follow them up before either side relies on the proposed arrangement.

Before sharing the brief, fill in what you know and mark uncertain points as questions to resolve. Commercial and support details are discussion points until both parties explicitly agree them for the relevant work.

Compare responses and decide what to do next

Use each response to test whether the proposed relationship fits the work and the way your agency serves its clients. A confident presentation is not enough: look for specific answers, and note what the partner cannot yet assess without more information.

• Understanding and capacity: Does the partner understand your agency’s offer and the kinds of work you expect? Can it explain which parts of the work it can assess from your brief, and what further detail it needs before estimating or agreeing to take it on?
• Responsibilities: Is it clear which work the partner would deliver and which tasks remain with your agency? Check that handovers, decisions, approvals and responsibility for resolving issues are described rather than assumed.
• Client-facing fit: Does the proposed approach to client contact, progress updates and approvals match the service your agency promises? Identify who communicates changes or delays, and how your agency stays informed if the partner works directly with a client.
• Delivery approach: Can the partner explain how it would move from enquiry and handover into planning, review and delivery? Look for relevant dependencies, the information or access it would need, how changes are handled, and what happens when a decision is delayed.
• Operational and commercial clarity: Are technical responsibilities, access and information-handling expectations understood? Are estimates, scope changes, invoicing and ongoing support described as assumptions to discuss where they are not yet agreed?
• Unresolved points: Record unanswered questions, assumptions to test and decisions that must be agreed before sharing client information or starting delivery. Confirm what information can be shared, who needs access and what approvals are required.

Compare responses against your agency’s actual priorities, such as client control, available capacity, technical coverage or support after launch. You do not need to turn those priorities into a single score: a strength in one area may not make up for a poor fit in a requirement that matters most.

A development partnership is not the only option. For continuing internal demand, consider hiring; for work already covered by a suitable relationship, an existing supplier may be simpler. You could narrow your agency’s offer to work you can support responsibly, or decline an opportunity if you cannot provide the delivery and support it requires. Decide what further discussion would resolve the gaps before making a commitment.

For agencies considering a white-label development relationship, discuss an agency partnership as an optional next step.