Field note

A Lead Score Is Not a Prospecting System

We began by asking AI for a shortlist. The useful experiment was turning the hidden work behind that request into an evidence-backed, reviewable workflow.

JC DoradoFounder, ezenciel·6 min read

The question we began with

We began with a very ordinary prospecting question: which companies should we contact next?

A language model can produce a list quickly. We could ask for ten candidates, a score, and an introductory message. The output often looked useful. But it left us with an uncomfortable question: why should anyone trust the next step?

A high number could sit beside a thin explanation. A company could look relevant while being the wrong entity, the wrong commercial model, already worked, or simply not verifiable. We were asking a single instruction to research, judge, locate a person, write a message, and somehow keep the process coherent.

A score could not make a weak lead stronger

We kept scoring because it is useful for prioritising cases. But we made one rule explicit: a score could not repair a failed condition.

Before a candidate could move forward, we needed to know:

  • Are we looking at the right company?
  • What current evidence supports the fit?
  • Is there a reason it belongs in this workflow rather than a generic list?
  • Is there a specific missing fact that means we should wait or reject it?
  • Is the record still usable, rather than duplicated or already worked?

“Not confirmed” was not treated as “probably yes.” That small distinction reduced the temptation to turn plausible language into commercial confidence.

We separated the jobs

Instead of treating prospecting as one AI task, we began to model the work as a sequence of smaller jobs an experienced commercial team would recognise:

  1. Identity and evidence. Find the right company and retain the sources behind the relevant facts.
  2. Qualification. Test explicit fit and exclusion rules. Reject or hold cases that do not clear them.
  3. Priority. Use a score to decide where to spend attention, not to override the qualification decision.
  4. Contact and context. Find the person or route that makes sense for this company and its current situation.
  5. Message draft. Prepare a first message that can be reviewed against the evidence.
  6. Approval and execution. Keep a visible boundary between preparing a message and sending it.
  7. State and next action. Record what happened, avoid repetition, and give the next person or system enough context to continue responsibly.

This was not about adding agents for the sake of having more agents. It was an attempt to make each piece of judgement inspectable. If the company identity was uncertain, that uncertainty stayed visible. If the fit failed, the next stage did not quietly write a convincing message anyway.

What changed for a small team

The practical change was not a fully autonomous sales operation. It was a workflow the team could inspect.

A person could see why a company was being considered, which condition had not been met, what message was being proposed, and whether an action had actually been taken. What we wanted from the CRM changed too: not a final destination for notes, but a place where the state of the work could be understood.

That matters for a smaller business. A lean team usually does not have spare time to correct a long list of plausible but weak prospects. It needs fewer cases, clearer reasons, and a next action that does not disappear when the person who did the research closes a browser tab.

The smallest version we would try now

Looking back, the smallest useful version of this experiment did not need a large system.

We could take ten candidates and add five fields:

  • The source that supports the fit
  • The condition that would disqualify the case
  • The confidence or priority score
  • The owner of the next action
  • Whether a human must approve the message before it is sent

For us, the value of those fields was that they exposed whether there was a workflow worth designing properly. When they did not improve the decision or the handoff, adding more tools would not have fixed the underlying problem.

We are still learning where this pattern earns its complexity and where a straightforward human process is better. The useful question is not whether a business needs an agent. It is which handoff currently loses enough context, judgement, or follow-through to deserve a better system.

Experiment rule

A priority score can rank the work. It should not override missing evidence, a failed fit rule, or the team’s authority to decide whether outreach happens.

Related field notes

When Chat Becomes a Workflow

Why a useful chat prompt is not yet a company workflow.

Read more

Where AI Systems Break in Real Work

The state, authority, and exception issues a demo hides.

Read more

Start With One Real Workflow, Not an AI Roadmap

How to choose a bounded first system.

Read more
J

JC Dorado

Founder, ezenciel

Technical operator focused on building useful AI systems with clear human authority and operational accountability.

Start with a real workflow

Bring the shortlist that is currently hard to trust.

We can examine the handoffs between research, qualification, outreach, and CRM state before deciding whether a system is warranted.