Insights / Connected systems
Draw the flow before you choose a product.
On mapping where a request comes from, who takes it on and where it ends before deciding on workflow automation or new software.
A connected workflow is an arrangement in which a request moves from first contact to delivery without getting lost. Most teams try to build that arrangement by buying a new tool, but a tool chosen before the flow is clear only moves the disorder onto a new screen. Draw the flow first, then choose the product.
See the start and the end point
Where does a request come from, who takes it on, and when does it count as complete? The answers to these three questions should be shared before any tool is chosen.
Open three columns on a whiteboard: request, owner, definition of done. For an agency, a request might arrive by email, through a messaging app or in a meeting; the point where all of them become a single record is the real start of the flow. “Done” needs the same clarity: is it when the client approves, when the file goes live, or when the invoice is issued? If people on the team give different answers, the flow has not yet been drawn.
Turn every request into a single record
Disorder usually starts when a request is split into as many copies as there are channels: an email thread, a chat group and a task board, with nobody sure which is current.
You do not have to reduce the number of channels. It is enough for every channel to feed the same record. That record should contain at least:
- who the request came from and through which channel,
- a one-sentence summary of what is being asked,
- the owner and the expected delivery date,
- links to the related files and conversations.
Make handovers explicit
Sharing a file, talking to a customer and an internal task can be different touchpoints of the same job. Define how information moves from one tool to the next, and who is responsible.
A handover is where information is most often lost: from sales to the project team, from design to development, from the team to the client. At every handover, three things should be clear: what is being delivered, who receives it, and what the recipient checks. Where the final file lives, how a client conversation is noted on the task, where an approval is recorded: small questions that, left unanswered, come back every week.
Choose the tool to fit the flow
Once the flow is drawn, the tool question narrows. You no longer ask “which product is best?” but “which tool carries the steps in this flow with the fewest copies?” When evaluating, look at:
- Connections: can it talk to your existing tools through an API or webhooks?
- Permission model: can access be granted by role rather than by person?
- Data location: where is the data stored, and does that fit your data protection obligations?
- Export: if you walk away tomorrow, can you take all of your data with you?
- Simplicity: will the team really use it every day?
Our own hubApps products grew out of this approach: team work, client conversations, file sharing and a company agent were designed as different touchpoints of the same flow.
Design the way back to a person for AI
Where automation cannot solve something or is unsure, do not leave the user in uncertainty. Treat the handover to a human team, its timing and its context, as part of the flow.
An AI assistant can take on a step of the flow: classifying an incoming request, summarising it, routing it to the right person. But every automation has a limit, and that limit should be defined in advance. In which situations does it hand over to a person? Are the conversation history, attachments and customer details carried across? What is the user told about waiting time? Automation with no way back to a person leaves the customer in a loop in exactly the hardest cases.
Start with a small scenario
Pick one recurring task and try it in real use. Once missing information and difficult steps are visible, deciding on the next connection becomes easier.
For example, pick only the revision requests that come in from clients. For two weeks, handle every request in the new way and note where information was missing and at which step work sat waiting. Those notes make the choice of the next connection indisputable. With small, observable steps instead of a big migration plan, the team sees the change as help rather than an imposition.
How do you know the flow is working?
The success of a connected flow can be felt, but it should also be measured. Compare the answers to these questions at the start and a few weeks later:
- How long does it take for a request to become a record?
- How quickly is the first response given?
- How many jobs come back at a handover because of missing information?
- How often do people ask “where is this file?” or “who picked this up?”
If those questions have become rarer, the flow is doing its job. If not, the problem is most likely not the tool but a handover that has still not been drawn.