Automating Quotes with AI: AI Interprets, Code Calculates, Humans Approve
Quoting ate two days a week. The architecture that survived production: AI translates the messy request, code enforces the prices, a human approves in 30 seconds.
A Bangkok renovation contractor's quote process: client sends a request on LINE ("extend the kitchen, maybe move a wall, budget around 300k"), and someone spends 45 minutes matching it against the service menu, checking package rules, and building a proposal in a spreadsheet. Multiply by twenty requests a week and quoting eats two full days — while slow quotes quietly lose jobs to whoever answers first.
This is a case study in automating exactly that kind of work with AI — and the punchline is that 
the winning architecture uses AI for far less than you'd expect. The pattern that survived production: AI understands the request; code enforces the rules.
Automating quotes works best as a hybrid: the AI interprets natural language ("kitchen extension, maybe move a wall, ~300k budget") and maps it to your actual services, while hard-coded logic calculates prices, applies package rules, and enforces validity. Guardrails belong in the code layer, not the prompt — the AI should only ever "see" active services and valid combinations. For stable data like a service menu, include it directly in the prompt (in-context) rather than database search; the AI then matches by meaning instead of keywords. The result: minutes instead of hours per quote, no pricing hallucinations, and a proposal ready for human review. :::
Why quoting is the perfect hard problem
Quoting touches revenue directly, which makes it the ideal teacher of AI discipline:
- The input is messy — customers describe wishes in plain, vague language
- The rules are strict — prices, bundles, escalation terms can't be "approximately" right
- The catalog is a trap — dozens of services, half of them inactive or seasonal
- The cost of error is asymmetric — a wrong quote is a legal and trust problem; a slow quote is just a lost lead
Any architecture that survives here transfers to bookings, contracts, and proposals.
| Task | Who should own it | Why |
|---|---|---|
| Interpreting "maybe move a wall" | AI | Fuzzy language → intent mapping |
| Matching intent to service menu | AI (in-context) | Semantic, not keyword |
| Price calculation | Code | Must be identical every time |
| Active/inactive services | Code (filter) | AI never sees the option |
| Bundle & validity rules | Code | Non-negotiable constraints |
| Final quote formatting | Code (template) | Deterministic output |
| Sending to the client | Human (at first) | Trust builds gradually |
The architecture
Two layers, talking through a stateful table:
CLIENT REQUEST (LINE / form / call note)
│
▼
┌─ AI LAYER: interpretation only ─────────────┐
│ "kitchen extension, wall move, ~300k" │
│ → intents: [kitchen_ext, wall_mod] │
│ → constraints: {budget_tier: "mid"} │
│ → open_questions: ["load-bearing wall?"] │
└──────────────┬───────────────────────────────┘
▼
┌─ CODE LAYER: deterministic rules ────────────┐
│ service_catalog (ACTIVE only, injected as │
│ context) → price engine → bundle validator │
│ → quote template → draft row, status=review │
└──────────────┬───────────────────────────────┘
▼
HUMAN: 30-second review → send
The AI's entire job is translating human wishes into structured intent. The moment money appears, code takes over. If the output is ever wrong, you debug the price engine — a place where bugs are findable and fixable — not a prompt's mood.
The three lessons that saved the project
These came the hard way, from a production rollout — and they contradict prompt-engineering folklore:
1. Fewer instructions, not more
When the AI misbehaved, the instinct was to add rules. By instruction #30 the agent was worse, not better — buried rules get ignored mid-task (the proximity problem from our hallucination guide). Production rule: 3–4 instructions per task. If it's still wrong after that, the bug is in the action or the data, not the wording.
2. Guardrails in code, never in prompts
- ❌ Instruction: "Only quote active services"
- ✅ Code: the service list the AI receives is the active list
The AI literally cannot offer a retired package, because it never sees one. Non-determinism stops mattering where determinism is mandatory.
3. Data structure beats prompt engineering
A clean catalog — consistent naming, clear descriptions, explicit attributes — outperformed weeks of prompt tuning on a messy one. Before automating, spend an afternoon normalizing your service list. It's the highest-leverage hour in the whole project.
The retrieval surprise: in-context beat search
The team's first attempt had the AI search the service database (classic RAG). It failed constantly — keyword search couldn't match "open up the kitchen" to "Kitchen Extension Package B." The fix was counterintuitive: stop searching, and put the whole catalog in the prompt. With the full menu visible, the AI matched by meaning:
{
"available_services": [
{"id": "KIT-EXT-B", "name": "Kitchen Extension Package B",
"desc": "modular extension incl. cabinets + countertop",
"base": 185000, "unit": "sqm", "active": true},
{"id": "WALL-MOD", "name": "Wall Modification",
"desc": "non-load-bearing wall removal or relocation",
"base": 45000, "unit": "wall", "active": true}
],
"task": "map the request to ids + quantities + open questions"
}
For a stable set of a few hundred items, in-context wins: no search misses, no API hops, and semantic matching for free. Reserve RAG for huge or fast-changing data.
What this looks like for a service business
A realistic first build, one weekend:
- Clean the catalog — id, name, plain-language description, base price, unit, active flag
- Write the interpreter prompt — request → {service_ids, quantities, constraints, open_questions}, JSON only, quote-or-empty on every match
- Price in code — even a spreadsheet formula chain counts; the point is it's deterministic
- Route to review — quote lands in a table as
needs_review; you approve and send in 30 seconds - Measure — quote turnaround before/after; win rate on fast-quoted jobs
Typical outcome from the case study pattern: quote time from ~30–45 minutes to ~3 minutes including review, with zero pricing errors — because pricing never touched the AI.
And when quoting gets fast, the bottleneck moves to lead flow. That's a map problem: a free geo-grid scan at https://gbppeak.com/free-maps shows where your Google Maps ranking stands across your service area — more qualified requests for your now-instant quotes.
Frequently Asked Questions
Should the AI calculate prices?
No. AI interprets; code calculates. Price logic in prompts is non-deterministic — the same request can produce different totals on different runs. Put pricing in a formula, a script, or even spreadsheet logic, and let the AI only choose which services apply.
What's the difference between RAG and in-context for this?
RAG has the AI search a database mid-conversation; in-context puts the full dataset in the prompt. For stable catalogs (services, packages, policies) under a few hundred items, in-context is more reliable — the AI matches by meaning with the whole menu visible, with no search misses.
How many instructions should the AI get?
Three or four per task. Beyond that, buried rules get ignored and behavior degrades. If the agent is wrong, fix the action (the code) or clean the data — adding instruction #30 is the most common self-inflicted failure in production.
Is this only for big companies with CPQ software?
No — the pattern is platform-independent and works at small scale: clean catalog + interpreter prompt + deterministic price logic + human review. n8n, Make, or a coding agent can assemble it in a weekend.
Final note
The winning formula never changes across industries: AI for the fuzzy front end, code for the strict back end, and a table remembering everything in between. Get that split right and "automate the quotes" stops being a pilot project and starts being a Tuesday.