The Lead Was In Slack. That Wasn't The Same As Following Up.

On a Thursday morning call in June, the ops lead at a client in Australia was trying to identify someone who had reached out that morning. The lead had appeared in Slack but hadn’t entered their customer relationship management system, or CRM. She had a mobile number. She didn’t know who it belonged to.

“So it comes to Slack, thank God. But, like, it hasn’t entered into [the CRM]... I actually don’t know who it is.”

This was a software business with a small sales team. A notification had arrived, but the person behind it still had no CRM record and wasn’t on anyone’s speed-to-lead timer. That’s the gap I want to look at here: the distance between receiving an enquiry and someone taking responsibility for it.

I was building this team’s lead capture, so I was involved in the work, not just hearing about it afterwards. On June 25, we discussed the missing lead and a six-hour speed-to-lead goal. On July 2, a test lead showed up in about a minute during the first live test, and the ops lead still scored that test at 50% because the venue information hadn’t loaded.

That last detail matters. If I only told you about the minute, you’d get a much better impression of the build than the test deserved.

What The Notification Didn’t Tell Us

The team had run two weeks of cold outreach that included videos. On the June call, the ops lead raised another concern:

“Probably a lot have watched the [videos] from the cold outreach that we did those two weeks and haven’t been contacted.”

We didn’t have a count. I can’t tell you how many leads went without a call, or what those leads might have been worth. Her concern was that there were people to follow up with, and she couldn’t confidently say that had happened.

The distinction is worth keeping. A video view is evidence of a view, not proof that someone wants to buy. But the team wanted to act on those views. The question was whether that intended action had become anybody’s actual work.

For the lead in Slack, the notification proved that a message reached Slack. It didn’t prove that the CRM had a usable record or that a salesperson had taken it on. Treating those as separate checks gives you somewhere useful to investigate. Treating the notification as the finish line leaves the missing record out of the picture.

There was another failure discussed that morning: a billing webhook hadn’t fired, and trials the team thought had started hadn’t actually started. They made an emergency fix. I’m not saying the lead problem and the billing problem had the same technical cause. They did raise the same practical question: what evidence would show that the thing we expected had actually happened?

For the enquiry, that meant looking beyond Slack. For the trial, it meant checking whether the trial existed, rather than assuming the billing event had started it.

The Stars Were Part Of The System Too

Earlier in the June call, the ops lead explained the stars she’d added to CRM cards:

“I actually just put these stars on yesterday so that I knew who was sort of like ready to be followed up.”

I wouldn’t dismiss that as someone using the software badly. The stars were her way of answering a reasonable question: who needs attention now? Any replacement I built needed to answer that question at least as clearly.

There was a harder adoption problem as well. She reported that a new sales rep had tried the system and said, “I can’t function like this.” She said she’d do the selling herself while the system was being built. That’s one reported experience, not a survey of the whole team, but it’s a useful test for the build: could another person pick up the work without needing the founder to explain it?

The stack already included a phone system, Slack, a CRM and a cold email tool. My read of this case isn’t that another tool was necessarily missing. The missing CRM record and the hand-drawn stars gave us more specific things to work on: getting the lead into the system, then making the next action visible.

If you’re reviewing your own setup, I’d start with that distinction. Ask the person doing the follow-up how they decide who to call. If they show you a workaround, put it in your notes. Don’t design it away until you’ve understood what job it does.

What We Agreed, And What We Actually Tested

The June discussion included a goal of calling within six hours of a lead being put into the system. It also included finding past leads who had watched the outreach videos and hadn’t been contacted. Those are different pieces of work, and I’d keep them separate in a fix plan.

One is about the next lead. The other is about finding people already missed. A successful test of a new flow wouldn’t, by itself, tell you whether the earlier viewers had been followed up with.

We also agreed on daily check-ins of about ten minutes so we were at least checking progress. Then came the July 2 live test: a test lead showed up in about a minute, the venue information didn’t load, and the score was 50%.

Speed and completeness needed separate checks. In this test, arriving quickly didn’t mean the record had everything it needed. If the acceptance test had only been “did the lead appear?”, we would have missed the reason for that 50% score.

The July call also set a maximum of 24 hours before a hot lead’s next action. I would record that separately from the six-hour goal, rather than blend them into a vague promise to follow up quickly. Six hours was the speed-to-lead goal; 24 hours was the backstop for a next action. Neither is a universal benchmark I’m asking you to adopt.

I don’t have a measured recovery result to attach to this story. The material here establishes the problems, the agreed actions and an incomplete first test. It doesn’t establish that every missed lead was recovered or that the changes increased sales. I want the useful part to be the inspection you can repeat, without turning unfinished work into a case-study win.

Build A Leak Map You Can Check

Here’s how I’d turn this case into a review of your own business. I call the worksheet a Leak Map. I haven’t rolled it out across other teams yet. It’s the check I’d run after seeing this one.

Start with one route an enquiry takes. Write down where it arrives and follow it through to a human action. Use the actual inbox, channel or form name, not just the name of the software.

• Arrival: The exact place an enquiry first appears. The lead reached Slack. Where should it have gone next?

• Owner: One person responsible for checking that handoff. The lead wasn’t on anyone’s timer. Who would notice and take it on?

• Window: When a human action is due, with a defined clock start. The team discussed a six-hour goal. What event starts your clock?

• Proof: The record that shows the action happened. A Slack message wasn’t evidence of a CRM record or a call.

I’d add a link or reference to the enquiry you’re checking beside that row. Then fill the row from evidence, not from how the workflow is supposed to operate. If you can’t establish the owner, write “unknown”. If you find a call log, link it. If you only find an internal notification, don’t label it a customer response.

That also makes the map more useful to someone who wasn’t in the setup meeting. They should be able to open the evidence and understand what’s still outstanding, rather than take your word for it.

Be explicit about the clock. In the June case, the stated six-hour goal referred to the lead being put into the system. For your own review, choose and document the event you mean. An enquiry arriving and a CRM record being created are separate moments in this story. I’d record both timestamps where available so a late record doesn’t disappear from the review.

Test It Without Giving The System A Perfect Lead

The July test gives us a concrete starting point for a better acceptance check: don’t stop when the lead appears. Check whether the information needed for the next action appears with it.

For your own workflow, I would run a clearly labelled test through the real intake route, using contact details you control. Agree the expected result beforehand and make sure the test won’t accidentally contact a customer. Then inspect what actually happened at each step.

Here’s the test note I’d use. Fill in the blanks from your own workflow.

Enquiry Handoff Test

Intake route and test reference:

Arrival time at the intake:

CRM record link and creation time:

Information required for the next action:

Missing or incorrect information:

Responsible person and due time:

Human action taken, with evidence:

If the handoff fails, who checks it and where?

I’d include a test with an incomplete input as well, because the June lead had a number but no name. Decide what should happen in that situation before testing it. Perhaps your process needs a person to resolve the missing information. If so, write down who that is and how the unresolved item becomes visible to them. Don’t quietly require every incoming lead to be complete just to make the test pass.

Keep the observations separate. “Record created, required information missing” is more useful than “mostly working”. So is “notification received, no CRM record found”. Both descriptions point to a specific place to investigate, and neither implies a customer was contacted.

For an AI-assisted step, use the same note. In this case, the team was using Claude, and the ops lead had also described the gap between it sounding as though it was building successfully and the result being usable in practice. I would judge the enquiry handoff by the resulting record and human action, not the explanation the assistant gives about its work.

Check The Earlier Leads Separately

After testing the new route, I’d open a separate review for older enquiries. That follows directly from the June next step: find the past video viewers who hadn’t been contacted. Don’t let the new-flow test stand in for that review.

For a route you’re checking yourself, choose a lookback period and write it down. Pull the arrivals from the intake source, then compare them with the records and activity you can actually find. Starting from the CRM alone would leave out precisely the kind of lead we saw in June: one that arrived elsewhere but never entered it.

Use “no contact evidence found” when that’s what you mean. Before contacting anyone, have the responsible person check whether the conversation moved somewhere else and whether follow-up is still appropriate. The purpose is to resolve uncertainty, not turn a missing log into an automatic message.

If you only complete one row of the map, make it a row you can defend. Open the original enquiry and follow it through. Who took it on? What did they do? Where is that recorded? If something is missing, give that unresolved item an owner rather than marking the whole route fixed.

That’s the review I’d take from the two calls. In June, the enquiry existed in Slack without a usable CRM handoff. In July, a faster arrival still came with missing information. I’d keep checking until the next person could use the record and the intended human action was evidenced, not just until a notification arrived.

What I Got Wrong Before

I used to think the fix for lost leads was more automation. Better triggers, smarter routing, an AI that writes the follow-up.

For this case, I’d put the ownership rule and the recovery list first. Then test the automation against the work someone actually needs to do.

If you know an ops lead who’s still starring CRM cards to remember who to call back, send this to them.

Dhruv