Knowing what the client actually approved
Brief and feedback handling across 20 to 30 concurrent projects, where approval status is disputed because it lives in scattered threads.
A branding and design studio turning over under two million pounds, running 20 to 30 concurrent client projects.
A delivered Orchyn engagement. The client is anonymised at their request. The company and the people are not named. The operation, the workflow, the controls and the outcome are as delivered.
The commercial problem
Briefs, feedback and approvals arrive in email, meeting notes, presentation comments and messaging tools. A project manager spends too long turning unstructured feedback into tasks and checking what was actually approved.
The creative team loses momentum when brief changes are unclear. When a client questions whether something was signed off, the team reconstructs the thread across files and messages.
How the work runs before
- A client sends a brief or feedback through one of several channels.
- The project manager reads email, notes and comments.
- They build a task list and update the project board manually.
- The client services director clarifies scope or priority.
- The creative team produces work.
- New feedback arrives in a different channel and the history is searched again to confirm what changed.
What makes it hard to automate safely
- The model must not approve creative work, agree a scope change, alter a brief or send an external response.
- It has to tell apart feedback, a new request, an approval and a possible change request. These look similar and have very different commercial consequences.
- Client material is commercially sensitive and access is limited by account and project.
- The client must never receive an automated interpretation of their own feedback.
What we change first
The studio agreed what an approval actually is and where it is recorded. Until that existed, no system could report approval status, because the organisation itself did not have a single answer.
The redesigned workflow
- Client communication from approved channels enters one project timeline.
- The model classifies each item as feedback, request, approval or possible change, extracting the project and the specific item referenced.
- It links every classification back to the original message so the wording is always visible.
- A possible scope change is flagged to the client services director rather than converted into a task.
- The project manager confirms classifications and creates tasks. The approval record updates only on confirmation.
Where the model stops
The model classifies and links to source. It does not approve, agree scope, alter a brief or contact a client. A possible change request is surfaced as a question for a person, never actioned as a task.
What we learned
The dispute was never really about approval. It was that approval had no agreed definition or location. Answering that question was most of the value. It is the part a model cannot supply.