Lead Scoring and Priorization Module
Overview
Sales teams drown in leads but starve for signal. This project asks a simple question with a hard answer: given a raw stream of prospects and their email exchanges, which ones are actually worth a rep's time — and how should limited outreach capacity be allocated across them? The result is an end-to-end pipeline that scores, reads, and optimally assigns leads, wrapped in a dashboard a sales manager could use without ever seeing the code underneath.
What's the purpose of this project ?
Most lead scoring stops at "here's a number." But a score alone doesn't tell a team why a lead matters, or who should chase it given finite hours in the day. Two gaps stood out: scoring models rarely read the actual conversation (they lean on static features and miss what a prospect is saying), and even a perfect score is useless without a plan for turning scores into assignments under real constraints — rep capacity, lead priority, fairness. This project closes both gaps: it doesn't just rank leads, it reads them, and it doesn't just rank them, it decides what to do about it.
How can it be done ?
Python · HuggingFace Transformers (DeBERTa/MNLI) · scikit-learn · OR-Tools (CBC solver) · FastAPI · Streamlit · Docker
How did I do it ?
The pipeline works in three layers that build on one another. First, a machine learning model trained on simulated lead data, built using a latent-variable generative approach to realistically mimic how real prospects behave, produces a base lead score. Second, a DeBERTa-based MNLI model reads the actual email exchanges with each lead, using margin-based hypothesis selection to judge intent and engagement from language rather than metadata alone, and this signal is blended with the base score through a tunable weighting so the final ranking reflects both behavior and what was actually said. Third, an OR-Tools/CBC optimization layer takes those scores and solves the underlying business problem, deciding which rep should work which lead while respecting capacity and priority constraints, maximizing expected value across the whole pipeline rather than just the top of the list. All of it is served through a FastAPI backend, with a Streamlit dashboard on top so the output is something a non-technical stakeholder can explore and trust, not just a spreadsheet of numbers.
Results
The project was built as a standalone, integrable module rather than a one-off script, and that design choice is itself part of the outcome. Because scoring, language understanding, and optimization are decoupled and exposed through the FastAPI layer, the whole pipeline can be dropped into an existing sales workflow without disrupting it. Lead ingestion relies entirely on external APIs, which means the module doesn't assume a specific CRM or data source; connecting it to a new platform is a matter of pointing it at that platform's API rather than rebuilding internal logic. In practice, this makes the pipeline something closer to infrastructure than a demo: a scoring and decision engine that a sales org could plug into whatever CRM they already run, with the dashboard giving them visibility into the process without requiring any code-level familiarity.