A buyer waited from 4 business hours to 2 working days for a price. Now they ask in the portal and get it in seconds.
- Client
- A B2B company whose buyers order through a signed-in customer portal
- Users
- The client's business buyers, each under a company account
- Engagement
- A production AI assistant for product search and account pricing
The outcome in three lines
| Measure | Before | After | Evidence |
|---|---|---|---|
| Getting a price1 | 4 business hours to 2 working days | seconds, in the chat | Described |
| How a buyer asks2 | a search that returned long lists of near matches | a question in plain language, answered with their account's price | Described |
| Building the final quote for their own customer3 | waited on each price | shorter, no figure given | Described |
One line carries the client's own before and after figures. Two describe what changed for buyers and carry no number. The small number beside each line says how it is known.
The problem, in the client's terms
The client's business buyers needed prices to quote their own customers. Getting a price took a minimum of 4 business hours and up to 2 working days.
The catalogue made searching hard. Many products differ only by size, material, finish or brand, so a short search returns a long list of near matches. And the price depends on who is asking, because each company account has its own price in the client's pricing system.
Every hour a price is outstanding is an hour the buyer's own quote stays open. A buyer who cannot get a number today may quote from an old one, or take the order to a supplier who answers faster.
The assistant had to find the right item, then show that buyer's price, and never show one company's price to another.
- ConstraintA price comes only from the client's pricing system, for the signed-in buyer's own account.
- ConstraintBuyers ask in their own words, often for an item with many near twins.
- ConstraintEvery reply is one of four kinds the chat knows how to show.
The architecture, before and after
Switch between the two. The price moved from a reply someone sends to a lookup the backend releases, and the question moved into the buyer's own words.
- What hurt in this state
- Built in this engagement
Three decisions, and the options they rule out
Any team can wire a model to a catalogue. The choices below decide which item a buyer sees and whose price the backend may release. Each one names what it replaced and what it cost.
Who is allowed to release a price
Turned down
Trust the customer details the browser sends
Anything the browser sends can be edited, so nothing it says about the customer is trusted on its own. We removed a browser-side flag that let the page claim it was already signed in.
Turned down
Let the model read prices from a shared index
Each company account has its own price, so a shared copy either leaks one account's price to another or holds no price at all.
Chosen
Only the backend releases a price, after it checks the buyer
The price service verifies the signature on the portal's sign-in token, then checks that the signed-in customer is linked to the company account and approved, and only then asks the pricing system. The client's team added the company account check after we built the price tool and its sign-in check.
What it cost: Every priced answer waits on the client's pricing system, and the chat has to refresh the sign-in token before it expires and allow for clock drift on long turns.
Who chooses the next narrowing question
Turned down
Let a model pick the filters and the question
The model sometimes produced filter values that do not exist, reading a number from another specification as a size, and a filter that matches nothing returns zero results.
Chosen
Code picks the question, models only read the answers
A filter the model extracts is kept only if the search engine reported it for this query. Code then picks the next question by rule, and a model turns free answers such as "just pick the best one" into a skip, so the loop moves on.
What it cost: The rules for which filter to ask about first are written and kept by hand as the catalogue changes, and a reply inside a narrowing conversation can take up to six model calls.
How the model work is split, and what we would change
Turned down
One large model for every step, in our later view
Most messages are a classification or a short extraction, and a large model on each one adds cost and time to the common case.
Chosen
Eight small steps, already in place when we joined
Each step does one job and returns structured output the next step can check. An off-topic message stops after one model call.
What it cost: The calls add up. On the client's test system the median time per message rose from 3.2 to 6.6 seconds over three months, and a reply inside a narrowing conversation can take up to six model calls. We designed a version with at most two model calls per message.
How it was delivered
Our software engineer joined the client's team after the assistant's first workflow already existed. We built the chat, the price tool and the later workflow changes, and set up the reviewed release path it reached production through.
The chat in the portal
Sign-in check, session handling, conversation history, the product, list and question views, accessibility fixes and the pipeline that deploys the chat to the portal.
The price service
A price tool in the client's backend and the sign-in check in front of it. The client's team later added the company account check.
The workflow, kept as code
The workflow's code moved into version control and was built back into the workflow for each release. Exact matching for item numbers, checks on extracted filters, a loop breaker and stronger guardrails went in through it.
Measuring it
An evaluation suite in which a simulated buyer holds conversations and a judge model scores them, and timings read from the workflow's own run records.
Alerts and releases
Failures sorted by kind and paged by severity, and a release path from the test system to production through a reviewed pull request.
The next version
A design that merges the model steps into at most two calls per message, built and run on a local machine, not yet in production.
Who did the work
- Atyantik software engineerThe chat, the price tool, the later workflow changes, alerts, releases and measurement
- Client's teamThe chat's branding, the company account check, testing in production and day-to-day running
Who owns what now
The client's team runs the assistant and ships each change through the reviewed release path, which backs up production before it deploys.
Results
How long a business buyer waits for a price, before and after.
- Business buyers ask in their own words, narrow a long list in a few questions, and see their own account's price.
- Buyers quoting their own customers finish the final quote sooner.
- The client's team is paged by severity when the assistant fails, with repeats of one failure grouped into one incident.
No figure is given for how much sooner quotes are finished, or for how many price requests the assistant now answers.
4 business hours
Before, at the fastest
2 working days
Before, at the slowest
seconds
After, with the assistant
A buyer gets a price while they are still asking, not hours or days later.
| Option | Business hours from asking to getting a price, with a working day taken as 8 business hours. An answer in seconds is drawn at zero on this scale. |
|---|---|
| Before, at the fastest | 4 business hours |
| Before, at the slowest | 2 working days |
| After, with the assistant | seconds |
Source: Source note 1
What the wait costs you today
We do not publish what an engagement costs. So this works from your side: what answering price requests by hand costs today, and how long your buyers spend waiting.
Staff cost of answering price requests, per year
$21,000
- Staff hours spent answering, per year
- 600 h
- Business hours buyers spend waiting, per year
- 9,600 h
What went wrong, and what we would do first
A catalogue term tripped the model provider's filter, and the workaround leaked
[object Object]
Each model step added time
[object Object]
Will an assistant work for your pricing?
It fits when
- Business customers ask for prices often, and each request waits on someone on your team.
- Each company account has its own price, held in a system your backend can already call.
- Your catalogue has many near-identical items, so buyers need help narrowing before a price means anything.
Look elsewhere when
- Your prices are a short public list. A searchable price page may be all you need.
- Every price needs a person's judgement, as in a negotiated deal. An assistant can collect the details but should not answer.
- Your pricing system cannot return one account's price on request. Build that first, because the assistant can only release what the backend can look up.
Check it yourself this week
If the wait runs to hours and most answers are routine lookups, an assistant can likely answer them. Put your numbers into the calculator above.
- Count the price requests your team answered last week.
- Note when each one arrived and when the buyer got a price.
- Mark the ones answered by looking a figure up, with no judgement involved.
The stack, by layer
- ChatA chat window inside the client's signed-in customer portal
- OrchestrationAn agent workflow with filtering, routing and narrowing rules in code
- ModelsSmall hosted language models, one per step, with structured output and no fine-tuning
- SearchThe client's product search, with exact matching for item numbers
- PricingA price service in the client's backend that checks sign-in and company account first
- OperationsPaging by severity, structured chat logs and a reviewed release pipeline
- TestingAn evaluation suite with a simulated buyer and a judge model
How each figure was measured
- Before, the client's own figure for how long a buyer waited for a price. With the assistant, the client reports prices inside the conversation, and on the client's test system the median time to answer one message was a few seconds.
- How buyers ask for a price with the assistant, a question in their own words.
- Buyers' time to build the final quote for their own customer, shorter with the assistant, with no figure given.
Tell us how long your buyers wait for a price, and we will tell you if an assistant should answer.
Send the number of price requests a week and the usual wait. A software engineer reads it and replies with an honest answer, including when a better price page is the right fix.