Atlas Ops Revamp
A clear owner for every decision, and tickets that cannot be submitted half-filled.
Innovation & Strategy Analyst · inventor of Atlas · Jan 2026 → present
The work was never the problem. The routing was. So I mapped who owns each decision and put that map in front of the queue.
In sixty seconds
A clear owner for every decision, and tickets that cannot be submitted half-filled.
- was
- A ticket bounced between teams until someone chased the missing field.
- now
- The gate rejects it at intake, and every decision has a named owner.
- the decision
- Bounce at intake, not mid-work: a stricter form costs the requester a minute and saves the team the day a half-filled ticket used to lose.
- the run
- the gate runs on the pitch, chapter one
- where it sits
- the map →
Opened · One ticket
A ticket for a creative change arrives with no due date and no client. It bounces twice before anyone can start.
A planner needs a display creative resized. The ticket lands with the wrong team, comes back for a destination URL, goes out again, and comes back for a due date. Three people have touched it and nobody has done any work. Multiply by every request the agency handles in a week.
The work was not the problem. The routing was.
Blocked · The cost
Tickets bounced between teams because nobody owned the decision the ticket needed.
Every media agency runs on tickets, and tickets bounce when the decision they need has no owner. The bouncing was the real cost: not the work, the wait between the people who could have done it.
I have not published a bounce rate. The before-and-after routing map and the ownership matrix are redacted for release.
Fixing it meant deciding who decides.
Reassigned · The decision
Map who owns each decision at each step, then put that map in front of the queue.
Inside Atlas I wrote the ownership matrix in the team's own words: for every kind of request, who decides at each step. I rebuilt the request form inside the tools the team already uses, and only after the ownership map was honest did I add the automations. The constraint: nothing could ask a planner to learn a new app.
What I did not do
- A new ticketing app
- Nothing could ask a planner to learn a new app, so the request form was rebuilt inside the tools the team already uses.The gate lives where the work already was.
- Automations before the ownership map
- Only after the ownership map was honest did I add the automations.Start with the routing failure, not the tool.
- Routing a half-filled ticket to its owner anyway
- Bounce at intake, not mid-work: a stricter form costs the requester a minute and saves the team the day a half-filled ticket used to lose.Tickets arrive complete, and the owner is on them the same day.
Then the gate went in front of the queue.
In progress · How it runs
REQ-4471, Print proof, opened.
owner matrixclassifying…
- Print proofS. Chen
- TraffickingM. Rivera
- Budget changeJ. Okafor
- Creative resizeM. Rivera
- ReportingP. Patel
- TaxonomyS. Chen
outcomes
- ✓4469 routed → P. Patel
- △4470 · no due date
Simulated pre-flight gate. Names and clients are placeholders; the routing rules are the real ones.
A request is classified, checked for its required inputs, and routed to its owner, or sent back before it enters a queue.
The run beside this simulates the gate: intake, classification, a pre-flight check for required inputs, then a route to an owner or a bounce to the requester. The names and clients are invented; the rules are the real ones.
One decisionBounce at intake, not mid-work. A stricter form costs the requester a minute and saves the team the day a half-filled ticket used to lose.
When it breaks
- A request arrives without a required input
- the system It bounces to the requester with the missing field named, before it enters a queue.
- seen by The requester, immediately
- Two teams both think the decision is theirs
- the system The ownership matrix names who decides at each step, in the team's own words.
- seen by The owner on the matrix
Then the bouncing stopped.
Closed · The change
A ticket cannot enter a queue half-filled, and every decision has an owner.
No measured change is published yet; when the bounce rate before and after is released it will sit here with its denominator. What changed is structural: the gate rejects incomplete requests, and the ownership matrix names who decides.
A week nowTickets arrive complete, and the owner is on them the same day.
The queue holds work now, not questions.
Next
Do again
Start with the routing failure, not the tool. Automations only after the ownership map is honest.
The gate is the pattern the auditor and the proofing pass share: encode the check a person was doing by hand, and keep a person where judgment is needed. I am looking for an applied-AI engineering role at a company with real operations to automate.
Ask me about
- Why bounce at intake instead of routing a half-filled ticket to its owner anyway?
- Bouncing mid-work is what cost the team the day. A stricter form costs the requester a minute, and a ticket that enters the queue complete reaches its owner the same day.
Built with
Hire me
I'd build this for your team.
I am looking for an applied-AI engineering role at a company with real operations to automate. The résumé is one page.