How to track concierge requests and stop losing them
A concierge operation stops losing requests when every request lives in one place that answers three things without anyone having to ask: what state it's in, who owns it, and when it's due. Email and chat can't do that, because they organize by conversation instead of by request, so one request ends up split across five threads and none of them is the official one. Before you buy anything, those three columns in a single shared sheet solve most of it.
Email and chat organize by conversation, not by request
A concierge request isn't a message. It's something that has to get done, and it crosses several messages on the way. A dinner reservation starts as a text from the client, moves to an email to the restaurant, comes back as a phone call, and ends in a confirmation. Four channels, one request.
With one person handling everything, that works, because the person is the system. She remembers all of it because all of it went through her. The day a second person joins, the system quietly stops existing, and nobody finds out until something drops.
Your inbox groups by sender and your group chat groups by time. Neither one has a spot that says this request is half done and it's due Friday. That's why requests don't get lost inside a message. They get lost between two.
A request with no owner and no due date is already lost
Three fields are enough to keep a request from falling through: status, owner, and promised-by date. Miss any one of the three and the request is an orphan, even if it's written down somewhere. When I built a CRM for lifestyle and concierge agencies, the decision that organized everything else was exactly that: the central object of the system is the request, not the contact.
Status has to be a short, closed list of four or five options, never free text. Received, working, waiting on vendor, waiting on client, confirmed. A bare "pending" kills more requests than anything else, because it looks like someone's on it when nobody is.
The owner is a named person, never a team. A request that belongs to "ops" belongs to no one. And the date isn't the date of the dinner. It's the day you promised an answer, which is usually a good deal sooner.
The real minimum is a shared sheet and one rule
Before you look at tools: one sheet, one row per request, six columns. Client, what they asked for, status, owner, due by, and last update in a single line. That's all. Add columns before the team has used it for three straight weeks and you kill it.
The rule that makes it work is one line and it's not negotiable: if it's not in the sheet, it didn't happen. A request that came in by text and never got entered was never taken. Without that rule the sheet becomes an incomplete summary of work happening somewhere else, and you can't decide anything from it.
Then add ten fixed minutes a day when someone reads the rows due this week and asks about the ones that haven't moved. That ten minutes is what turns a list into a system. A sheet doesn't chase anybody on its own, and neither does a tool.
You buy software when the sheet breaks for a reason you can name
Sheets run out for concrete reasons, not because a spreadsheet feels beneath you. Two people overwrite the same row. You need to know who changed what and when. The client wants to see status without someone typing it out for her. Each vendor should see only their own line. Any one of those is a real reason to move.
As long as the reason is "a spreadsheet looks unprofessional", don't buy. The tool doesn't fix the problem underneath: a team that won't enter requests into a free sheet won't enter them into a paid one either. Before you go shopping, hold your own week up against the signs your spreadsheet has run out.
When you do go shopping, look at how they charge. Almost all of them price per seat per month, so your cost grows with headcount rather than with volume, which matters if your season runs three months and you staff up for it. And check that the tool can hold a request that isn't a sale: in concierge work the money is usually settled long before the job is finished.
Frequent questions
Is a group chat enough to coordinate the team?
It's enough to announce that something changed, not to know where anything stands. A group chat has no status and no owner, only chronological order, and nobody scrolls back two days. Use it for announcements, and keep the status itself in one place people can scan at a glance.
What do I do with requests that come in after hours?
Set one intake rule: whatever channel it arrives on, the request gets entered within the hour and the client gets an acknowledgment with the date they'll hear back. The acknowledgment isn't politeness, it's what stops the client from repeating the request on another channel and leaving you with two rows for one job.
How many requests a week justify setting this up?
It's not about volume, it's about hands. Two people handling fifteen requests a week already drop things. One person handling fifty will hold it all in her head until the week she takes off, and then it falls at once.