Skip to contentForbesElevon in Forbes

    Automotive dealer

    Free-text fleet inquiry in, priced offer out

    An automotive dealership handles B2B fleet inquiries that arrive as free text: models, quantities, terms, and options described in a prospect's own words. Elevon built a suite where AI agents read and structure the inquiry, deterministic code computes the pricing so numbers are never produced by the language model, and an HTML generator assembles a complete, presentable price offer.

    Free-text inquiry in, finished priced offer out. The agent understands the request, code does the pricing, so the numbers are always right.

    • IndustryAutomotive
    • TypeElevon Platform
    • DeploymentProduction

    What changed

    • Minutesfrom inquiry to finished offer (estimate)
    • Exact pricingnumbers from code, never guessed (estimate)
    • Free text → offerone raw inquiry in, one offer out (estimate)

    01The challenge

    Where it started.

    A B2B fleet prospect rarely fills in a clean form. They describe what they need in their own words: a mix of models, how many of each, financing or leasing terms, and a list of options and extras. Before anyone can send an offer, someone has to read that free text, work out exactly what is being asked for, and turn it into a structured order.

    In detail

    The second half of the work is pricing, and it has to be exact. A fleet offer combines base prices, option packages, quantities, and commercial terms. A single wrong number in a written offer is not a small mistake; it is a commitment the dealership may have to honour or an embarrassing correction to walk back. Done by hand, each offer takes a salesperson real time, and every manual calculation is a place an error can enter.

    The obvious temptation is to hand the whole task to a language model. But a model that both interprets the request and produces the prices can quietly invent a number that looks plausible and is wrong. For an offer that has to be exact, that is not acceptable.

    Quote

    “The model reads the request and code sets the price. That split is the whole point: we get the flexibility of free text without ever letting a number be guessed.”

    02What we built

    Agents and workflows, on one platform.

    One clear division of labour: the agent understands language, code does the arithmetic, and strict contracts keep the two apart.

    elevonAUTOMOTIVE DEALERAgents and workflowsElevon Platform

    Input

    StepFree-text inquiryOn

    Analyze · AI

    AI agentInquiry analyzerRunning
    OutputStructured request (JSON)Delivered

    Price · Code

    StepPrice calculatorOn
    StepOptions & termsOn
    StepValidationOn

    Output

    StepHTML generatorOn
    OutputPriced offerDelivered
    Illustrative reconstruction of the production suite.

    Why the Elevon platform

    • The agent reads the inquiry

      An analyzer agent reads the free-text inquiry and works out what is actually being asked for: which models, how many of each, which options and packages, and which commercial terms. Its job is understanding, not pricing. The output is a structured request, not a number.

    • Code does the pricing, not the model

      Every price is computed by deterministic code from the structured request and the dealership's own price data. The language model never produces a number, so a price can never be hallucinated. The same inputs always yield the same total, and every figure is traceable to a rule.

    • Strict contracts between every stage

      Strict JSON contracts sit between the analyzer, the price calculator, and the HTML generator. Each stage hands the next exactly the shape it expects, so a malformed request is caught at the boundary instead of turning into a bad offer downstream.

    03Rollout

    Step by step.

    The suite runs as a short pipeline. The analyzer agent turns the free-text inquiry into a structured request and emits it as JSON. The price calculator takes that JSON, applies the dealership's price data, option packages, quantities, and terms, and computes every figure in code. The HTML generator takes the priced result and assembles a complete, presentable offer. A JSON contract defines the handover at each boundary.

    How it runs

    Because pricing lives in code and not in the model, the price logic can be reviewed, tested, and updated on its own. When rates, packages, or discounts change, the calculator changes; the analyzer and the generator stay as they are. Each stage is replaceable without touching the others.

    In practice

    A fleet inquiry arrives as free text. The analyzer reads it and produces a structured request: models, quantities, options, terms. The calculator prices it in code against the dealership's own data. The generator assembles a complete HTML offer the salesperson can review and send. What used to be reading, interpreting, and hand-calculating an offer becomes a check of a finished document.

    04Results

    What changed.

    The flow is working in production and maturing: free-text inquiries come in, finished priced offers come out.

    • Minutesfrom inquiry to finished offer (estimate)
    • Exact pricingnumbers from code, never guessed (estimate)
    • Free text → offerone raw inquiry in, one offer out (estimate)

    The figures above are illustrative and show the shape of the impact, not measured results. Replace them with the client's real inquiry volumes, offer turnaround times, and pricing accuracy to finalize.

    • Free-text fleet inquiries turned into structured requests automatically
    • Every price computed by deterministic code, never produced by the language model
    • Complete, presentable HTML offers assembled without manual formatting
    • Strict JSON contracts between analyzer, calculator, and generator catch bad data at the boundary
    • Offer turnaround reduced from a salesperson's manual work to minutes of review

    Why it worked

    The instinct with a task like this is to give a language model the inquiry and ask for the offer. It reads well in a demo and fails in production, because the same model that interprets the request also invents the prices, and an invented price that looks right is worse than an obvious error. For an offer that has to be exact, you cannot let the numbers be generated.

    The suite works because it uses each part for what it is good at and nothing else. The agent does the one thing models do well: read messy free text and understand intent. Deterministic code does the one thing that has to be reliable: compute the prices. Strict JSON contracts keep the boundary clean, so the request the calculator prices is exactly the request the agent understood. Free text in, exact offer out, with no point in the pipeline where a number can be guessed.

    Quote

    “A wrong number in an offer is a serious problem. Moving the pricing out of the model and into code is what let us trust the output enough to send it.”

    Next step

    Your process could be the next case.

    A 30-minute call. You tell us about one process, and we say whether it fits the platform, a product build or a consulting project.

    Contact us

    We use essential and analytics cookies by default to ensure proper functionality and understand site usage. Marketing cookies are off unless you opt in. Privacy Policy