Inbound leads are the cheapest customers a business will ever get. Someone found you, decided you might be able to help, and wrote to you. Then, in a lot of companies, the email sits in a shared inbox. Someone eventually opens it, looks up the company, thinks about what to say, writes a reply and forgets to follow up. By the time the answer goes out, hours or days have passed, and the lead has often talked to someone faster.
I built an AI lead generation and sales agent to close that gap. It reads inbound email through the Microsoft Graph API, categorizes it, researches the company that wrote in, writes a personalised reply with a Groq-hosted LLaMA model, creates the reply as a draft in Outlook, assigns the lead round-robin by region and seniority, and tracks responses, with PostgreSQL as the system of record synced to Odoo. It handles more than 100 inbound emails every day. This post explains how an agent like that is structured, why it drafts instead of sending, and what it takes to make its replies actually good.
The real problem is not writing emails
It is tempting to think the hard part of a sales reply is the writing. It is not. The hard part is everything around it:
- Noticing that a message is a lead and not a newsletter, an invoice or spam.
- Understanding what the person actually wants.
- Knowing enough about their company to reply in a way that shows you paid attention.
- Responding quickly, while the person is still thinking about their problem.
- Following through, because the first reply is rarely the last.
A person doing this well is slow because research takes time and context switching is expensive. An agent can do the slow parts in seconds and leave the person with the part that needs judgement: checking the draft and pressing send.
How the agent is structured
The agent is a pipeline of small, focused steps rather than one giant prompt. Each step does one job and hands its result to the next.
- Watch the inbox. Through Microsoft Graph, the agent reads new messages from the relevant mailbox.
- Classify. Each message is sorted: is this an inbound lead, a reply to an existing conversation, or something else entirely?
- Extract. For leads, the key details are pulled out: who wrote, from which company, and what they are asking for.
- Research. The agent gathers context about the company so the reply can be specific.
- Draft. The language model writes a reply using the message, the research and guidance about tone and what the business offers.
- Save as a draft. The reply is created as a draft in Outlook, in the right thread, ready for a person to review.
- Assign. Each lead is routed to a salesperson, round-robin within the right region and seniority level.
- Track. The lead and its status are recorded in PostgreSQL, synced to Odoo, and later replies are matched back to the conversation.
On the home page of this site there is a simulated replay of this flow: a new email arrives in a shared inbox, the agent researches the sender's company, and a reply types itself out and is saved to Outlook drafts, with the lead logged in the database.
Why it drafts instead of sending
The most important design decision was that the agent does not send emails on its own. It creates drafts.
This is not a limitation. It is what makes the whole system trustworthy enough to use:
- A person stays accountable for what goes out under the company's name.
- Mistakes are cheap. A wrong detail in a draft costs a few seconds to fix. The same mistake in a sent email costs credibility.
- Adoption is easy. Sales teams do not have to trust a black box. They see every reply before it leaves, and they learn quickly where the agent is strong and where to double-check.
- Quality improves over time. The edits people make to drafts show exactly where the prompts and research need work.
The time saving comes from removing the slow parts: noticing, researching and writing the first version. Reviewing a good draft takes a fraction of the time it takes to write one from scratch.
Research is what makes a reply personal
A generic reply ("Thanks for reaching out, we'd love to help") is barely better than no reply. What makes an answer feel personal is evidence that you understand the sender's situation: what their company does, roughly how big it is, and how their question connects to what you offer.
The research step gathers that context before drafting. The model then gets a short, structured brief (industry, size, the likely problem and how well it fits) alongside the original email. Two rules kept this useful:
- Keep the brief short. A few relevant facts produce a focused reply. A wall of text produces a rambling one.
- Never invent facts. If the research does not find something, the reply should not claim it. A made-up detail about a prospect's company is worse than no detail at all.
Writing replies people want to answer
Getting the model to write a good sales reply is mostly about constraints. Useful guidance for the drafting step includes:
- Answer the question they asked first. People write in with a specific need. The reply should address it before anything else.
- Be specific. Refer to their situation, not to "businesses like yours".
- Keep it short. A few sentences and one clear next step beat a long pitch.
- Propose one concrete next step, such as a short call at a suggested time, rather than a vague "let me know".
- Match the company's voice. The drafts should sound like the team that will be sending them.
Routing: the right lead to the right person
At volume, who answers a lead matters as much as how fast. The agent handles more than 100 inbound emails a day, so assignment cannot be manual.
Leads are routed using round-robin within two dimensions: region and seniority level. A lead is first matched to the region it belongs to, then to the seniority level that fits it, for example a large account going to a senior salesperson and a smaller enquiry to someone earlier in their career. Within that group, round-robin spreads leads evenly, so nobody is buried while others sit idle, and every lead has a clear owner from the moment it arrives.
The assignment is written to PostgreSQL and reflected in Odoo, the business's CRM, so each salesperson sees their new leads where they already work. Nobody has to copy anything between systems, and managers can see exactly who owns which lead.
This is what separates a real AI system from "an LLM connected to a chatbot". The language model is one step. The value comes from the whole pipeline around it: ingestion, categorization, research, drafting, assignment and a CRM that stays in sync on its own.
Microsoft Graph: working inside Outlook
Because the agent lives inside Microsoft 365, the Microsoft Graph API is the backbone of the system. It provides everything the agent needs: reading messages, identifying conversation threads, creating reply drafts in the right thread, and reading later replies.
A few practical points matter here:
- OAuth 2.0 permissions should be as narrow as possible. The agent needs access to specific mailboxes, not the whole organisation.
- Threading matters. Drafts must be created as replies in the original conversation, so the recipient sees a normal thread.
- Processing must be safe to repeat. If the agent restarts, it must not create a second draft for a lead it already handled.
PostgreSQL and Odoo as the system of record
Every lead, every draft, every assignment and every response is recorded in PostgreSQL and reflected in Odoo. This gives the sales process something inboxes never provide: a clear, queryable picture of what is happening.
- Which leads came in this week, and how quickly were they answered?
- Which drafts were sent, and which are still waiting for review?
- Which conversations went quiet and need a follow-up?
Response tracking closes the loop. When a lead replies, the message is matched to its conversation and the status updates, so nothing falls through the cracks between the first reply and the second.
A lead's journey, end to end
Here is what happens to one enquiry.
A new email lands in the shared sales inbox: the operations manager at a logistics company writes that her team receives about forty supplier invoices a day as PDFs and keys them in by hand, and asks whether that can be automated.
Within a minute the agent picks up the message through Microsoft Graph. Classification marks it as a new inbound lead, not a reply and not a newsletter. Extraction records who wrote, the company name and the core request: automating invoice intake.
The research step builds a short brief: the company works in freight and logistics, it is a mid-sized team, the pain point is manual invoice entry, and the fit is strong because document pipelines are exactly what the business delivers.
The drafting step writes a reply that answers her question directly, refers to her forty PDFs a day rather than to "your documents", explains in one sentence what automation would look like, and proposes a twenty-minute call on a specific day. The draft is created in Outlook as a reply in her original thread.
The lead is logged in PostgreSQL with its status set to "draft ready". A salesperson opens Outlook, reads the draft, adjusts one sentence and presses send. The status becomes "replied". When she answers two days later, her message is matched to the same conversation and the status moves on again.
From her side, she got a fast, specific, human-sounding answer. From the team's side, they spent a minute on it instead of half an hour.
Measuring whether it works
An agent like this should earn its place with numbers, not impressions. The measures that matter are simple:
- Time to first reply. How long between a lead arriving and a reply being sent. This is usually the biggest and most visible improvement.
- Draft acceptance. How many drafts are sent with little or no editing. A falling edit rate means the prompts and research are getting better.
- Coverage. What share of inbound leads get a reply at all. Manual inboxes quietly drop a surprising number of messages.
- Follow-up rate. How many conversations that went quiet received a follow-up.
Because everything is recorded in the database, these measures come from queries rather than guesses.
Common pitfalls
A few mistakes are easy to make when building an email agent:
- Letting it send automatically too early. Trust is earned draft by draft. Automatic sending, if it is ever appropriate, should come much later and only for well-understood cases.
- Over-long replies. Models like to write. Sales replies should not. Constrain length firmly.
- Treating every email as a lead. Poor classification floods the review queue with drafts nobody needs, and people stop looking.
- Ignoring threads. A reply that starts a new conversation instead of answering in the original thread looks careless and confuses the recipient.
Lessons from building it
- Keep a human in the loop where it counts. Drafting is the sweet spot: most of the time saved, almost none of the risk.
- Use small steps, not one giant prompt. Classification, extraction, research and drafting each work better when they are separate and testable.
- Research quality decides reply quality. The best prompt in the world cannot write a personal reply without real context.
- Forbid invention. Replies must only use facts the agent actually found.
- Record everything. A database of leads and their status turns a messy inbox into a pipeline you can manage.
Where an agent like this fits
This kind of agent is a good fit for any business that receives inbound enquiries by email and wants to answer them faster and more consistently: service firms, B2B software companies, agencies and consultancies. It is especially useful when leads arrive in bursts, when the same few questions come up again and again, or when the people who should be replying are busy doing the actual work.
It is not a replacement for a sales team. It is the colleague who reads every email the moment it arrives, does the homework, and puts a good first draft in front of the right person.
Summary
The AI lead generation and sales agent turns a shared inbox into a managed pipeline. It reads inbound email through Microsoft Graph, classifies and extracts leads, researches the sender's company, drafts a specific reply with a Groq-hosted LLaMA model, saves it to Outlook drafts for a person to review, and tracks every conversation in PostgreSQL. The result is inbox to drafted, researched reply without anyone having to do the slow parts.
If you want to talk about automating inbound leads for your own team, ask Alfred or send me a message.
Found this useful?
Share it with someone who is still doing this work by hand, or ask Alfred how it could apply to your team.
Next article
The content engine that reached page one in two months
Read it