Sales operations
Scores and routes inbound leads with a stated reason for every score, and drafts the first follow-up for a human to send.
Build effort, not elapsed calendar time. Engagements ran alongside study and employment, so this figure is the work itself rather than the span it sat in.
Interface built in code for this case study — not a client screen capture.
01Business problem
Inbound leads arrive faster than a small sales team can qualify them, so the ones worth calling are buried next to the ones that were never going to buy.
Who feels it
A form submission, a WhatsApp enquiry and a referral email all land in different places. Someone copies them into a spreadsheet or a CRM, looks up the company, guesses whether it is worth a call, and writes a first message from scratch. By the time the third lead is handled, the first has gone cold.
Teams try to fix this with a lead score. Most scoring implementations make it worse: a number appears next to a lead with no explanation, reps do not believe it, and within a month they are ignoring the column entirely. A score nobody trusts is worse than no score, because it creates the appearance of triage without the substance.
The second failure is duplication. The same person enquires twice from two channels and becomes two leads, two owners and two conversations — which is how a prospect ends up being called by two reps in the same week.
02Product overview
A lead intelligence layer that unifies inbound channels, resolves duplicates into one record, scores each lead with visible contributing reasons, routes it by rule, and drafts a first-touch message the rep edits and sends.
Engineering notes
Every inbound source normalizes into one lead shape at the boundary, so a WhatsApp enquiry and a web form produce the same record with a channel attribute rather than two different objects. Identity resolution runs on entry: email, normalized phone and company domain are compared before a new lead is created, and a probable match is merged with the previous record instead of duplicating it.
Scoring is deliberately explainable. Each contributing signal — declared budget range, company size band, stated timeline, channel, engagement recency, fit against the ideal customer profile — produces a weighted contribution, and the interface shows the contributions rather than only the total. A rep who disagrees can see exactly which signal moved the number, which is the difference between a score being used and a score being ignored.
The model drafts, a person sends. First-touch messages are generated from the lead record and the qualification notes, then held in a review state. Nothing leaves the system without a human pressing send, because an automated message with a wrong assumption in it costs more than the time it saved.
03Key features
10 capabilities, of which 3 are model-backed. The rest are ordinary deterministic software, and the distinction is marked so the AI claim stays honest.
Web forms, messaging enquiries, referrals and manual entry normalize into one lead record with the source retained as an attribute.
Email, normalized phone number and company domain are matched before creation, so a repeat enquiry updates a lead rather than duplicating it.
Each signal contributes a visible weighted amount to the score, and the reasons are shown next to the total rather than hidden behind it.
Free-text enquiries are summarized into structured qualification fields — need, timeline, budget signal, decision role — with the source text kept.
Ownership is assigned by territory, segment and score band using ordered rules, with an explicit fallback owner so no lead is unassigned.
A first outreach message is generated from the lead record and held for review. The rep edits and sends; the system never sends by itself.
Stages with an explicit next action and age per lead, so a stalled deal is visible as a stalled deal rather than a card sitting in a column.
Every touch, score change and stage move is recorded per lead, including which rule assigned the owner.
Ambiguous identity matches go to a review list instead of being auto-merged, because a wrong merge is harder to undo than a duplicate.
Weight configuration is versioned and visible, so a manager can see why last month’s leads scored differently from this month’s.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Channel adapters normalize inbound payloads into one lead shape.
Identity matching on email, phone and domain; ambiguous cases queued.
Enquiry text summarized into structured qualification fields.
Weighted signals produce a total plus the reason list behind it.
Ordered rules assign an owner, with a guaranteed fallback.
Draft generated, reviewed by a human, sent and logged.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
Adoption is the whole problem with lead scoring. Reps use a score they can interrogate and ignore one they cannot, so the reasons are part of the return type rather than a debugging aid.
Trade-off
The scoring function becomes more verbose and every weight change has to produce sensible prose. That cost buys the score actually being used.
Why
A wrong merge destroys history and can attach one prospect’s conversation to another. Duplicates are annoying; bad merges are damaging, and the asymmetry justifies human review in the middle band.
Trade-off
Someone has to work the queue. Confident matches still merge automatically, so the queue stays small.
Why
Weights get tuned. Without a version stamp, historical scores become uninterpretable and any comparison across months is misleading.
Trade-off
Extra field on every lead and a config store to maintain, in exchange for score history that means something.
Why
Implicit routing produces unowned leads, which is the single most expensive failure in an inbound pipeline. An ordered rule list with a fallback makes "nobody owns this" impossible.
Trade-off
Rules need maintaining as the team changes. The evaluator returns the matched rule so an owner assignment can always be explained.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Identity keys are normalized before comparison — phone numbers to E.164 where a country can be inferred, emails lowercased with common alias handling, and company domains extracted from both website and email. Matching produces a confidence, and only the high band merges automatically.
Outcome
Repeat enquiries update one record with a second touch on the timeline, which is what a rep needs to see before calling.
Approach
Structured output with every field nullable, and a rule that a field is only populated when the source text supports it. The interface shows the source excerpt next to each derived field, so an unsupported inference is immediately visible.
Outcome
Qualification fields stay empty when the enquiry did not say, rather than being filled with a plausible guess a rep would act on.
Approach
Stages are server-rendered with pagination per column, drag interactions operate on an optimistic local move with rollback on failure, and the score-band filter is a URL parameter so a filtered board is shareable and cacheable.
Outcome
The board stays fast and a manager can link a colleague to exactly the view they were looking at.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Lead inbox
Leads with score band, channel, owner and age — filterable by band, sorted by what needs a call today.
Score breakdown
The contributing signals with their weights and direction, next to the original enquiry text.
Pipeline board
Stages with per-lead next action and days in stage, so stalls are visible without a report.
Draft review
Generated first-touch message in an editable composer, with an explicit send action and the lead context beside it.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
11Technical preview
There is no repository link on this site. What is available instead is the module structure, the data model, the interface contracts and annotated excerpts written for this case study — enough for a technical reviewer to judge the engineering.
Technical preview
Selected implementation details are available for technical review: component structure, data models, architecture notes and sanitized code excerpts. Some client-specific source material stays private because of confidentiality. Enter the project access keyword if you have been given one — the same one works across every case study.
A presentation convenience, not authentication. This is a static site, so the keyword ships to your browser with the page and anyone reading the bundle can find it — worth saying plainly rather than dressing it up. Nothing confidential is stored behind it.
Inside this section
For private client work, contact me for a walkthrough.
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.