Reviewing and approving Update Requests

Update Requests are the most direct signal a brand owner gets about how the brand is being used. Each request is a moment the team noticed a gap. The work of reviewing requests is not interruption; it is the working surface of stewardship. This page covers the brand-owner workflow and the habits that keep the request channel productive.

​

The Inbox

Open the Inbox from the sidebar. The Inbox shows every open Update Request, sortable and filterable:

• By section. Group requests touching the same section.
• By age. Oldest first or newest first. Aging requests are flagged after 48 hours, escalated visually after a week.
• By requester. All requests from a specific team member.
• By type. Section edits, Horizon proposals, asset uploads, escalations.

A useful habit is a daily Inbox scan: open the Inbox, sort by age, address the oldest first. Most days the scan takes five to ten minutes.

​

Reviewing a single request

​

Editing before applying

Most approved requests benefit from light editing. The team member proposed a change; you accept the intent but want to phrase it differently, scope it differently, or apply it to a slightly different block. The apply screen opens the affected section in the editor with the proposal staged as a draft change. Edit the draft. Save applies the edited version. The team member is notified with the final wording. This is the most useful editing pattern; the team learns the brand’s voice from how their proposals are edited.

​

Rejecting well

A rejection without a reason is the fastest way to teach a team to stop raising requests. The reason matters more than the rejection. Three patterns for good rejections:

1. State the principle. “We are keeping the palette to four colours on purpose; adding a fifth would change the brand’s tightness. The blue we have should cover this use.” The team learns the principle, not just the answer.
2. Offer the alternative. “Use Primary Blue at 60% rather than a new tint.” The rejection becomes a redirect.
3. Acknowledge the gap. “You are right that this is unclear in the section; I am going to clarify the existing rule rather than add a new value.” The rejection becomes a maintenance trigger.

A good rejection is sometimes the most useful response a brand owner can give. The team member who is told no with a reason understands the brand better than the team member who is told yes by default.

​

Bulk handling

For a backlog of requests, bulk actions help:

• Select multiple. Tick boxes in the Inbox.
• Apply the same response. Reject all with a shared reason, approve all in a single action, reassign all to an Editor.

Bulk handling is best for routine cases (related requests on the same topic). Individual handling is best for substantive ones.

​

Habits that keep the channel healthy

Three habits, in order of importance:

1. Acknowledge within 48 hours. Even a comment saying I will look at this next week keeps the channel trusted. Silence kills the channel faster than rejections do.
2. Reject with reasons. A team trained on reasons learns the brand. A team trained on rejections alone stops engaging.
3. Look at the patterns. A weekly review of recent requests, regardless of outcome, surfaces patterns: sections that generate many requests are sections that need work; team members who raise many useful requests are candidates for Editor role; recurring questions point at glossary entries waiting to be written.

​

When to delegate

On Guardian, the brand owner can delegate first-pass review to Editors:

• By section. Requests on a section route to its Editor first; the Editor either applies, rejects, or escalates to the brand owner.
• By type. Routine requests (typo fixes, link updates) route to Editors; substantive requests stay with the brand owner.

Delegation does not transfer authorship. The brand owner is still accountable. Delegation just removes routine work.

​

Related pages