A buyer filled in the “request a quote” form on a Friday afternoon, described a bracket run in two sentences, and waited. An estimator opened it the following Tuesday, wrote back to ask about material, quantity, and tolerance, and never heard anything more. The buyer had already placed the order with a shop that answered first. The owner only found out weeks later, when the same buyer mentioned it in passing on a call about something else.
That lost job is where our engagement started, and it turned out to be a good summary of the whole problem. Nothing was broken on the floor. The machines ran, the work was good, the prices were competitive. Quotes were simply going cold in the hours and days between a buyer asking and someone with the right questions getting to it. For a shop that wins a fair share of work on being responsive, that quiet gap was costing real jobs.
The business here is a representative composite we will call Ridgeline Fabrication, a mid-sized metal shop assembled from the kind of engagement we run regularly. The situation and the work are true to how these projects actually go; the name and specifics are illustrative rather than a single named client.
Duration ~4 to 6 weeks · Manufacturing (metal fabrication) · Zipprr AI Chat · Integrates with the shop's existing CRM, email, and capability content · A quote-intake and qualification assistant that collects, never prices · Medium complexity
Reading three weeks of real requests
We rarely trust the summary of a problem. So the first thing we asked for was the raw material: a few weeks of actual quote requests, exactly as they had arrived. The owner exported web-form submissions, forwarded emails with drawings attached, and the shared sales inbox, and we spent a morning at the estimator’s desk reading them in the order they came in.
The volume was not the story. What stood out was how few of the requests could be priced as written. Most were missing at least one thing an estimator cannot quote without: the material and its grade, the quantity, the tolerance, the finish, or a real due date. A drawing would arrive with no material called out. A material would be named with no quantity. Each of those gaps kicked off the same slow loop, read the request, notice what was missing, email to ask, wait a day, get half an answer, email again.
Add it up and the estimator was not spending his mornings estimating. He was spending them collecting four or five facts that should have arrived with the request in the first place. A slice of the inbound was never going to become a job at all: single ornamental pieces, quantities of one on parts the shop only runs in the hundreds, work well outside anything the floor does. Those still cost him a reply each.
Reading that pile changed what we proposed. The owner had framed it as “we are overwhelmed,” and if we had taken that at face value we might have pitched something ambitious around configure-price-quote software or an ERP tie-in. The requests told a smaller, more useful truth. The drain was incomplete intake and mismatched enquiries, not raw volume, and that meant the right build was narrow.
The line we drew before writing any code
One decision shaped everything that followed, and we made it on the first call, out loud, before scoping anything. The obvious way to read “automate our quotes” is to have the software produce the price. We chose not to, and we were explicit about why.
Pricing a fabrication job is not a lookup. It moves with material markets, machine time, how efficiently parts nest on a sheet, secondary operations, and an estimator’s read of a drawing a buyer summarised in one line. A wrong number in an automated reply is not a small slip; it is a figure a customer might hold the shop to. So the assistant would do the genuinely repetitive part, hold the opening conversation, gather a complete and consistent brief, quietly set aside the requests that were never a fit, and hand a person something already worth pricing. The estimator would keep every judgment that carried risk.
Drawing that line early is also what let the project move quickly. Because nothing we were automating could make a commitment the shop had not made, there was very little that could go badly wrong in a way a customer would feel.
Choosing a system the shop would own
The owner had a clear preference before we recommended anything: no more monthly subscriptions with a meter ticking in the background. He had watched other tools grow more expensive precisely as they became more useful, and he wanted to own the thing outright, host it himself, and change it without asking anyone.
That pointed us to Zipprr AI Chat rather than a rented platform or a from-scratch build. Three reasons decided it. Ownership, because the engagement ends with complete source code ownership transferred to the shop, so it can self-host, customize, and maintain the system without vendor lock-in, the way it keeps its own machines. Customization, because the questions, the qualification rules, the fences, and the tone all had to bend to how this particular estimator works, which a closed subscription would not let us reshape freely. And fit, because the assistant needed to sit in front of the shop’s existing site and inbox and feed its existing CRM, not ask anyone to migrate onto a new stack.
We were honest about the other side of that trade. Owning the system means the shop maintains it once the support window closes, where a subscription would keep patching it forever for a recurring fee. For a business that already services its own equipment and prefers to own its tools, that was an easy call. A shop that wanted someone else to run everything indefinitely might weigh it differently, and we said so at the time.
One practical point made that ownership easier to say yes to. At the time of writing, Zipprr also includes free implementation customization with every AI Chat purchase, which covers exactly the kind of tailoring this project lived on: shaping the conversation flow, the qualification rules, and the integrations during implementation. As with the price, it is worth confirming the current offer before you buy, since promotions can change.
Designing the conversation
We built the assistant on Zipprr AI Chat and put it on the quote page and the main inbound channels the shop already used. Everything past that point was either configured inside the assistant or wired into a tool the shop already had. We kept new systems to a minimum on purpose, since every extra moving part is something the shop has to maintain after we leave.
The conversation was designed to feel like a good estimator opening a call, not a web form demanding twelve fields. It greets the buyer, works out in two quick questions whether this is even the kind of work the shop takes, and only then walks through what an estimator would otherwise ask for one email at a time: part description, material and grade, quantity or annual volume, dimensions or a drawing, tolerance, finish, any certification, and the date it is needed. Short questions, in an order that reads like a conversation.
Behind that sits a deliberately legible set of rules rather than a black box. The assistant checks fit first, is the process, material family, and rough volume something the floor actually does, then completeness, are the estimating essentials all present, then handling, is a drawing needed and has it been captured. We kept the logic readable so the shop could see exactly why any enquiry was routed the way it was, and change a rule without calling us.
Under the hood
A few of those boxes deserve a word, because they are where a project like this is really decided.
Grounded answers, so the assistant could handle basic capability questions (“do you run stainless,” “what is your minimum quantity”) without inventing anything, we tied it to the shop’s own materials list, capabilities, and finishes and had it retrieve from those rather than guess. The largest piece of preparation was not technical but editorial: we went through the shop’s published content and pulled the stale entries first, an expired certificate reference and an old tolerance range the floor no longer held, because grounding an assistant in wrong information is worse than not grounding it at all.
Drawings, handled plainly. Buyers can attach a PDF or an image. The assistant confirms it has the file and captures the facts around it, then stops. It does not claim to read CAD geometry, and it never calls receiving a file an engineering review. A file in an inbox is not an engineer having looked at it, and pretending otherwise is how you lose a buyer’s trust. The assistant says, simply, that a person will review the drawing.
Handoff, treated as a promise. A completed brief is packaged with the conversation and any files and dropped into the shop’s existing CRM queue, with an email alert to the estimator and the original request attached. Anything that trips a fence, a request for a firm price, a hard push on lead time, a hint of controlled or export-sensitive work, goes straight to a person instead. And the assistant only tells a buyer “I have sent this to our team” after the routing has actually gone through, never before.
After hours, honest about it. The shop did not want the assistant implying someone was at a desk at eleven at night, so its promises shift with the clock. Inside business hours it sets a same-day expectation; after hours it captures everything and tells the buyer plainly when a person will pick it up. That closed the exact gap that had lost the first quote, without inventing a night shift.
Where these deployments actually break
The happy path is never the hard part. The edges are.
When the assistant reads a spec out of a loose answer (“about a quarter inch, give or take”), it does not quietly record a tidy number. Low-confidence captures are flagged for the estimator rather than presented as fact, which keeps a person in the loop exactly where the software is least sure. If an integration fails, if the CRM write or the alert does not land, the assistant does not swallow it and reassure the buyer anyway. It retries, and if it still cannot confirm the handoff it surfaces the failure so a person can catch the brief by hand. The rule we held throughout: never report success we have not verified.
We planned for the ordinary messes too. The buyer who pastes a wall of text and a drawing and nothing else. The one who answers three questions and disappears, where we keep the partial brief and the contact so it is a warm follow-up rather than a dead form. The out-of-scope hobbyist, released politely without tying anyone up. The same job submitted twice across two channels, deduplicated so the estimator is not chasing a ghost. And because fabrication drawings are sometimes confidential and occasionally export-controlled, we had the assistant collect only what intake genuinely needs, keep files inside the shop’s own environment, and escalate anything hinting at controlled data to a person rather than handle it in an automated thread. In this work, collecting less and escalating sooner is the safer default.
The version that asked too much
Our first build was thorough to a fault. It marched every buyer through the full specification set before it had any idea whether the job was something the shop even runs. A serious buyer with a real production part got the same twelve-question interrogation as a student pricing a single decorative piece, and the serious buyers were exactly the ones we could least afford to make wait. It is one of the most common intake mistakes there is, and we walked straight into it.
The fix was to reorder the conversation, not add to it. The assistant now settles scope first with two quick questions, roughly what is the part and roughly how many, and only opens the full set once the job reads as in range. Out-of-scope enquiries get a short, honest answer and a pointer elsewhere.
Launch week
What actually changed
The clearest result was not a number on a dashboard. It was the estimator saying, a couple of weeks in, that the quotes reaching him were arriving ready to price instead of ready to chase. The round-trip for missing details, the thing that had been eating his mornings, mostly went away for anything that came through the assistant, because the details were no longer missing.
Side by side, the change looked like this:
| Before | After |
|---|---|
| Requests arrived missing material, quantity, or tolerance | A complete, consistent brief on the estimator's desk |
| Two or three emails to assemble one quotable spec | A single guided conversation captures it up front |
| A trained person did the repetitive qualifying | The assistant handles scope and completeness first |
| Hobby and out-of-scope enquiries ate replies | Filtered out politely, with no staff time spent |
| Responses could slip for days, losing fast jobs | Immediate intake, day or night, with an honest follow-up window |
We were careful about what we claimed on return. A brief that used to take two or three days of back-and-forth could now land in one sitting when a buyer answered, which mattered most on the fast-moving requests the shop had been losing to whoever replied first. Public write-ups on quote automation report large cuts in preparation time, but those are other companies’ numbers on other deployments, and we would not paste them onto Ridgeline. We left the hard figures, quote turnaround, complete-brief rate, win rate, hours saved, to the shop’s own records, and told them precisely which of those to start tracking so they could judge the payback themselves.
The line that stuck came a week after launch, when the owner mentioned that a request had arrived overnight, complete, and gone out as a quote first thing in the morning, before the buyer had reached anyone else. That was the whole point of the engagement in one ordinary sentence. As he put it to us later, the surprise was not the speed. It was the conversations his estimator no longer had to repeat.
What we would do differently
What we would do differently
Thinking about your own quote intake?
Read a few weeks of your real requests first, and count how many arrive ready to price. When you’re ready to build, Zipprr AI Chat is a one-time purchase from around $490 (subject to change) with complete source code ownership, 90 days of free support, and free implementation customization with every purchase.Explore Zipprr AI Chat or the full product range. Confirm current pricing and offers before you buy.
Frequently Asked Questions
Does the assistant generate the price or the quote?
Will it replace our estimator or sales team?
How does it handle out-of-scope or hobby requests?
What happens when someone uploads a drawing?
What stops it from saying something wrong about price or lead time?
Does it work with the systems we already use?
Do we own it, or is it a subscription?
What does it cost?
The AI Chat Software product this was built on is a one-time purchase that starts at around $490 (subject to change), with no per-conversation or monthly fees.
What happens after purchase?
What if something needs adjusting after launch?
Project snapshot
- Industry: Manufacturing, metal fabrication (make-to-order, quote-driven)
- Business size: Small-to-midsize shop; a lead estimator plus a small sales and front-office team
- AI solution: Conversational quote-intake and qualification (collect and route, never price and quote)
- Zipprr products used: Zipprr AI Chat only. Intake, qualification, drawing capture, grounded answers, escalation, and business-hours behaviour were all configured inside it; no other product was needed
- Integrations: The shop’s existing CRM, its email and notification setup, drawing-file handling, and its own capability content for grounded answers. Nothing replaced
- Deployment complexity: Medium. Simple on the surface, but the qualification rules, escalation fences, confidence handling, and honest failure behaviour are where the work sat
- Estimated implementation time: Roughly 4 to 6 weeks, given the deliberately narrow scope
- Best fit: Make-to-order and configure-to-order shops (fabrication, machining, custom manufacturing, signage and print, industrial supply) losing time to incomplete quote requests and out-of-scope enquiries
- Not suitable for: Businesses that need the system to produce binding prices or delivery dates automatically; heavily regulated or export-controlled work that should not run through automated intake at all; or shops already quoting through a mature CPQ or ERP flow with complete requests arriving as standard
- Lessons learned: Read the real requests before designing anything. Retire stale capability content first. Put the automate-versus-human line at the price and defend it. Make the handoff message literally true. Ask the estimator for his one “always ask this” question up front
- Future enhancements (candidates, not commitments): A repeat-part lookup so recurring jobs surface a prior quote faster; a light intake-quality view (complete-brief rate, clarification cycles, time to a person) so the shop can measure the payback in its own numbers; and, only if the shop wants it, a carefully reviewed path to indicative ranges on simple, well-understood parts, with a person still confirming every number
Â
Where to Start With Your Own Quote Intake
If your quotes are going cold in the same gap, the honest first step is not to buy anything. Pull a few weeks of your own real requests and read them in the order they arrived, the way we did here, and count how many were actually quotable as written. That reading usually tells you exactly what is worth automating and, just as importantly, what should stay with a person.
When you are ready to build, the details matter. Zipprr AI Chat is a one-time purchase that starts at around $490 (subject to change) and includes complete source code ownership, 90 days of free technical support, and free implementation customization with every purchase (a current promotional offer). Please confirm the latest pricing and offers before you buy, since they can change, and you can see what else fits your workflow across the Zipprr product range.
Ridgeline Fabrication is a representative composite drawn from engagements of this kind, not a single identifiable client. The work is described as these projects actually run.
