BlogPlaybook

Building a client request process that survives growth

A shared Slack channel with a client usually ends up carrying two different things. One is conversation, which is why you opened it. The other is requests for work, which is what makes it a problem.

How the requests actually arrive

They arrive as messages. Some are explicit, some are a sentence at the end of a call, some are a forwarded email with "can we do this by Friday" on top. None of them are in your project tool when they arrive.

So somebody puts them there. In every agency we have set this up for, that somebody is one person per client relationship, and it is rarely a formal part of their job. They read the channel, work out which messages are requests, and create the items. An agency running twelve client relationships has twelve of these arrangements, in twelve different places, each one held by a different person.

The arrangement is visible when that person is on leave. The channel keeps filling, nothing enters the board, and the team plans a week without knowing what is in it.

The time spent switching

Harvard Business Review tracked 137 people across three large companies and found them switching between applications around 1,200 times a day, spending just under four hours a week reorienting after each switch, or about 9% of working time. Transcribing requests from chat into a project tool is that switch, repeated, performed by the people whose hours you sell.

There is a second effect that does not show up as time. A request in a Slack thread is not attached to a budget, an owner or a deadline. The client considers it submitted and starts waiting. The agency has no record of it. Both parties are being reasonable, and they disagree about whether anything is happening.

What we build instead

The channel stays. Clients keep talking to you in it, and the relationship is worth more than the tidiness.

What replaces the transcription depends on the platform.

On monday.com it is a form, native or a Jotform feeding a board, asking for the client, the requester, the work, the date needed, the project or retainer it belongs to, and any file needed to start. On submission it creates the item on the client's board, assigns the account owner, sets the deadline and links it to the parent project.

On platforms like Teamo we build the client a portal instead. They log in and submit requests, and they can also see and edit their own projects and data, and comment directly on work in progress. For a retained client that difference matters, since a form is a one-way submission and a portal is somewhere they come back to. Either way the requests, edits and comments land in the system your team already works in, so nothing gets retyped.

Enforcing it

The system only works if requests sent through the channel do not become work. That rule is easy to write and hard to hold, because the person who used to transcribe messages will keep doing it as a favor, and clients will use whichever route produces results.

Two things make it hold. The account owner replies to channel requests with the form link rather than the answer, consistently, including for clients they like. And the form is genuinely faster than writing a paragraph, which means keeping it short and pre-filling everything the system already knows.

It is easier to establish at the start of an engagement than to introduce to a client who has had direct access for two years. For existing clients, the usual approach is to introduce it alongside something they gain, such as a status view or a monthly report, rather than as a new restriction.

When this is not worth doing

If a client sends you a handful of requests a month and one person handles all of them, the form adds a step and removes very little. The case for it grows with request volume, with the number of people who touch a request, and with how often you have scope disagreements.

Retainers with an agreed monthly allocation are where it pays fastest, because the form gives you a count of what was asked for against what was bought.