Putting your brand system into daily use

Here is the question that predicts whether a rebrand will survive: who makes the next hundred brand decisions, and what do they use to make them?

Not the launch decisions: those get plenty of care. The hundred small ones that follow: a sales deck due tomorrow, a social post for a holiday, a partnership logo lockup someone needs by noon. If the answer is "they ask the designer" or "they improvise," the brand starts drifting the Monday after launch, no matter how good the identity is.

The brand book fallacy

The traditional answer is a thicker brand book. In our view it falls short, for a simple reason: brand books document what the identity is, but daily work needs to know what to do. A rule like "maintain clear space of one x-height" is true and useless to a marketing coordinator with a deadline and no design tools.

A brand that only lives in a PDF is a museum. A brand that lives in your team's tooling is an operating system.

What a brand operating system contains

When we build visual identities, the deliverable is structured around three layers:

• Decision rules, not just specifications. "When choosing between two layouts, pick the one with fewer elements." "If a message needs a paragraph, it is not a headline yet." Rules like these transfer judgment, and judgment is what keeps a brand coherent when nobody is watching.
• Format kits for the real publishing surface. Whatever your team publishes weekly (social posts, decks, offers) gets templates engineered so that the on-brand path is also the fastest path. Consistency should not depend on discipline; it should depend on tooling.
• A named owner and a change process. Brands evolve. Without an owner, they evolve by accident. One person decides on exceptions, with no as the default answer and strong evidence needed for a yes, and updates the system, so exceptions become versions instead of erosion.

A test you can run this week

Take the last ten things your company published and line them up: the kind of audit of what customers actually see that Jenni Romaniuk of the Ehrenberg-Bass Institute recommends. Ask three questions: Would a stranger group them as one brand? Can you name the rule behind each visual decision, or was it taste? How many required a designer's intervention to be acceptable?

If these answers highlight problems, the logo itself may not be the cause. The team may need practical rules and templates that make it easier to apply the brand consistently.

That is the standard we hold brand work to: not "does it look right in the case study," but "does it still look right in month six, published by someone who never met the designer."

About that "33% revenue" statistic

Any search for a business case will produce the same number within two clicks: consistent branding increases revenue by up to 33%. It appears in agency decks, in pitch documents, and in a great many blog posts that do not say where it came from.

It came from a 2019 survey by Lucidpress (a company selling brand enablement software, now called Marq) of a little over 200 organizations, reporting their own perceptions of their own outcomes. There is no control group, no revenue verification, and no way to separate "consistent branding causes revenue" from "companies doing well can afford to be consistent".

We are citing it deliberately, because the alternative is worse. A studio that quietly repeats a vendor survey while telling clients to demand evidence has a problem. The honest position is that this survey does not establish a causal estimate of the revenue effect of brand consistency, and the case for a brand system does not need one.

The case that does not need a statistic

The argument for a brand system is operational, and you can check it inside your own company this week rather than trusting anybody's survey.

• Count the questions. How many times last month did somebody have to ask a designer, a founder or a "brand person" a question that a written rule could have answered? Each one is a delay, and each one is a decision made by whoever happened to be available.
• Count the rebuilds. How many assets were made from scratch that a format kit would have produced in ten minutes? That is direct, measurable, uncontroversial waste.
• Count the exceptions. How many published pieces last quarter broke the guidelines? Not to punish anybody, but to find out whether the guidelines describe cases the team actually encounters.

Those three counts are the real business case. They are specific to your company, they cost an afternoon to gather, and unlike a survey of somebody else's opinions they cannot be argued away.

What goes in each of the three layers

Decision rules. Not "our tone is confident and human": that is a description, not a rule. A rule is testable: "we never claim a result we cannot show the evidence for", "prices always appear with what is included", "we do not use stock photography of people". Somebody should be able to look at a finished piece and say whether the rule was followed.

Format kits. The five to ten things the team actually makes every month, built as working templates rather than as specimens in a PDF. The test is whether a new person can produce a correct example without asking anybody.

An owner and a change process. One named person, inside the business. When a case appears that the rules do not cover, they decide, and the decision is written into the rules. A system without this step is a snapshot: correct on the day it shipped and drifting from that day forward.

Why the owner has to be internal

An agency can build the system, and we do. It cannot own it. A system whose only owner is a supplier can stop being maintained the moment the contract ends, leaving a PDF that everybody quotes and nobody follows.