Requests from Website, Email, and WhatsApp: How to Collect Them Without Losing Them

A lost request leaves no trace. It doesn’t show up in any report, nobody claims it, and the company only discovers it was lost if the customer insists or tells someone else about it. It’s the difference between problems you can see and problems you pay for: here the cost is invisible, and that’s exactly why it grows.

The fix isn’t a new piece of software. It’s an intake process: every request, whatever channel it arrives from, gets recorded with the same minimum data, assigned to a person, and closed with an outcome. You build it before choosing the tools: the process fits on one page, the tools follow.

Map the channels and check what can actually be connected

The first list is of the ways a person can ask you something today. It’s almost always longer than expected, because it includes personal contact details.

• The website’s contact form, and any different inboxes it writes to (information, support, administration).
• Shared mailboxes and the personal ones belonging to sales reps, which are in fact intake channels.
• The landline, company cell phones, and messages arriving through messaging apps.
• Social media profiles, industry portals, and forms on any marketplaces or third-party platforms.

Next to each channel, write down one thing, and it isn’t technical: if the person who watches it is out tomorrow, who sees those requests? The channels that fail this test are the points where something gets lost.

The minimum data for a request

For requests coming from different places to become comparable, they need the same identity card. A few fields, always the same ones, filled in even when the request arrives by phone.

1. Who: name and at least one contact detail that allows for calling or writing back.
2. What they’re asking for, in their own words, in one line. Not the category: the customer’s own words help you understand later what people are really asking for.
3. Where it came from: channel and, if possible, the source page or campaign.
4. When it arrived, with date and time.
5. Who’s handling it right now.
6. What the next action is and by when.

The first four fields fill themselves in if the channel is connected. The last two are what makes the difference between an archive and a process, and no system fills them in for you.

Duplicates: merging too much is worse than merging too little

The same person writes through the form, then calls, then sends a message. Three lines, one customer. Recognizing that it’s the same request is useful; merging it wrong is quietly harmful, because one customer’s conversation ends up inside another’s record.

• Only merge on a strong match: same email address, same phone number, same VAT number. Full name isn’t enough, and in family businesses, not even surname plus city.
• A switchboard phone number is shared by many people: as a merge key it produces wrong merges. It needs to be used together with another piece of data.
• Weak matches get flagged, not applied: a warning next to the request, and a person decides.
• Keep the contact (the person) separate from the request (the thing they’re asking for). The same customer can have two different requests open, and merging them just because it’s the same person means losing one of them.

The map: request, channel, owner, outcome

An example of an ordinary morning, including the case that complicates everything.

The third line is the case to design for. The follow-up arrives on a different channel and needs to be linked to the existing request, not opened as a new one. But the second line concerns the same customer and is a different matter: merging them because the phone number matches would make the service call disappear inside a sales deal. Same person, two requests, two owners.

Owner, priority, and next action

A request with no name attached belongs to everyone, which means it belongs to no one. Three rules are enough to keep it from sitting idle.

• Immediate assignment, even if provisional. Better assigned to the wrong person, who passes it on, than a request waiting for someone to notice it.
• Priority with few levels and a written criterion: usually a downtime issue for an active customer comes before a new request, but that’s your own choice and needs to be stated.
• Next action with a date. Not “in progress,” a status a request can sit in for weeks, but what needs to happen and when.

The check that keeps everything up is weekly and takes a few minutes: open requests with no next action, and those whose date has already passed. If the list is long, the problem isn’t people’s discipline but the workload: you’re receiving more requests than you can work through, and that’s a decision to make, not a mistake to correct.

When intake breaks without making noise

The worst failure doesn’t generate errors: it generates silence. The form stops sending after an update, the connection between two systems expires, a mail rule moves messages into a folder nobody opens. From the dashboard, it looks like a quiet period.

• Count requests by channel, week by week. A sudden zero on a channel that usually brings something in is a failure, not a slowdown.
• Send a test request from outside at regular intervals, and check that it arrives where it should.
• Ask a customer who calls you how they had already tried to contact you. A “I wrote to you last week and you never replied” is worth more than any report.

What this guide doesn’t cover

This guide covers intake and routing: how a request comes in, who picks it up, and how to avoid losing it. What happens next — the stages of a deal, sales forecasts, managing proposals and renewals — belongs to sales organization and is addressed separately. Choosing which questions to ask in the contact form is also a separate matter, one that precedes this process.