Why Do Rebrands Fail in the Second Year?

The rebrand launched well. The site went live on the date it was meant to, the announcement did what announcements do, and for about six weeks every surface matched every other surface. Then a sales colleague sends a proposal built on the old deck template, and nobody in the thread can say whether that is a problem or simply Tuesday.

That moment is where rebrand failure begins, and it is worth being blunt about the cause. Rebrands almost never fail as design. They fail as maintenance. Four mechanisms do nearly all of the damage: assets decay faster than anyone plans for, exceptions get granted and never recorded, governance is written as a document rather than as a set of decisions, and no single person owns the identity once the project closes.

The second year is the real test because the first year still has momentum. People remember the launch, the files are fresh, and the person who ran the project is still in the role. Year two has none of that, and it has new hires, new surfaces, new partners and a backlog of small requests nobody escalated. What survives that is the brand you actually have.

What rebrand failure actually looks like

It does not look like a crisis. It looks like a Monday where the careers page uses one typeface, the product interface uses another, and the invoice template still carries the wordmark that was retired eighteen months ago. Nobody has done anything wrong. Every individual decision was small, defensible and made by somebody trying to finish a task.

By the time it is visible, the identity has stopped being a system and become a preference: something people apply when it is convenient and skip when it is not. That distinction is the whole subject of identity as a system, not a logo file, and it is the frame that makes the rest of this argument make sense. A logo cannot decay. A system can, because a system has rules and rules need somebody to hold them.

The other tell is arguments. When a team starts debating whether something is on-brand, based on how it feels rather than on what was decided, the decisions have gone missing. People are not being difficult. They are reconstructing rules from artefacts, which is a slow and unreliable way to work.

The launch is the easy part

A launch produces two things: a set of decisions, and a set of files that express those decisions on the surfaces that existed on the launch date. That is genuinely hard work and it deserves the fuss it gets. It is also, structurally, a snapshot.

The surfaces that did not exist on that date are the ones that break the identity. A new product screen. A partner portal. A hiring page written by somebody who joined in March. An invoice template generated by a system the brand team never saw. A slide made at eleven at night from whatever was on a laptop. None of those were covered by the launch, because they were not there to cover, and each one gets built by somebody making a reasonable guess. A launch is a snapshot; an identity is a rule that has to keep being applied.

This is why we treat the handover as part of the work rather than the end of it. The deliverable that matters twelve months on is not the visual identity itself but the machinery around it: the source of truth for files, the named owner, the exception log and the cadence on which somebody checks. Most launches ship the first and assume the rest.

Asset decay is the symptom you see first

Asset decay is the drift between the identity as designed and the identity as it exists in files people can actually reach at speed. The design has not changed. What has changed is that the nearest copy of the logo is now the one in somebody’s downloads folder from two jobs ago.

Where the old files survive

Old assets do not live in one place, which is why a single announcement never clears them. They live in the places nobody thinks to audit.

• Email signatures, which everybody edits and nobody reviews.
• Decks saved locally in the fortnight before launch, then duplicated for every new pitch.
• Third-party profiles: directories, app stores, review sites, job boards, event listings.
• Automated documents such as invoices, contracts, exported reports and transactional email.
• Printed material and anything else with a long physical life and no version number.
• Partner, reseller and agency material you do not control and cannot edit.

Each of those has a person attached to it, and that is the useful part. Decay is not abstract. It is a list of surfaces with names next to them, and a list can be worked through in an afternoon by somebody who has been given the authority to do it.

The template problem

Templates are where identity either holds or quietly stops. Most launches deliver the logo, the palette and the type system on day one, then deliver the deck, the document, the proposal and the social templates weeks later, or never. In that gap people improvise, and improvisation is permanent. The improvised deck becomes the deck, because it is the one that has been used to win something.

Structured surfaces age differently from hand-assembled ones, and the difference is arithmetic rather than discipline. A site assembled from structured widgets, which is how Nichevio builds mobile-first profile sites, has a small and countable number of places where a wordmark or a colour is defined. A hand-built deck has one per slide, and every copy anybody saves is a fork of the identity that will never be updated again.

One decay mode is not cosmetic at all. Colour approved on a calibrated screen in a studio can fail badly in a table cell on a laptop in a bright room, and a palette that was never tested against the contrast thresholds in WCAG 2.2 will produce a long tail of accessibility defects that get fixed locally, one component at a time, each fix pulling further from the palette. Test the palette against the standard before launch and the drift never starts.

Exceptions nobody wrote down

The first exception is always reasonable. A regional team needs the wordmark in a second script. A partner requires a horizontal lockup for a co-branded page. The product needs a dark interface variant the identity did not anticipate. Each request has a real constraint behind it and a person who needs an answer this week.

The exception is not the problem. The problem is that it gets granted in a message thread and never written down, so three months later a second request cites the first as precedent, and nobody can tell the difference between a considered decision and accumulated drift. Six exceptions in, the guidelines describe a brand the organisation no longer operates.

When an exception becomes an architecture

The expensive version of this is structural. A team that could not get its offer to fit the master brand gives it a name, then a mark, then a website, and the organisation has acquired a sub-brand nobody approved and nobody funds. That is a brand architecture decision made by default, and it is much harder to reverse than to prevent. Our parent company has set out the small-company version of the same question in brand architecture for a small company.

The rule we apply is unglamorous and it works: an exception is granted only when it is written into the same place the rule lives, with a date and the name of whoever approved it. If it is not worth writing down, it is not worth granting. This also fixes the document nobody reads, because a guideline that accumulates real decisions becomes a record people consult rather than a PDF they were sent once, which is the argument in brand guidelines nobody follows.

The missing owner

During a rebrand there is a project, a budget, a schedule and a decision-maker. Afterwards there is a folder. The agency has finished, the marketing lead who ran it has moved on to the next thing, and the question of who decides whether a request is acceptable has no answer, so the answer becomes whoever replies first.

Ownership is not a committee and not a shared inbox. It is one named person with the authority to refuse, whose refusal holds without being escalated. That person does four things: approves or declines exceptions, keeps the source of truth current, runs the surface sweep on a fixed cadence, and briefs new starters in their first week rather than their first year.

A brand is not what you launched. It is what survives the next few hundred small decisions nobody thought worth escalating.

The owner protects the words as well as the marks, and words drift faster. Within a year a team under deadline will reach for the phrasing it used before the rebrand, because that phrasing is easier to remember. The defence is not enforcement, it is writing lines short and concrete enough that people can repeat them accurately from memory, which is exactly what messaging that people can repeat is about.

The maintenance model that prevents this

None of this needs a large programme. It needs five commitments made at launch, when there is still attention and budget, rather than in year two when there is neither.

1. Name one owner, publicly. A person, not a team. Say what they decide, and say that their decision stands. Do this before the launch date, not after it.
2. Ship the templates with the launch. Deck, proposal, document, email, social and invoice. If a template arrives after people have needed it, the improvised version has already won.
3. Set a retirement date for every old asset. Then make the new file easier to find than the old one. Convenience beats policy in every organisation, every time.
4. Log every exception where the rule lives. Date, requester, decision, reason. This is ten minutes of work that prevents a year of arguments about precedent.
5. Sweep the surfaces on a fixed cadence. Quarterly is enough. Put it in a calendar with a named owner, or it becomes an intention rather than a task.

The sweep is more useful when it is organised by cause rather than by symptom, because the same symptom keeps returning until the cause is dealt with.

Two technical surfaces deserve naming, because brand teams rarely own them and engineering rarely thinks of them as brand. The first is your structured data: the Organization markup on the site carries the name and logo that machines read, and it survives a redesign untouched unless somebody updates it deliberately. The second is redirects. If the rebrand moved a domain, the permanent redirect map is an asset like any other, and it decays when new pages are added without anyone checking the old paths still resolve.

Inside the product, the screens nobody re-checks after a rebrand are the ones nobody looks at during a review either: error pages, confirmation screens, and the blank panels a new user meets before they have any data. Those carry the identity to people at their least patient, which is the case we make in empty states are the most neglected screen in your product.

When maintenance is not the answer

Here is the concession, and it matters. Some rebrands fail in the second year because they should have failed in the first. If the business changed and the identity only changed its appearance, no amount of governance rescues that. Maintenance keeps a correct decision correct; it cannot make a wrong decision right. The symptoms look identical from the outside, which is why how do you know it is time to rebrand is worth re-reading before anyone commissions a repair. Our parent company puts the commercial version of that question plainly in what gets sold when a brand stops working.

The opposite failure is just as real and less discussed. A brand policed so tightly that every small request routes through one busy person produces exactly the same drift, because people stop asking and start guessing. Governance that cannot answer within a day is governance that will be worked around. Build the rules so most questions answer themselves and only genuine exceptions reach a human.

Where we would start

If you are twelve to eighteen months past a launch and something feels loose, resist commissioning new design first. Inventory the surfaces instead: list every place the identity appears, mark which ones are current, and mark who controls each one. That list is usually longer than expected and it settles most arguments on its own, because it converts a matter of taste into a matter of fact.

Then fix the cause rather than the instance. A wrong logo on a partner page is a symptom of an asset source that is harder to reach than a search engine. Copy in the old voice is a symptom of messaging that was never made repeatable. If the inventory shows the identity itself no longer fits what the business now sells, that is a different piece of work, and it belongs in a rebrand and growth reset rather than in a tidy-up.

The first fix, though, is free and takes a single meeting: name the owner. Here is the decision rule to carry away. If you cannot say, out loud, which person would refuse a request that breaks the identity, the identity is already drifting, whatever the files look like. If that person exists but nobody outside your team knows their name, you are one departure away from the same problem. Tell us what is drifting and we can tell you whether it is a maintenance problem or a positioning one.