Learn how to stop clients sending requests in different channels by routing every email, chat and DM into one briefed, tracked request. No new rules needed.
Short answer
Don't try to stop clients using email, chat and DMs. Let them keep their habits, and route every message into one tracked request with a brief. Confirm each ask in the same channel it came from, and capture missing details once. That removes the scatter without asking clients to change.
When does forcing one channel work, and when doesn't it?
Forcing one channel works when the people sending requests have no choice, like an internal team using a ticket form. It tends to fail with paying clients, who pick whatever takes the least effort and won't thank you for a rule.
Even small internal teams struggle with it. One practitioner on r/msp describes a team of six getting "xyz has an issue" pings several times a day and replying to each one with a redirect. That's a single anecdotal post, not a statistic, but anyone who runs client work will recognize it. With colleagues you can at least escalate. With a client you can't.
Three things change the answer:
- How many clients you have. With two or three clients, scattered messages are annoying. With fifteen, they cost you real hours every week.
- Who the contact is. A founder who texts you at 9pm won't open a ticket form. A marketing coordinator might.
- How urgent the work is. Urgent asks always go to the fastest channel, whatever your policy says.
Booher Research gives a middle path for multi-channel communication: pick a preferred channel, tell people what it is, and respond in the channel they used. That's a stated preference, not a wall.
There's one honest exception. If you run a one-off project with a single client and a single thread, plain email is probably enough. The comparison of Dora and email covers where email stops being enough and where it doesn't.
How do you centralize client requests without changing client habits?
You centralize on your side of the fence. Pick one place where every request lives, and make every channel feed it. The client keeps emailing, DMing and commenting; you stop having four threads per ask.
Here's the loop, in five steps:
- Name a preferred channel, but accept the others. Tell clients "the portal or email is best," not "anything else gets ignored."
- Turn every incoming message into one request record. One ask, one record, whatever channel it arrived through.
- Ask for missing details once, in the channel the client used. If they emailed, ask by email. If they commented in the portal, ask there.
- Reply and update in that same channel. The client never has to go looking for the answer.
- Keep status, files and sign-off visible in one place. A client portal is the natural home, so the team and the client always see the same state.
Step-by-step setup
Here's what it looks like with a design studio and one client.
On Monday the client emails: "Can you make the logo a bit bigger on the homepage banner?" On Tuesday they DM a follow-up in Slack: "Also, the blue looks off on mobile." On Wednesday they leave a comment in the portal: "Actually, can the banner be shorter too?"
Without a central record, that's three threads, two of which the designer might not see until Friday. With one, it's a single request: banner adjustments, with the logo size, the mobile blue, and the shorter height all in the brief. The designer opens one thing and knows what to do.
This is the same idea the Pedowitz Group makes about marketing consent: keep a single record across email, SMS, phone and mail so every channel honors the same status. Their example is opt-outs, not client requests, so treat it as an analogy. The principle carries over. If every channel reads from one record, nothing falls through the gaps between them.
Here's how that maps to Dora. Dora takes requests in any form: the portal, email, chat, or a connected AI agent. Email intake turns a client's email into a briefed request, and the client can reply to any update from their inbox. If a client sends a DM in a place Dora doesn't listen, paste it into the request yourself, or hand it to a connected AI like Claude to log.
The AI account manager does the part that normally eats your time. She asks the client for what's missing, writes the brief, and keeps the request up to date. Your team's decisions about the work stay with your team.
The brief matters most. A request that arrives complete the first time doesn't get redone. A request that arrives as "make it pop" in a DM gets built wrong and costs a revision round.
The client portal is where all of it lives: requests, files and approvals under your logo and name. Clients don't need to live in it, though. They can use it or never open it.
Onboarding checklist
These are recommendations, not sourced findings. Cover them in your kickoff email or call:
- State your preferred channel and why: "so nothing gets lost in a personal inbox."
- Say plainly that other channels are fine and you'll log the request for them.
- Agree what counts as urgent and which channel to use for it.
- Tell them they'll get a confirmation in the same channel they wrote in.
- Explain that you may ask a question or two before starting, so the work lands right.
- Send the first portal invite yourself, so they see the finished state before they have to learn it.
What do you do when a request arrives incomplete or on the wrong channel?
Log it yourself, then ask the missing questions once, in the channel the client used. Don't bounce it back with "please resubmit via the portal."
That canned reply is common advice, and it's tempting when you're drowning. But it makes a paying client redo their ask, and it teaches them you're hard to work with, not that the portal is good. The cost of logging a request yourself is thirty seconds. The cost of an annoyed client is much bigger.
A good response to an incomplete request looks like this:
- Capture what you have. Log the ask as it arrived, even if it's three words long.
- Reply where they wrote. "Got it, I've logged this as a banner update. Two quick questions before we start: which page, and do you have the new logo file?"
- Ask everything in one message. Five separate follow-ups across three channels is how threads multiply.
- Update the record. Once the client answers, the brief is complete and the work can start.
Other fields reach for similar patterns. Telesign, a messaging API vendor, describes setting fallback options and timeouts per request so messages still arrive if one channel fails. It's a vendor blog promoting its own product, so it isn't neutral evidence. The idea is useful anyway: every request should have a plan for what happens if the first attempt goes nowhere.
For client work, that plan is nudges and sign-off. If a client goes quiet on a question or an approval, a reminder goes out. One-click approvals let them sign off from the portal or their inbox, and auto-approval kicks in after the days you choose (the default is 7). Nothing sits in limbo because someone forgot to reply.
The same logic applies to intake. Having one dedicated place where requests start, whatever route they took to get there, is a long-standing design pattern in software. You're applying it to client work.
A word on evidence: the sources here are mostly blogs and forum posts, so treat them as qualitative guidance. Measure your own numbers instead. For two weeks, count how many requests arrive outside your official intake and how many need a follow-up question. Then route every channel into one request queue with briefs. After four more weeks, check two things: the share of requests that are complete on the first pass, and how many "where did that go?" messages you still get. If both don't improve, adjust the process before you blame the clients.
Want every email, chat and portal message to become one briefed request? Try Dora free: your first client is free, forever.
Related questions
Should I tell clients to stop DMing me?
No. Tell them your preferred channel and why, but keep replying where they wrote, and log the request yourself. A friendly preference gets followed more often than a rule, and the client never feels policed. If a channel really causes problems, like a personal phone number, move the conversation gently rather than banning it.
How do I get clients to use a portal they won't log into?
They don't have to. Clients can send requests and answer updates entirely by email, and Dora keeps the portal up to date behind the scenes. When you do invite them, the invite signs them in with no password. Many clients end up opening the portal anyway, because it's where their files and status live.
What about urgent requests sent by text?
Log them immediately and reply with a confirmation, so the client knows it's in the queue. Agree at onboarding what counts as urgent, and which channel is fine for it. That way a text at 8pm is a known exception, not a surprise.
How do I keep scope creep from hiding in chat messages?
Scope creep thrives when asks live in DMs nobody counted. If every message becomes a request, the extras are visible. Set a monthly request allowance per client, with a warning or queue when they go over, and send extra work as an estimate the client approves in one click.
Can I use Claude or ChatGPT to log requests?
Yes. You can connect Claude or ChatGPT to Dora over MCP, and a connected AI can create open requests for you. That's handy for logging a stray DM or a batch of messages from a call without retyping them.
Sources
