What Is a Brand Operating System? Give Teams Clear Decision Rights

A proposal author should know which case studies can be used, which claims need checking and which parts of the layout can change. 

If those answers still rely on a designer's interpretation of the guidelines, the workflow remains dependent on that designer.

A brand operating system connects brand standards with decision rights, working templates and maintenance. For a growing professional services firm, the useful test is whether people can produce appropriate work without sending every routine choice back for approval.

That is the distinction to establish before buying software or commissioning another brand manual. When briefing a brand governance agency, ask which decisions the engagement will resolve and which decisions your team will still need help making.

What is a brand operating system?

A brand operating system is a practical framework connecting brand standards, decision rights and everyday production. A usable system specifies what people must preserve, what people may adapt and when approval is required. Guidelines, templates and asset libraries support that framework; named ownership keeps the rules maintained.

• Standards define the approved brand expressions.
• Decision rights identify who may adapt those expressions.
• Workflows make the approved choices available during production.

A brand operating system connects brand standards, decision rights and everyday workflows so teams can produce appropriate work within defined approval boundaries.

For a 100-person consultancy, that could mean an approved proposal structure, current evidence for service claims and a clear route for requesting an unfamiliar page layout. The proposal author can work within those boundaries without interpreting the entire identity system.

This guide proposes judging operational usefulness by independent, acceptable decisions. The proposition draws on established ideas about maintaining shared design resources and assigning decision-making roles; it does not demonstrate a measurable commercial return. 

Nielsen Norman Group’s “Design Systems 101” describes the need for ongoing oversight, while Bain & Company’s RAPID framework separates the roles involved in decision-making and execution.

What does a brand operating system add to guidelines and tools?

Brand guidelines describe approved expression: typography, colour, imagery, language and examples. An asset library stores approved files. A template provides a reusable starting point.

The operating system connects those resources to authority and use.

Consider a partner preparing a tender response. The guidelines explain the heading style. The library contains the logo. The template supplies the page structure. None of those resources necessarily answers whether the partner may invent a new service name or describe an unpublished client result.

Those are decisions.

A useful specification therefore adds an owner for approved claims, boundaries for local adaptation and a route for exceptions. The existing guidelines may remain entirely serviceable. Good documentation deserves to stay.

Do we need new software?

No. Start by checking whether the existing document platform and production tools can support current files, sensible permissions and visible ownership.

For a firm producing a small range of proposals, a maintained library and usable templates may be sufficient. 

A platform becomes worth evaluating when a specific requirement exceeds that arrangement: suppliers need controlled access, teams cannot reliably identify current versions, or approved content must be distributed across several working tools.

NNG distinguishes adopting, adapting and creating design systems, noting that greater customisation increases implementation demands. 

That guidance concerns design systems rather than complete brand operations, but supports a useful procurement question: what genuinely needs building?

Do not buy a platform to avoid deciding who owns the content. The ownership problem will be present on the new platform with the files.

What decisions must the architecture make explicit?

Specify the decisions before specifying the platform.

The following architecture is a proposed working model for a professional services firm. The rows describe recurring decisions, rather than departments or software products.

The table needs real owners. “Marketing” is too vague if no one knows who to contact to resolve an exception.

What must stay fixed, and what can partners change?

Fix decisions whose variation would undermine the approved proposition, misrepresent evidence or create avoidable risk. Allow adaptation where professional judgement improves relevance without crossing those boundaries.

For example, a partner can select an approved case study from the manufacturing sector for a manufacturing prospect. The partner should not change the published result to make the case sound more closely aligned with the tender requirement.

Likewise, an editable proposal introduction can address the buyer’s specific concern. An editable introduction should not authorise a different account of what the practice does.

Partner autonomy becomes workable when the permitted choices are explicit. “Use your judgement” needs a boundary.

Who can approve an exception?

Name an accountable decision-maker for each exception category and identify the expertise that decision-maker must consult.

Bain & Company’s RAPID framework distinguishes Recommend, Agree, Perform, Input and Decide. The distinction matters because contributing an opinion is different from holding approval authority.

A firm need not implement a formal RAPID process for routine production. Borrow the useful separation: who proposes, who must be consulted, who decides and who implements?

A new proposal layout may need a brand owner’s decision. A new performance claim needs the relevant subject specialist and any required internal reviewer. A new trading name belongs in a more senior brand governance decision process.

Keep those routes separate—otherwise, a page-layout question and a naming decision end up in the same meeting.

How should exceptions change the system?

Record the request, decision, reason, scope and review point.

An exception approved for one tender should not quietly become permission for every future proposal. Equally, a recurring request may reveal a missing template rather than repeated user error.

For example, if the existing proposal layout cannot accommodate an accessible comparison table, the useful response is to assess and improve the component. Asking each author to improvise repeats the problem.

Nielsen Norman Group’s design-system guidance identifies continuing maintenance as a requirement. Treat exception records as maintenance inputs, not an archive of who broke the rules.

How do you implement a minimum viable brand operating system?

Start with one recurring workflow that matters commercially and is observable. Proposal production is a sensible candidate when partners repeatedly ask marketing to rebuild familiar material.

Choose something else if proposals are already under control and the actual problem lies in recruitment campaigns or client reports. The pilot should address an observed dependency.

Set the entry conditions.

Confirm the positioning before embedding the positioning in templates. If the partners disagree about the target client or the central proposition, settle that disagreement first.

Name an executive sponsor who can resolve ownership disputes and an operational owner who has time to maintain the system. 

Nielsen Norman Group’s “Design Systems 101” describes the value of management support and continued oversight; a handover without maintenance capacity leaves a predictable gap.

Run a proposal pilot.

Take a hypothetical 120-person consultancy with several practice areas. This is an illustration, not an Inkbot Design client.

Assume the consultancy has an agreed positioning, an existing proposal template and approved client examples. The immediate problem is that proposal authors still ask the designer which pages to use and ask partners which claims are current.

1. Observe the current workflow. Follow a proposal from brief to submission. Record searches, questions, approvals and corrections—separate missing information from genuine judgement.
2. Define the proposal boundaries. Identify fixed positioning, editable buyer-specific content and material requiring review. Use examples from the actual proposal types.
3. Build the smallest usable kit. Update the template, connect current case studies and publish the decision routes. Do not rebuild every brochure.
4. Test with intended users. Give proposal authors a realistic brief. Observe where the authors pause, improvise or ask for help.
5. Inspect the output. Check the completed proposal against criteria agreed before the test.
6. Correct the system. Resolve missing guidance, awkward components and unclear authority before extending the pilot.

A successful test needs more than a completed file. The author should be able to explain why the chosen case study was permitted and why a particular claim required review.

“Will this create another approval queue?”

The concern is justified if the proposed system adds reviewers without removing routine approvals.

Make the pilot specify which decisions no longer require individual sign-off. An author using approved content within a tested layout should not automatically need design review for the same choices on every proposal.

Keep specialist review where the content warrants specialist judgement. Removing a designer from routine layout decisions does not remove the need to verify technical claims.

If approval volume remains unchanged, investigate whether the new rules are unclear or whether approvers are unwilling to delegate. Another template will not settle an authority dispute.

“Our partners will never accept a rigid template”

Give partners control where the buyer benefits from partner judgement.

In the hypothetical consultancy, partners can choose relevant evidence, adjust the order of approved service modules and write a buyer-specific introduction. The partners cannot invent results or create a competing practice identity inside a tender.

Test those boundaries with partners during the pilot. A template that obstructs legitimate proposals needs revision. A partner preference that changes the agreed positioning needs an explicit decision.

Roll out only after the pilot produces acceptable work, and the maintenance owner can support continued use.

How do you measure useful independence?

Measure whether people can complete defined work independently, then check whether the work remains acceptable.

Counting assets tells you what exists. Counting downloads tells you what was accessed. Neither establishes that a proposal author made the right choices.

Use a small paired scorecard:

• Independent completion: eligible routine tasks completed without design interpretation.
• Quality failures: reviewed outputs that fail agreed criteria.
• Rework: corrections after a task was considered finished.
• Exception demand: requests for decisions the system cannot yet resolve.

Define “eligible routine task” before collecting the numbers. Otherwise, a change in task complexity can make apparent progress meaningless.

For example, exclude a new service launch from the same category as an update to an established partner biography. Keep the exclusion visible rather than improving the score by quietly removing difficult work.

What would count as failure?

Fewer questions alongside more incorrect claims is failure. Faster completion alongside repeated template workarounds is a warning. An unchanged approval queue suggests the workflow has not achieved the intended independence.

Record the reasons as well as the totals. A user asking whether a claim is supported may be exercising exactly the judgement the system should encourage.

Bain & Company’s RAPID framework helps distinguish responsibility for decisions from responsibility for execution. Use that distinction when investigating delays: the problem may be an unavailable decision-maker rather than a slow author.

Do not attribute revenue growth to the system from a before-and-after comparison alone. Client mix, pricing and market conditions may also have changed. Operational observations can justify improving a workflow without proving a financial return.

Start with the decision that keeps coming back.

A system earns its place when the rules help someone finish appropriate work and reserve escalation for decisions that genuinely need it.

Choose one recurring proposal question. Write down the current answer, the permitted alternatives and the person authorised to approve an exception. Place that information next to the template, then test whether an intended user can proceed.

If the internal team can do this and maintain the result, start internally. An external provider is useful when positioning, cross-practice authority or implementation capacity requires help.

Inkbot Design offers a free Brand Equity Audit™ covering positioning, messaging, visual presentation and visibility, with a written diagnostic identifying priorities. 

The audit can inform the next step; the audit does not replace observing your production workflow.

Today, document the brand decision your team keeps asking someone else to make.