Treat a stalled lead as something to investigate
A website inquiry arrives, but nobody follows up. One person says the CRM is too complicated. Another says the notification never appeared. A third thought someone else owned the request. Replacing the software may be worth considering, but the missed handoff has not yet told you what needs to change.
Start with one lead source and one next action. Trace how the work actually moves, including spreadsheets, inboxes, messages, and manual decisions outside the CRM. The aim is to make the current process visible enough that a software recommendation can address an observed problem. This is a practical review method, rather than a diagnosis of every stalled lead.
Choose a narrow lifecycle
“Our sales process” is usually too broad for a first review. “A website inquiry becomes an assigned follow-up task” gives you a beginning and an end that people can inspect. Select a recent example the team is permitted to review, remove unnecessary personal details from shared notes, and walk through it with someone who handles the work.
Separate what you can observe from what someone assumes happened. A form receipt can establish that the inquiry arrived. It does not establish that a record was created or that an owner saw it. Write down where the evidence stops. Those gaps are useful findings, even before anyone knows the cause.
Ask six questions about the handoff
Use these questions to describe the current process. Capture the team's existing answer first, then record any proposed change separately. If two people give different answers, preserve that disagreement until the owner resolves it. A clean diagram should not hide an unresolved decision.
Scroll sideways to see all columns.
| Question | What to record | What to look for |
|---|---|---|
| What triggers the work? | The observable event that starts follow-up. | An inquiry can arrive without entering the follow-up process. |
| Who owns the next action? | A responsible person or role and where ownership is shown. | Several people are notified, but nobody is accountable. |
| What data is required? | The information needed to take the next step. | The owner receives a record that cannot be acted on. |
| What is the response target? | When action is due and what counts as completion. | A notification exists without a visible commitment. |
| What counts as an exception? | Missing, invalid, duplicated, or unassigned work. | The process describes only successful submissions. |
| How is recovery completed? | Who notices, corrects, reassigns, and closes the issue. | An exception is recorded but never resolved. |
Walk through an illustrative inquiry
Consider a service business receiving a project inquiry through its website. This example is a proposed workflow, with no client result implied. The trigger is a confirmed form submission. The required-data check looks for a usable contact method and enough detail to identify the request.
If those details are present, the system creates or matches a customer record, creates the inquiry, and assigns an owner using the team's agreed rule. The owner sees a response target and a clear next action. If the request cannot be assigned, it remains visible in an exception queue with a named person responsible for resolving the assignment.
Now try a submission missing the information needed for follow-up. The inquiry should have a defined path instead of silently disappearing or looking complete. The process might create an incomplete record for review, request clarification through an approved route, or stop for manual handling. Choose the behavior deliberately. Recovery finishes when the issue has been handled and its outcome recorded.
Turn observations into the next investigation
The map may expose several possible explanations. An unassigned lead could reflect an ownership decision the team never made, a routing rule that is missing, or an integration that failed. The visible symptom alone cannot choose among them. Use the evidence to narrow the next check.
Scroll sideways to see all columns.
| Observed gap | Next investigation |
|---|---|
| The team disagrees about who should respond. | Resolve process ownership before configuring the assignment. |
| The form omits information the owner needs. | Review data requirements and the missing-information path. |
| The rule is agreed, but the CRM never applies it. | Inspect the configuration and test the triggering condition. |
| The form succeeds, but no CRM record appears. | Trace the connection, response, and recovery behavior. |
| The required process cannot be represented adequately. | Compare the tool's fit and the alternatives using explicit requirements. |
Compare the smallest useful changes
Once the gap is clearer, compare possible responses. The next step might be a written ownership rule, a field change, a different configuration, a connection between existing tools, or a custom feature. A replacement CRM is another option to evaluate against the same requirements.
For each option, record who would maintain it, what data needs to move, which other workflows depend on it, and how the team would verify the handoff afterward. Make uncertainty visible. If the proposal depends on a product capability that has not been checked, put that verification on the decision list. This keeps the conversation tied to the process the team needs to operate.
Test the exceptions with the people doing the work
Before accepting a change, walk through a normal inquiry and the cases that previously caused confusion. Include missing data, a duplicate submission, an unavailable owner, and a failed connection where those conditions apply. Let the person responsible for follow-up verify that they can understand the state and take the next action.
Keep a short record of the trigger, observed result, remaining gap, and next owner. A test that fails can still make the project more useful by showing precisely what remains unresolved. When the workflow passes its agreed checks, the team has a clearer basis for accepting the change and deciding what to review next.