Article

Five Questions Before Lunch: Running a Working Afternoon Without Writing a Single Query

Most afternoons in a sales or support team start the same way. Someone opens the CRM, someone else opens the help desk, a third person pulls up billing, and by...

Five Questions Before Lunch: Running a Working Afternoon Without Writing a Single Query

Most afternoons in a sales or support team start the same way. Someone opens the CRM, someone else opens the help desk, a third person pulls up billing, and by the time the tabs have loaded, the original question has half evaporated. The useful part of the work is still ahead: figuring out which customers need a call, which deals have gone cold, and which tickets are about to breach their deadline.

The Skopx feed post that started this piece lists five questions a team can ask at any point in the afternoon. There is no SQL in them, no report request, and no ticket to file with someone who will get back to you on Thursday. Which customers are late paying? Which deals went quiet? Which tickets are near their deadline? What changed since Friday? Who hasn't heard from us? Each one is a plain sentence, and each one can be answered if the tool doing the answering can reach the right data.

This article takes a different angle on those questions. Rather than repeat what they are, it looks at one of them closely and walks through what a good answer actually requires.

Take One Question: Who Hasn't Heard From Us?

"Who hasn't heard from us?" sounds like a mood check. It is really a data question with a precise definition, and the definition is where most tools quietly fail.

To answer it, a system has to decide what counts as hearing from you. Does an outbound email count? A logged call? A reply from the customer? A meeting on the calendar that was later cancelled? Each choice changes the list. A useful answer names the rule it used, so the person asking can accept it or change it. "Accounts with no logged touch in seven days, counting email and calls but not automated reminders" is an answer you can act on. "A few accounts might be neglected" is not.

Then the system has to know which accounts are in scope. A customer on a renewal that closes next month matters differently from a lapsed trial. Filtering by account status, owner, or contract value turns a long list into the short list a person will actually work through.

Finally, the answer should come with its source. If the list says twelve accounts, you should be able to see which twelve, and check the last touch date for each against the source system. A number that cannot be traced back is a number you will eventually stop trusting.

Why Plain Language Changes the Work

The reason this kind of question is hard to ask in most business software is that the software was built around pre-made reports. Someone decided in advance which views exist, and if your question falls between two of them, you are stuck. Asking a colleague to build a new view can take days.

Asking in plain language removes that bottleneck, but only if the tool translates your sentence into a correct query against the right tables and shows you what it did. A good system makes its reasoning visible: which sources it read, what it filtered on, and what it left out. If the question was ambiguous, it should say so and offer the reading it chose.

That visibility is also what keeps the afternoon honest. When the answer to "which deals went quiet" comes back with the definition of quiet attached, you can disagree with the definition in one sentence instead of discovering a week later that the report used a different threshold.

What to Do With the Answers

Five answers are only useful if they lead to five actions. A reasonable pattern for the afternoon is to take each question in turn, read the result, and decide immediately: send a message, reassign an account, reply to a ticket, or note the item for tomorrow. Most of these decisions take under a minute once the data is in front of you. The time previously lost was in gathering the data, not in deciding what to do with it.

The more important discipline is deciding which actions need your explicit approval before anything runs. Drafting a follow-up email is cheap to review. Sending it to two hundred customers without a second look is not. A sound setup lets the assistant prepare the work, shows you exactly what it would do, and waits for your yes on anything that touches customers or money.

A Practical Starting Point

If you want to try this on your next working afternoon, start small. Pick one question, ask it in plain words, and check the answer against the source for three accounts you know well. If the answer matches what you see, ask the next question. If it does not, look at the definition the tool used and adjust it.

Five questions, asked honestly, will tell you more about the state of your pipeline than an hour of scrolling through dashboards. The point is not to replace the people who know the customers. It is to make sure they spend the afternoon on the customers, not on finding them.