One ticket, end to end - submit to approved. Tap any step to open the detail.
From “I need creative” to “it’s approved.” This is the exact path your request
travels on the MCR board. Follow the spine top to bottom; tap any step to open its
detail, then collapse it to keep the map clean.
This is really about protecting the automations. The moment a ticket is created, the automations take over: BRAT reads it for readiness, the folder hierarchy is generated, and status and notifications start tracking it. They all key off exact, complete values, so a typo or a skipped field doesn't just look messy, it stops the automations from firing correctly. The form and the Excel template exist to guarantee every ticket lands clean, complete and consistent in one shot. That's what keeps the whole workflow stable.
The Form: the guided path for a single request. Dropdowns and required fields enforce the exact values the automations expect.
The Excel template: for many tickets at once (a whole campaign), one row → one ticket, same guarantees in a single pass. PMs & trained operators only.
Never hand-key rows straight onto the board: piecemeal entry skips the creation automations and breaks consistency.
You fill in: copy-needed? · intended use · brand · the Creative Overview (your brief) · files & references · dates and any print / web specifics.
The board fills itself: requestor details, location and year. Scope, request type and assignee are the fields the form deliberately leaves open: they're set on the board during triage by a brand manager, project manager or trained operator (or the assignee, once someone who knows how to move it forward has what they need). See the next step.
The one rule: give the maker enough to start without chasing you.
Answer:What is it? · Who's it for? · Where's it going?
BRAT checks every ticket the second it lands. It isn't judging your idea, just confirming nothing's missing or contradictory (brief substance, matching fields, attached files actually present, specs for print / 3D / social). It posts a plain-English comment saying exactly what it found, then returns one of three verdicts below.
It re-checks the board once a day. After two passes with no fix, it locks the ticket. That's the cue for a human to step in.
Read the full page →
↓ BRAT returns one of three verdicts ↓
Sufficient
Enough to begin. Moves straight into the work queue for a creative to pick up.
Needs Attention
Something's missing or mismatched. Waits while it's fixed; BRAT says exactly what.
Rejected
Not enough to work with. Pulled off the board; requester resubmits with specifics.
Every ticket, whether from the form or a bulk import, is reviewed by a brand manager or project manager. They set the columns the form leaves open, scope, request type and assignee, and assign who does the work: a designer, copywriter, photographer, videographer or CG artist. These fields are open, not locked: a brand manager can even assign the work to themselves, and a trained operator (or an assignee who knows exactly how to move the ticket forward) can fill them too. Whoever is assigned is notified the moment it lands in their name.
Each reviewer is pinged when it reaches their rung. Approve → it advances; request changes → it drops back to the maker, then re-enters the chain. Solid = always; dashed = switched on only when needed.
The aim is to keep it moving up, but the flow is built to go backward too. Any reviewer can set the status to an earlier rung. For example, a director can send it back to Brand Manager review; the board recomputes correctly and resumes forward once that person approves again. The reverse is also true: skipping the status forward past a rung counts as that rung signing off - the board approves everyone you jump over and keeps climbing; it never circles back to ask them. Full rules.
When the final required approval lands, the ticket flips to Completed. It stays on the board as the permanent, canonical record of the work. That's what year-end reporting and dashboards pull from, so every finished piece lives here.
Throughout, the board keeps everyone in the loop: requester on status changes, assignee when assigned, each reviewer when it's their turn.