Brand management roles: who proposes, approves and maintains
Assign proposal, expert review, approval, publication and maintenance responsibilities to specific decisions.

Key points
- Define responsibility around decisions and risk.
- Separate advice, final approval and publication.
- Provide delegation boundaries, deputies and handoff evidence.
How should brand responsibilities be allocated?
Begin with decisions that actually occur. For each one identify who drives it, who contributes expert judgement, who gives final approval, who publishes the result and who maintains it afterward. One person may hold several roles, but small company size does not remove responsibility. Consequential changes should have an appropriate independent check rather than self-approval by the creator. The purpose is to make authority boundaries usable: what someone may decide and where they obtain help. The model here is an editorial recommendation, not a statement that a company already operates it or that an internal title proves legal authority.
Why does an organisation with managers still have decision gaps?
Marketing may assume that design owns the wording, design may assume that a manager verified the promise, and sales may interpret “seen” as permission to use it. Someone makes the asset, but nobody establishes the underlying fact. Separate responsibility for doing work from authority over a decision. Identify the person responsible for factual accuracy, the person judging expression and the person entitled to accept an external commitment. Check that these people have the information and capacity they need. Responsibility without authority or time produces a chart, not an operating arrangement.
Step one: list decisions and their consequences
Review recent work and distinguish factual changes, strategic choices, routine assets, exceptions and incident corrections. Record the question, potential impact, evidence required, affected people and decision timing. Updating a contact label and introducing a service guarantee are both copy edits, but they need different treatment. Start with a manageable set of recurring or consequential decisions. The output is a usable decision catalogue rather than a comprehensive job description. Where the boundary is unclear, describe the exact uncertainty instead of assigning it to whichever department receives the request first.
Step two: distinguish deciding from delivering
Atlassian's DACI separates driving a decision, approving it, contributing expertise and being informed.[S1] The editorial extension here is to record publication and maintenance because accepting a statement does not mean it has reached the right channels. GOV.UK also distinguishes overall service ownership from specialist content and design roles.[S2] Adapt these ideas to the size and structure of the business rather than copying public-sector titles. A role definition should explain what judgement it covers, which inputs it receives and which decisions remain outside its authority.
Step three: test responsibilities with a decision card
Use a concrete question: should a service be offered in an additional context? The driver collects demand, feasibility information and affected content. Specialists check delivery, technical and relevant compliance questions. The approver decides the scope and conditions, recording why significant advice was not adopted. Unresolved material issues remain visible. The publisher checks the approved version and channel, while the maintainer records where it takes effect and what triggers future review. Assign every role to an actual person or function and specify cover during absence. Walk a real case through the card; if someone cannot make the assigned decision, change the authority arrangement or narrow the question.
Step four: define routine autonomy and escalation
Routine work may proceed within an established template and current facts. A new service commitment, disputed usage rights or sensitive information needs the appropriate authority. These are example boundaries, not universal legal rules. Replace “escalate important issues” with observable triggers such as changing what customers can reasonably expect or citing an unapproved case. Provide a deputy and a pause mechanism for absence, departure or urgent work. An emergency should change timing and coordination, not silently grant a new authority. Make clear whether a person is being consulted or is required to approve a particular condition.
Hypothetical scenario: sales requests an absolute information claim
Imagine a salesperson asks design to add “All data stays in the customer's environment.” A manager's reaction in a group conversation is not sufficient evidence. The driver identifies relevant products, deployment modes, support tools and possible exceptions, then obtains review from the people responsible for that scope. If the claim is valid only under specific conditions, those conditions stay in the approved wording. The publisher updates the approved deck, and the maintainer identifies other copies in use. This example illustrates a decision process; it does not assert that the claim is true for any company or product.
Step five: make continuity testable
A handoff needs current decisions, sources, active versions, unresolved questions, access arrangements and review triggers. Ask a successor to find an asset, judge whether a sample change needs escalation and complete a simulated publication. These activities expose gaps that a folder transfer can miss. Public explanations may describe roles and processes without exposing internal locations or private contact information. Keep restricted indexes under the relevant access controls. Confirm that someone accepts maintenance responsibility during a role change, rather than assuming that transferring files also transfers understanding and authority.
How can the arrangement be accepted?
Sample recent decisions and check whether the approver, version, rationale and execution state can be identified. Track ownerless issues, decision waiting time and repeated escalations. Use comparable start and end points: time from complete evidence to decision differs from time from initial idea to publication. Set improvement goals from an actual baseline. Faster decisions accompanied by more false promises indicate a poor balance. Conversely, escalation for every minor wording change suggests overly narrow delegation. The aim is sound decisions at the appropriate level, with enough evidence to reconstruct what happened.
Small teams, suppliers and conflicting authority
Small teams can combine roles while retaining independent review for consequential issues. If suitable expertise is unavailable, narrow the claim or obtain the necessary advice. An agency can create and recommend work without automatically gaining authority over company facts. Where two managers hold legitimate authority over different conditions, split the decision or state the required concurrence instead of hiding the conflict behind one approver label. Legal execution authority is also distinct from internal brand approval. A responsibility model cannot override a contract, employment obligation or applicable law.
Test an absence as well: can the deputy access current evidence, identify their authority limit and recognise decisions that must wait? A named substitute without information or authority does not provide continuity. Complete the usable handoff before an urgent request exposes the gap.
Frequently asked questions
Does every asset need a separate matrix? Reuse rules for recurring decision types and add a case-specific card when circumstances differ. Who owns an error? Examine source accuracy, review scope, publication version and authority before assigning the corrective work; blame is not a substitute for repair. Can AI approve? It can organise evidence and flag inconsistencies, but people with the relevant authority remain responsible for commitments, formal approval and publication. A useful arrangement reduces ambiguity without creating a committee for every routine action.
Sources and evidence boundaries
- S1 · DACI Decision-Making Framework
Atlassian · Accessed 2026-10-22
Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.
- S2 · What each role does in a service team
Government Digital Service · Accessed 2026-10-22
Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.