How do you currently handle requests from clients?
How do other freelancers handle this?
When a client needs something done, where does the request normally come in?
Email, WhatsApp, Slack, a form, project management software?
I’ve found the actual request is usually the easy part. The messy bit is keeping track of what was asked for, what’s being worked on and letting the client know when it’s done.
I’ve been building Reqst around this problem because I found the usual options either too unstructured or more complicated than I needed.
P.S. If anyone wants to have a look, it’s at reqst.co. Would genuinely appreciate any feedback.
Requests come in everywhere (email, WhatsApp, Slack), and I stopped fighting that. What fixed it for me was one rule: nothing is "real" until it's a line in a single intake list. So when a client pings me on WhatsApp, I reply "logging it now" and paste it into one board with three fields only — what they asked, what I'm doing about it, and when they'll hear back. Two things that cut the follow-up chaos: (1) a standing Friday status note per client, 5 lines, sent whether or not anything shipped — most "any update?" messages disappear once clients trust the rhythm; (2) an explicit "not this week" column that the client can see, so deprioritizing is visible instead of feeling like silence. The tool matters way less than having exactly one place requests land.
This is pretty much the exact problem I’m trying to solve with Reqst. Instead of having to copy requests from WhatsApp/email into a separate board, the idea is to give people one link where they choose what they need and it automatically lands in one place. Really interesting point about making deprioritisation visible too.
For me, requests usually start in WhatsApp or Slack, and the mess begins when details get scattered across different messages. Reqst looks useful because it keeps that simple instead of becoming another heavy project management tool. There could also be a nice AI angle in turning those messy client messages into clear tasks and status updates automatically.
Exactly. I want to keep it much lighter than a project management tool. The AI angle is interesting too, especially turning an unstructured message into something that can actually be tracked without the user having to set everything up manually. Please do give it a try and let me know your thoughts.
For many smaller teams, email and WhatsApp still win because they are where the client already is. The opportunity may be less about replacing the first message and more about making the handoff visible after it arrives.
I’d test a workflow that turns an email or WhatsApp request into a simple shared status view: received, clarified, in progress, ready for review. The client should not need to learn a new project-management tool just to know what is happening.
A useful early interview question might be: “What was the last client request that slipped, got misunderstood, or required a follow-up?” Their answer will tell you whether the main job is intake, prioritization, or client updates.
This is a really good point. I don’t think Reqst needs to replace WhatsApp or email completely. It could be the place you send someone once a request needs to become something trackable. Definitely something I’m going to think about as people start using it.
The strongest part is that you’re targeting the messy handoff after a client request arrives, not just building another task tracker. The key question is whether freelancers feel enough pain around request visibility and client communication to change their existing workflow.
Yeah, that’s the bit I’m trying to validate now. I don’t think people necessarily want another tool, so Reqst needs to make the process noticeably easier than just sticking with email or WhatsApp. Getting real people using it should answer that pretty quickly.
That makes sense. I’d be interested in continuing the conversation outside the thread if you’re open to it. What’s the best email to reach you at?
I’ve mostly seen requests come through a mix of email, Slack, and WhatsApp, and the biggest problem is exactly what you mentioned — the request itself isn’t difficult, but tracking its status becomes messy.
A simple centralized system where clients can submit requests and see what’s in progress or completed would definitely solve that problem. I think keeping it lightweight is important too, since many freelancers probably don’t want a full project management tool just to manage client requests.
Curious to see how you differentiate Reqst from tools like Trello or ClickUp while keeping the workflow simple.
That’s the goal really. Trello and ClickUp are great for managing projects, but Reqst is meant to stay much lighter and focused on the request itself collect it, prioritise it, track progress and close it without making the requester learn a project management tool.
If you want to try the current version, it’s at reqst.co. I’d be interested to know whether that difference feels clear when you actually use it.
The intake channel matters less than having one place where a request officially "exists." What worked for me when I was doing client work: clients could message wherever they wanted (WhatsApp, email, whatever), but nothing was real until I logged it and sent back a one-line confirmation — "Got it: change the pricing table copy, targeting Thursday." That reply does two jobs: it proves I heard them, and it forces me to restate the request in my own words, which catches about half the misunderstandings before they cost a day of work. The status-chasing problem mostly disappeared once I sent a short Friday recap: done this week, in progress, waiting on you. The "waiting on you" line is the one that saves you — most stalled work is stalled on the client side, and putting that in writing weekly stops it from silently becoming your fault.
I ran into a version of this building a marketplace with two sides (hosts and guests) needing to communicate. WhatsApp was the obvious first channel since that's where people already are, but it made requests untrackable — nothing was ever "closed," just buried in a thread.
What ended up working was keeping WhatsApp as the entry point but funneling everything into a structured conversation view tied to the actual booking/request, so nothing lives only in someone's phone. The lesson for me was similar to what's being said here: don't fight where people naturally message you, just make sure it lands somewhere trackable instead of trying to replace the channel itself.
Curious whether Reqst is meant to sit alongside WhatsApp/email as that landing point, or replace them as the primary channel - that distinction seems to make a big difference in adoption.
That’s exactly the distinction I’m leaning towards now. I don’t think Reqst needs to replace WhatsApp or email. It can be the place a request lands once it needs to become trackable.
I’m looking for a few people to try that workflow with real requests before I launch properly. If you’re up for it, have a look at reqst.co and I’d genuinely value your feedback.
Tracking client requests across email, Slack, and messages usually turns into organized chaos pretty quickly. Having a single hub to manage that workflow makes total sense for freelancers. Awesome idea
Yeah, that’s exactly the problem I’m trying to solve. The hard part isn’t receiving the request, it’s stopping it from disappearing into the rest of the messages.
Kinda badly, until recently. Client requests used to come in through 3-4 different channels (like WhatsApp, email, the invite) and stuff fell through constantly. What helped most wasn't a cool tool, just forcing all client comms into one place, even when they initially resisted switching.
Really curious what's worked for others here across multiple clients who all have their own preferred channel.
Interesting that forcing everything into one place worked even when clients resisted at first. I’m leaning towards letting the initial conversation happen wherever they already are, but using Reqst as the point where the request becomes official and trackable.
I think the biggest challenge is having requests come in through too many channels. Email, Slack and WhatsApp are convenient for clients, but they can make it difficult to track ownership and status. If I were building a solution for this, I’d probably focus on making the intake process simple for the client while giving the freelancer one clear place to prioritize, track progress and close requests. A lightweight approach sounds more appealing than another complex project-management tool.
Dexter_Wei's AI-angle comment is close to a problem I'm solving in a different context, turning unstructured natural language into something structured and actionable. the version I've learned the hard way: the tricky part isn't the happy path (clear request, clear scope), it's ambiguous or partial ones. "can you also tweak the header a bit" is not the same kind of input as "fix the broken checkout button," but both would come in through the same WhatsApp/email channel you're describing
for Reqst specifically, curious how you're planning to handle a request that's genuinely ambiguous once it lands, does it get logged as-is and the client/freelancer resolve the ambiguity later, or is there an interpretation layer that tries to structure it upfront and risks getting the scope wrong. that's the exact tradeoff I keep hitting, structure too early and you risk misreading intent, stay unstructured and you're back to the mess you're trying to solve
routinekit's "nothing is real until it's a line in a single intake list" is a great, simple rule regardless of tooling, worth keeping even if Reqst becomes that single list for people
That’s a really good point. For now I’m deliberately keeping Reqst simple rather than trying to interpret what someone means. They choose the closest task from the list and can add context in the notes. If it’s still ambiguous, it gets clarified afterwards. I’d rather not have Reqst guess the intent and potentially get it wrong.
"I'd rather not have Reqst guess and potentially get it wrong" is the same instinct behind confirming before acting, just solved a step earlier, you're avoiding the ambiguous interpretation entirely instead of catching it after the fact. genuinely a simpler, more defensible answer than what I'm doing, less to get wrong when there's less guessing happening in the first place
good discipline to hold onto as it grows too, the temptation to add "smart" interpretation later to reduce clicks is going to be real once you have real usage data showing people picking "closest task" a lot. worth remembering why you chose not to guess in the first place if that pressure shows up.
Yeah, I think that’s a good principle to hold onto. If real usage later shows people constantly choosing the closest task, then that’s a signal to improve the Lists themselves before adding any clever interpretation layer.
that's the right instinct to land on, fix the list before reaching for interpretation. good, durable principle to have written down before you need it
Please do give it a go. Would love some feedback
happy to take a look, though worth flagging upfront I'm not your actual target user, no freelance clients on my end, so I can't give you real usage feedback the way an actual freelancer would. what I can offer is a genuine first-impression UX pass, does the "choose closest task" flow feel intuitive on first use, is the notes field discoverable, that kind of thing. let me know if that's still useful or if you'd rather save the ask for someone in your actual audience