This AI lead qualification case study covers a system we built for our own website. Every enquiry that reaches ranbanka.com, whether it comes from the contact form or the website chat, now gets a second email right behind it. That email holds an AI triage of the enquiry: a quality rating, the matching service, a relevant past project, qualifying questions and a draft reply for our team to edit.
This is our own product. We built it for ourselves and we run it on our own site. It is also a working example of what we build for clients: a small, focused AI system that helps a team without taking decisions away from it.
The challenge
Before this system, every enquiry landed in our inbox unsorted. Someone had to read each one and judge how serious it was. They had to work out which of our services it needed, find a relevant past project to point to, and write the first reply. Spam and SEO pitches arrived mixed in with genuine leads, so every message took the same attention whether it deserved it or not.
We wanted AI to do that first pass. We also set three hard constraints:
- Never risk a lead. The contact form had to stay fast. A failure in the AI step could never cause an enquiry to be lost.
- Keep the cost very low. Triage runs on every enquiry, including spam, so the cost per run and the total daily spend both had to be strictly bounded.
- Don't let an enquiry steer the AI. An enquiry is text written by a stranger. If it contains instructions, the system must not follow them.
What we built
A triage step that runs only after the lead is safe
The lead email goes to our team first. Only after that email has been sent is a separate Python Lambda started for triage. This Lambda is invoked asynchronously with retries turned off. The visitor never waits for the AI, and if triage fails, the original lead email is already in the inbox.
Structured output grounded in verified company data
Claude Haiku 4.5 reads the enquiry together with our verified company knowledge base. It returns structured output, defined with Pydantic, containing:
- Quality: hot, warm, cold or spam
- Matching service: chosen only from our real service list, or "Other" if nothing fits
- Urgency
- Budget or timeline, but only if the visitor actually stated one
- A short summary of the enquiry
- A relevant portfolio project taken from our real, delivered work
- 2-3 qualifying questions for the team to ask
- A draft reply in the visitor's own language
Because the service and project fields must come from real data, the output points the team to things we actually offer and have actually built. You can see the same work it draws on in our portfolio and on our services page.
An email the team can act on immediately
The triage is emailed to our team, threaded under the original lead email as "Re:
A person always sends the reply
Nothing is ever sent to the visitor by the AI. A member of our team reads the triage, edits the draft and decides what to send. The AI prepares the first pass; the reply stays human.
How we delivered it
The system was built in-house by the Ranbanka team, using Python on AWS Lambda, Amazon DynamoDB, Amazon SES and our Node.js contact-form Lambda. The main difficulty was getting useful triage at very low cost, without ever risking a lead or letting an enquiry manipulate the AI. Each of those needed a specific design decision.
Isolation from lead delivery
Running triage in its own Lambda, started asynchronously and with no retries, keeps the two jobs apart. Lead delivery happens first and does not depend on the AI. Triage either completes or it doesn't, and either way the lead is already with the team.
Cost control with a fail-safe
Triage costs about $0.005 per enquiry. On top of that, a cap of $1 per day, roughly 190 enquiries, limits total spend. Daily spend is tracked in Amazon DynamoDB. If the spend store is unavailable, triage is skipped rather than run without a budget check. The system fails safe: no triage is better than uncontrolled spend, and the lead email still arrives either way.
Enquiry text treated as data
The enquiry is treated as data to be classified, not as instructions to follow. Whatever a visitor writes, the model's job stays the same: fill in the structured triage.
Evaluation on five sample enquiries
We evaluated the system on five sample enquiries. It classified all five as expected:
- A UK pharma agency enquiry was rated hot.
- A vague "want website" message was rated cold.
- An SEO pitch was rated spam.
- A Hinglish fintech chat was rated warm, with a draft reply written in Hinglish.
- A prompt-injection attempt was classified as spam rather than obeyed.
Each triage took between 3 and 9 seconds. Because it runs after the lead email has been sent, that time does not hold up the visitor.
The result
AI lead triage is live for every enquiry to ranbanka.com, from both the contact form and the chat. Each lead now reaches the team with a rating, a matched service, a relevant past project, qualifying questions and a draft reply in the visitor's language, threaded right under the original message. Spam and SEO pitches are rated as such instead of sitting unmarked among real leads.
The constraints we started with are built into the design: the lead email goes out before triage starts, spend is capped per day, nothing is sent to visitors automatically, and in our evaluation a prompt-injection attempt was treated as spam.
For teams considering something similar, the approach carries over: keep AI off the critical path, force its output into a fixed structure tied to verified data, cap the spend in code, and keep a person in charge of anything customer-facing. That is the kind of work we describe on our AI solutions page.
Talk to us about your own AI workflow
If your team spends time sorting, qualifying or drafting replies to inbound requests, we can help you scope a focused, budget-capped AI step that fits your process. Book a free initial consultation. We respond within 24 hours and work under NDA.