#004 · Log · Systems2026-08-22 · 6 min read

The Request That Never Existed

By Mico PedrigalRev. R.07

A strategy deck was due Thursday. The requester was buried, so she did what everyone does — sent a WhatsApp message to a designer she trusts. The designer was buried too, working a shared inbox where everything urgent lives. Thursday morning she asked where the deck was. He had never seen the request. Not ignored it, not deprioritised it — it had simply never entered the place he looks. Two people did their jobs correctly and the work still didn't exist.

That story runs in every agency I have worked in. It isn't a discipline problem. It's a routing problem, and the fix is architectural.

TL;DR

  • Requests arrived by email, Teams, WhatsApp and shoulder tap. No owner, no status, no record.
  • I built the Creative Request System to consolidate all of it — one intake, one workflow, six automations.
  • Built on SharePoint, Power Automate, Lists and OneDrive. No new app, no new login, nothing to install.
  • Three role-scoped views over one record: requester, designer, creative manager.
  • Files live in the shared environment, not on laptops. Work survives leave and handover.

What was actually broken?

Five things, and only the first is the one people name:

  • Multi-channel submission. Four ways in, so no consistent prioritisation.
  • No visibility. Status, ownership and progress all required a manual chase.
  • Unorganised files. Assets scattered across drives, inboxes and laptops.
  • No measurable data. Turnaround, volume and load were unknowable, so nothing could be optimised — or argued for.
  • Unclear accountability. No record of who owned what, producing both delays and duplicated work.

None of these are solved by asking people to be more organised.

One front door

Diagram contrasting three scattered intake channels with a single consolidated request system feeding three role-scoped views

The channels didn't change — people still work in email and Teams and WhatsApp. What changed is where a request lands. One intake, one record per request, one workflow behind it.

Why it had to live inside Microsoft

This is the decision I'd defend hardest. The company already ran on Microsoft 365, so the system was built where people already were. No new application. No new credentials. Nothing to install, pin, or remember to open. People hate a new app, and they're right to — every additional tool is another tab and another password, abandoned within a month.

A standalone platform would have been a better product and a worse system, because it would have handed everyone a reason to keep using WhatsApp. A request system people route around is worse than none: it fragments the record while appearing to consolidate it.

Mapping the problem to the tools

Layer diagram mapping each responsibility in the creative request system to the Microsoft tool that carries it

The build wasn't the hard part. Deciding what each layer should carry was.

  • Forms and Lists hold the record — a request becomes an object with fields, not a message with a sender.
  • Power Automate carries the lifecycle: six flows covering submission, assignment, review, revision, completion, and collaborator added.
  • SharePoint provides the surfaces, so access control inherits from the org's existing groups rather than being reinvented.
  • OneDrive holds every file against its request, so the asset and its brief never separate.
  • JSON formatting does the interface work — status colour, priority, layout — with no development environment involved.

That mapping is the actual work. Anyone can automate a task. The harder judgment is knowing which layer owns which responsibility, and refusing to solve a data problem with an interface.

What the workflow actually does

State diagram of a creative request lifecycle with the owning role labelled on every transition, showing that only the requester can move a task to complete

Five states, one loop, and an owner on every arrow.

Defining the states is easy. Deciding who may move a request between them is where accountability lives. The rule I'd keep above all others: a designer can send work to review, but only the requester marks it complete. Completion becomes an agreement rather than a claim.

Notification matrix mapping four roles against six request lifecycle events showing which role is notified at each stage

Every state change fires the right notification to the right role, which is why nobody has to chase. Filling in that grid also specifies the access model — who needs to know something and who is responsible for it turn out to be the same question.

Three views over one record

Three role-scoped interfaces over one shared request record, showing what the requester, designer and creative manager each see

Not three systems — three permissions on the same object.

The manager view is where the business case lives. Once every request is a record, you can see volume by month, turnaround by designer, and where the year actually peaks. Resourcing stops being a negotiation about feelings and becomes a conversation about a curve. Seasonality becomes plannable. Individual load becomes visible before someone burns out rather than after.

Where the work lives

Comparison showing design files isolated on individual laptops versus stored against request records in shared team storage.

The most expensive failure wasn't slow delivery. It was files sitting on individual laptops.

A designer goes on leave, a client needs the working file that afternoon, and the only option is to rebuild it. Everything already paid for, paid for twice.

Because delivery runs through SharePoint and OneDrive, every file lands against its request in an environment the whole team can reach. Handovers stop being archaeology. Work survives leave, reassignment and headcount change — a continuity argument as much as a creative one.

The brief is the upstream fix

Diagram pairing each required intake form field with the downstream failure it prevents

The intake form is where creative judgment gets encoded.

A request can't be submitted without the fields a designer actually needs in order to start. Those questions do the work a good creative conversation would do — every time, without needing the conversation.

The effect shows up in scope. Most scope creep isn't a client changing their mind; it's an ambiguity at the start that nobody noticed until week three. Forcing definition upstream is cheaper than negotiating it downstream.

What this does not prove

No visual. The close should be text alone — after seven diagrams, an unillustrated ending reads as the author speaking directly.

There is no AI in this system. It predates the current generative wave and needs no model.

The work was orchestration: mapping a broken process, designing a data model for it, choosing which tool carried which responsibility, wiring six automations across four roles, and building the interface inside a platform never really intended for it — without an external developer or agency.

Generative tooling has since widened what systems like this can execute. It did not supply the thinking. Anyone can point a model at a creative workflow now. The harder and more durable skill is knowing what the workflow should have looked like before anything was automated at all.

04.2Related reading