Full quote automation

Questions
, , ,
1

:bullseye: What is your goal?

Building a Quote generation of technical products based on a customer form

:thinking: What is the problem & what have you tried?

Im building a full quote automation scenario, based on a hubspot forms. These process require lots of rules and technical sheets to make sure that the quote comes correct and without any mistakes. On a first stage I want to get the list of materials to produce each quote on my CRM manually.
With this i could get a quote request from a customer and 5 min after I already had the materials list to produce the proposal.

The structure is all done but I dont think Pinecone is the right way to do it because its not giving me the correct products that it should.

Any tips/suggestions? ( first time working on a automation and really enjoying)

:camera_with_flash: Screenshots (scenario flow, module settings, errors)

Captura de ecrã 2026-07-22 232153.png
Captura de ecrã 2026-07-22 232153.png1756×705 94.3 KB

3

Hello,

Using AI to generate quotes is generally a bad idea when you already have a structured materials list in your CRM. The core problem: AI is non-deterministic - it can produce different output for the same input.
For quoting, if product A costs $99, you need it to appear as product A at $99 – not “Super Fancy Product A” at “99,99”.

There are better tools for this. A few options depending on your setup:

  • Dedicated quoting apps like Proposero handle this out of the box and are fully integrated with Make
  • Google Slides works well for flexible, custom PDF generation.
  • Google Docs or any PDF-filling app is a good fit for single-page quotes or if you dont need fancy styling or hard-coded elements.
  • If you’re delivering quotes as email body content, generate an HTML table directly from your CRM data – clean, deterministic, and easy to maintain.

Have a nice day,
Michal

4

Hello! Thanks for you reply

What im trying to achive is an automation that based on customer information it gives me the list of materials.

Example:

Customer 1

“ this customer will need: 2x product A , 4x Product B and 1 product C”

So it’s not the quote itself but yes the materials needed for me to produce it on my crm directly instead of evaluating every Quote Form information.

Of course that the AI needs to have all the tech sheets and lots of rules on how to choose the right product for each type of situation.

I was trying on Claude Code to create a python file with all of these rules, using a method of putting the customer information and uploading a quote made by me so it can learn and adjust the code… Maybe this can be a good way if i can get it on Make.

5

Hi Rodrigo
This sounds like an interesting workflow. From the way you’ve described it, I wonder whether Pinecone is being used for something that might be better handled by a structured product/rules database.

For technical quoting, where the result needs to be exact, semantic similarity alone can sometimes return a product that is conceptually similar but technically incorrect. You may get more reliable results by separating the workflow into two parts: using structured rules/filters to determine which products are actually eligible, and then using AI/vector search only where it adds value.

Are your technical sheets currently stored as structured data (for example, one product per row with specifications and compatibility fields), or are they mainly being searched as unstructured documents?

6

Thanks, that makes sense. So the main goal is not for AI to generate the quote itself, but to take the customer’s requirements and return the exact materials/products needed for that specific configuration.

In that case, I would be careful about relying on AI or Pinecone alone to make the final product decisions. For technical products, I think the more reliable approach would be to have the product specifications and selection rules structured in a way that the workflow can validate, then use AI to interpret the customer’s form information and map it to the relevant rules.

Your idea of using previous quotes as examples could still be useful, but I would probably treat them as reference examples rather than allowing the AI to learn from them and make unchecked decisions.

How many different products and technical rules are you dealing with approximately? And are your existing technical sheets mainly PDFs/documents, or do you already have the product specifications in a structured format such as Excel or a database?

7

Hello!

Right now, Im dealing with 3 different products and more than 10 technical rules.

In Claude, I thought about the concept of machine learning… I tried it with 5 different quotes& customer information and after adjusting the code, I only sent claude the information to see if it gave me a proper list of products based on that and it worked.. So now I have .py of the product references and all the rules.

I have all the tech sheets in Pdfs.

8

Hi Rodrigo,

I think Jane is pointing you in the right direction here.

The key question is probably not “how do I connect the Python file to Make?” yet. It is: can the Python file explain why it selected each product?

For this kind of quote, I would treat the system more like a decision engine than a search flow:

  1. AI extracts the customer requirements into a clean structure.
  2. Your rules decide which products are eligible or excluded.
  3. The output includes the selected product plus the reason behind the decision.
  4. If a required input is missing or two options are too close, it goes to review instead of guessing.

The PDFs can still be useful, but I would avoid relying on live semantic search for the final product decision if the quote needs to be technically correct. I would use the PDFs to build or maintain structured product specs, then test the rules against your previous quotes.

A good next test would be simple: take your 5 previous quotes and make the Python return not only the selected materials, but also the rule trace for each one. If the wrong output happens, you’ll immediately see whether the issue is customer input extraction, product data, or the rule logic.

If you can share one anonymized example with:

  • customer input
  • expected materials
  • current wrong output

it would be much easier to tell where the system is actually breaking.

9

Hello!

This is exactly the right direction, so it’s good to hear it.

Where I’m at right now:

It is a decision engine, not a search flow. I moved away from Pinecone/semantic search for the final product decision. I extracted the tech sheets into a structured spec file (product codes, size options, coverage rules, accessories) that’s separate from the rules that decide which product to pick. So updating a product spec never touches the decision logic.

Every decision now returns a rule trace, not just the answer. For each item needed, the output includes the selected product plus a step-by-step log of why: which rule fired, what assumptions were made, what was inferred vs. given directly by the customer.

There’s a “needs review” flag. It fires whenever an input is missing, an assumption had to be made, or two options were a close call. Those get flagged for a manual check instead of the system just guessing.

I ran the “previous quotes” test you suggested — checked it against 3 real past quotes so far, product-line by product-line against what was actually delivered. Two are at 100% match; the third is 8/10 lines correct (the 2 gaps turned out to be a data version mismatch on my side, not a rule error).

Here’s an anonymized example of exactly the kind of break you’re describing:

Customer input: one room, ~37 m² gross area, one of my install types (the one where the product goes fully embedded rather than surface-mounted), one finish type.

Expected output (from the real past quote): 1x large-capacity unit of Product Type A.

Initial wrong output: 2x smaller units of Product Type A (system split it into two).

Root cause, found via the trace: my rule was sizing off the wrong area basis (a “usable” area field that was empty and defaulted) at a density target that didn’t match how this product is actually sized in practice. The correct rule sizes off the gross area directly, at a lower density band, and prefers one slightly-under-density unit over splitting into two when it’s close. Once I fixed the area basis and the density target, it matched the real quote exactly.

That trace made it obvious in under a minute this wasn’t a product-data problem or an extraction problem — it was two rule parameters that didn’t match real practice.

Next step is wiring this into Make — there’s a native Code App module that runs Python directly in a scenario now, so no external API/server needed. But open to your suggestions. The review flag will route anything uncertain to a manual check before the quote is finalized.

10

That’s a very good sign Rodrigo.

If the trace let you separate “wrong product data” from “wrong extraction” from “wrong rule parameters” in under a minute, then the core engine is already becoming useful.

At this point I would be careful with one thing before wiring it into Make: don’t only pass the final selected products back to the scenario. Pass the decision package.

For each quote line, I’d want Make to receive something like:

  • selected product
  • confidence / review flag
  • rule trace summary
  • assumptions made
  • spec version used
  • rule version used
  • reason for review, if any

The spec version and rule version matter more than they seem. Your example already proved why: one mismatch can look like an AI problem, a product-data problem, or a business-rule problem depending on what you can see afterward.

So the Make scenario should probably do three jobs:

  1. Send clean customer requirements into the Python engine.
  2. Store the decision output and trace somewhere readable, not just in the final quote.
  3. Route “needs review” cases with enough context for a human to approve or correct the line quickly.

The native Python Code App module sounds like a good fit if the package/dependency needs are simple. I’d just avoid letting the Make scenario become the place where the business rules live. Make should orchestrate. Python should decide. The trace should explain.

One useful next test: when a reviewer corrects a quote line, can that correction become a new regression test without changing the Make scenario?

11

This is a much stronger architecture now. For the Make wiring, I would put a strict normalization/validation step immediately before the Python module so the decision engine never has to interpret free text.

A useful extraction contract could look like this:

{
  "schema_version": "1.0",
  "request_id": "...",
  "inputs": {
    "gross_area_m2": 37,
    "installation_type": "embedded",
    "finish": "..."
  },
  "provenance": {
    "gross_area_m2": {
      "source": "customer",
      "raw": "~37 m2"
    }
  },
  "warnings": [],
  "review_required": false
}

Then the Python module should fail closed when a required field is missing, an enum is unknown, or a value is outside an expected range. It can return the selected products, rule trace, rule/spec version, and review_required.

The Make flow becomes: intake → normalize to the schema → validate → Python decision engine → router on review_required → manual review or quote generation.

I would also store the normalized input and the rules/spec version with every quote. That makes a future mismatch reproducible even after the catalogue changes. Finally, keep a small regression set of historical quotes and run it whenever rules or specs change; the two mismatched lines you found are exactly the kind of case that belongs in that set.

One final guardrail: allow AI to extract values, but never let it invent product codes. Validate every returned code against the structured catalogue before the quote can proceed.

12

Hi all,

Wanted to close the loop on this thread with an update, since the advice here really shaped how this turned out.

Where I landed:

Built it as a decision engine, not a search flow. Product specs (sizes, coverage rules, accessories) live in a structured JSON file, separate from the rules that decide what to pick. A normalization step sits between the AI extraction and the rules, so the engine never has to interpret free text — it only ever sees a validated, structured input.

Every decision returns a trace: what was selected, why, what was assumed vs. given directly, and a “needs review” flag with the reason attached.

Tested against 3 real historical quotes, line by line. Two matched 100%, one was close with an explainable gap. The trace made it trivial to tell whether a mismatch was an extraction issue, a product-data issue, or a rule issue — exactly as predicted here.

Found a real systemic bug this way: my AI extraction step was pre-applying a single fixed coverage percentage to every room before the data even reached my rules engine. Since my rules only apply their own calibrated coverage when they receive the raw/unprocessed value, that fixed percentage was silently overriding rules I’d carefully tuned per product type from real quotes. Fixed by having the extraction step return the raw reading and letting the rules own 100% of the business logic.

Wired it in with a native Python “Code” module in the automation tool — no external API/server needed. It sits right after the AI extraction step and a form field, and outputs a clean summary (plus the full structured trace) instead of the raw JSON.

For now I’m keeping the last step manual (I build the actual quote myself from the material list), but the whole material-selection layer is automated and auditable. Corrections that I make manually get logged as permanent regression cases, so the rules only get more reliable over time instead of drifting.

Really appreciate the pushback early on — the “treat it like a decision engine, not search” framing changed the whole direction of this.

image
image1761×705 87.8 KB

13

Your instinct to keep material selection deterministic is right. I’d keep Pinecone out of the final pricing path unless you need it for retrieval of unstructured product notes. Store a canonical product/material table with SKU, aliases, unit, compatible options, price version, and effective date; let Make normalize the form input, look up candidates, and stop for human review when a match is uncertain or required fields are missing. Then generate the quote from validated line items, not from an LLM response. Log the form ID, matched SKU IDs, price-list version, and approval state so a retry cannot change an already-reviewed quote. For the first version, what is the harder part for you: matching customer language to SKUs, or composing the final proposal?