Build a B2B ecommerce AI assistant or buy one: three tests on your own portal
A packaged assistant is quick to switch on. Whether it can quote the right number to the right company is a separate question, and your own systems hold the answer.
Should you build a B2B ecommerce AI assistant or buy one?#
Buy one when your account prices and catalogue already live in the platform that sells the assistant, and build when the price must come from your ERP after a check on who is asking. That covers most cases. However, each half hides a test you can run on your own systems.
The buy case is strong. Take Salesforce's Trailhead module on Buyer Agent, as of 12 October 2026. It describes an assistant that "identifies negotiated pricing her company is entitled to". So if your negotiated prices already sit in that platform, the vendor has done the hard part.
The build case starts where the prices sit somewhere else. Algolia's guide to personalised B2B pricing is dated 21 September 2026. When per-customer prices stay out of its index, it says, "you can't use them for sorting or filtering". Then something else has to fetch the price, and it has to know who is asking.
That is the design in the B2B pricing case study. There, only the backend releases a price, after it checks the sign-in and the link between the customer and the company account. In short, the choice turns less on chat quality and more on where your prices live.
How many business customers want to buy without a sales rep?#
Gartner's survey published 20 May 2026 found 70% prefer a completely digital, self-service buying experience, and 69% still check insights from AI with sales reps. The press release covers 645 buyers in B2B purchasing, surveyed from August to September 2025.
Most of your customers want to serve themselves, yet most still check what an AI tells them with a person.
Show data table
| Item | Value |
|---|---|
| prefer a completely digital, self-service buying experience | 70% |
| validate AI-generated insights with sales reps | 69% |
| used GenAI in a recent purchase | 45% |
Most of your customers want to serve themselves, and almost as many check what AI tells them with a rep.
Both findings point the same way. Sixty-seven percent of those surveyed, the same 20 May 2026 Gartner release says, prefer to buy with no sales rep at all. Meanwhile, 45% said they used generative AI in a recent purchase, mostly to learn about vendors and products. So your customers already ask AI tools about what you sell.
However, the second finding is the catch. Because so many still check with a rep, a wrong price or part does not save a call. Instead, it creates one, and it costs some trust on the way. An assistant that answers fast but quotes another account's price is worse than a slow email.
As a result, this sets the bar for everything that follows. Chat polish matters less than two plain facts: the right part, and the right price for the signed-in company.
What does a packaged AI assistant for B2B ecommerce already do?#
The packaged assistants search your indexed catalogue, ask follow-up questions over the results, and, inside a commerce platform, can see the prices that platform already holds. Whether a vendor sells it as a B2B ecommerce chatbot or an AI sales assistant for distributors, its documentation describes a conversation over data it already has. Pages with no date are cited as of 12 October 2026.
- Algolia Agent Studio. Algolia's Agent Studio docs, dated 28 July 2026, say it "grounds responses in live data from your Algolia indices". Its tools page adds client-side tools for "authenticated actions" in your app.
- HawkSearch Conversational Search. HawkSearch, a site search product from Bridgeline Digital, says its conversational search uses "current search results as context for user questions."
- Zoovu Conversation Studio. Zoovu's overview describes drag-and-drop digital assistants that suggest products from your catalogue. A Zoovu representative activates it.
- Spryker AI Commerce. Spryker's AI Commerce page, dated 15 June 2026, lists image search, order forms filled from a photo, and a Back Office assistant for admin users.
- OroCommerce AI Smart Agent. Oro's AI concept guide describes an assistant for logged-in customers that finds "product details, pricing, inventory levels" inside the OroCommerce storefront.
- Salesforce Buyer Agent. The Trailhead module describes an assistant that finds products and the negotiated prices held in Salesforce.
Notice where the data comes from in each case. First, a search product answers from its index. Meanwhile, a commerce platform answers from its own price books and orders. Also, these are not the only products on the market, and others sell similar features. Still, the pattern holds for every product named here.
So the first question for a vendor is not how smart the chat is. Instead, ask where the price in the answer comes from, and whether your real prices live there.
| Product | What its documentation describes | Read |
|---|---|---|
| Algolia Agent Studio | Grounds responses in live data from your Algolia indices; client-side tools for authenticated actions | 28 July 2026 |
| HawkSearch Conversational Search | Uses current search results as context for follow-up questions | As of 12 October 2026 |
| Zoovu Conversation Studio | Drag-and-drop digital assistants that suggest products from your catalogue | As of 12 October 2026 |
| Spryker AI Commerce | Image search, order forms filled from a photo, a Back Office assistant for admin users | 15 June 2026 |
| OroCommerce AI Smart Agent | Product details, pricing and inventory levels for logged-in customers in the storefront | As of 12 October 2026 |
| Salesforce Buyer Agent | Finds products and the negotiated prices held in Salesforce | As of 12 October 2026 |
What does Salesforce's agent for B2B commerce need before it runs?#
Salesforce lists Agentforce Commerce for B2B, a Service Cloud or Sales and Service edition, Agentforce, Einstein for Service and Einstein generative AI before its agent can be enabled. That list sits on the Trailhead module, as of 12 October 2026, under required licences and add-ons.
For a portal already on Salesforce B2B Commerce, this is the strongest buy case on offer. The same module follows a lead purchaser named Rebecca at an industrial manufacturer. There, Buyer Agent finds parts and applies her company's negotiated entitlements. So if your prices and accounts already live in Salesforce, Buyer Agent reads data you already keep.
Salesforce is also widening where Buyer Agent works. A trade report in Digital Commerce 360, dated 24 June 2026, covers the launch. According to Digital Commerce 360, Salesforce announced Buyer Agent and a Merchant Agent, and Buyer Agent meets customers in WhatsApp and SMS conversations.
The cost question is the licence stack, and its price is not public. Salesforce's commerce pricing page, as of 12 October 2026, shows "Contact for pricing" on its commerce editions. So ask for the full stack in writing, with each add-on, before you compare it with a build.
Still, there is one honest limit. If your account prices live in an ERP and reach Salesforce only in batches, Buyer Agent can only quote what was last copied over. That is the first test.
Who is allowed to show a signed-in customer their account price?#
Only your backend should release an account's price, after it verifies the sign-in token and checks the customer is linked to that company account. When each company account has its own price, that price cannot sit in a shared search index. Instead, it has to come from a service that checks who is asking before it answers.
Algolia's personalised pricing guide, dated 21 September 2026, points the same way. It suggests fetching each customer's price "from another database" at display time, because prices kept out of the index cannot drive sorting or filtering. Similarly, commercetools, a headless commerce platform, documents a product search for B2B catalogues. It returns "Products with resolved, negotiated Prices" scoped to each account.
In practice, Atyantik's case study shows the same rule in a custom build. Its price service verifies the signature on the portal's sign-in token. Then it checks that the signed-in customer is linked to the company account and approved. Only then does it ask the pricing system. The client's own team added the company account check later, after the price tool and its sign-in check.
The case study also names the options it turned down. First, it did not trust customer details sent by the browser, because anything the browser sends can be edited. Second, it did not let the model read prices from a shared index. As the case study puts it, "a shared copy either leaks one account's price to another or holds no price at all."
So the test is short. Ask where each account's price lives, and what checks the caller before that price leaves. If the answer is your commerce platform, buying stays simple. If it is your ERP, the assistant needs a backend service in front of it.
| Option | What it does | In the case study |
|---|---|---|
| Trust the customer details the browser sends | Takes the company account from the request | Turned down: anything the browser sends can be edited |
| Let the model read prices from a shared index | One copy of prices for every account | Turned down: a shared copy either leaks one account's price to another or holds no price at all |
| The backend releases the price after its checks | Verifies the sign-in token, checks the link to the company account, then asks the pricing system | Chosen; every priced answer waits on the client's pricing system |
How long does your pricing system take to answer one request?#
Every priced answer waits on your pricing system, so time one account-price lookup before choosing a tool that calls it inside a chat. A chat answer is only as fast as that lookup plus every model call placed in front of it.
Atyantik's case study, published 11 October 2026, names this cost plainly: "Every priced answer waits on the client's pricing system". The same 11 October 2026 case study also measured the model side. On the client's test system, the median time per message rose from 3.2 to 6.6 seconds as model steps added up.
3.2 s
Earlier
6.6 s
As model steps were added
Each model step added to a reply added seconds to it.
Show data table
| Option | median seconds per message on the client's test system, from the workflow's run records |
|---|---|
| Earlier | 3.2 s |
| As model steps were added | 6.6 s |
The reason is simple: in that build, each message passed through small model steps, and each step did one job. Because a reply inside a narrowing conversation could take up to six model calls in that 11 October 2026 case study, the seconds stacked. As a result, the case study records a redesign with at most two model calls per message. It was built and run on a local machine and is not yet in production.
So that gives you two things to measure. First, time one account-price call against your ERP during a busy hour. Second, ask each vendor how many model calls sit between a question and a priced answer. For example, Algolia's Agent Studio docs, dated 28 July 2026, describe two model steps: one to choose tools and one to write the answer.
If your price call takes several seconds on its own, no assistant will feel instant. In that case, fix or cache the lookup first, whichever route you choose.
What happens when one search returns a long list of near-identical parts?#
When parts differ only by size, material, finish or brand, the assistant has to ask a narrowing question, and code should choose which one. A long list of near twins is not an answer, and a better search box alone does not fix it.
Atyantik's case study describes this catalogue problem directly. Many products differ only by size, material, finish or brand, so a short search returns a long list of near matches. In that build, a model first picked the filters and the question. However, it sometimes produced filter values that do not exist, and "a filter that matches nothing returns zero results."
The fix in the case study is a split of duties. A filter the model extracts is kept only if the search engine reported it for that query. Then code picks the next question by rule. Meanwhile, a model only reads free answers, so a reply such as "just pick the best one" becomes a skip and the loop moves on.
By contrast, packaged tools take a lighter route. HawkSearch's conversational search, as of 12 October 2026, uses the current results as context for follow-up questions. Similarly, Algolia's tools page lists a Grouped Results tool that can "Show a shortlist grouped by theme instead of one flat result list."
Those features may be enough for a catalogue with clear names. However, if your parts differ by one attribute that customers rarely type, ask the vendor to run your ten hardest real searches. Then count how often its follow-up question is one your sales desk would ask.
The case study also names the cost of the custom route. Its rules for which filter to ask first are written by hand. So they need upkeep as the catalogue changes.
What does waiting for a price cost you today?#
In Atyantik's case study published 11 October 2026, a price took 4 business hours at the fastest and 2 working days at the slowest before the assistant. With a working day taken as 8 business hours, the slowest wait is 16 business hours.
Show data table
| Item | Value |
|---|---|
| fastest reply before the assistant | 4 h |
| slowest reply before the assistant (2 working days) | 16 h |
Before the assistant, one price took between 4 and 16 business hours.
Price requests a month times the wait per request gives the business hours your customers spend waiting a year. That is the number any assistant has to beat.
Take an illustrative portal with 200 price requests a month. At the 11 October 2026 case study's fastest wait of 4 business hours, that is 200 times 12 times 4, or 9,600 business hours a year. At the slowest wait of 16 business hours, the same illustrative volume comes to 38,400 business hours.
Your customers' yearly wait for prices
Enter your price requests a month and the business hours each one waits; it multiplies them by 12 months to give the business hours customers spend waiting a year.
Business hours customers spend waiting a year
9,600
Arithmetic from the Atyantik Technologies case study, 11 October 2026. Modelled, not measured.
Those hours matter. The case study notes that each hour a price is outstanding keeps your customer's own quote open. So a slow price can cost an order, not only time.
So use your own request count rather than the example. Then weigh the yearly figure against the licence stack for a packaged tool, or the cost of a build that holds up in production. If the figure is small, neither route may be worth it this year.
When is a custom build the wrong fit?#
Skip the custom build when prices are a short public list, when every price needs a person's judgement, or when your pricing system cannot return one account's price on request. In each case, something simpler works.
- Your prices are a short public list. A searchable price page may be all you need, as the case study itself says.
- Every price needs a person's judgement, as in a negotiated deal. An assistant can collect the details, but it 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.
There is a fourth case worth naming. If your prices and catalogue already live in a commerce platform that sells an assistant, try that one first. For a portal on Salesforce B2B Commerce or OroCommerce, the vendor's own assistant reads data you already keep. In that case, a custom build would repeat work the vendor has done.
The wider market also argues for patience. NAW (National Association of Wholesaler-Distributors) and MDM published In Pursuit of Value in 2026, a survey of over 400 senior distribution leaders. In that NAW study, 73% of distributors say they expect results from AI, yet only 16% have achieved them.
73%
Expecting results from AI
16%
Have achieved those results
Far more distributors expect results from AI than have achieved them.
Show data table
| Option | percent of distributors surveyed |
|---|---|
| Expecting results from AI | 73% |
| Have achieved those results | 16% |
That gap is a reason to start with the narrowest job, such as price lookups, rather than an assistant that tries to do everything. It is also a reason to fix the data an assistant depends on before you add the assistant.
How do you run the three tests on your own portal this week?#
Count last week's price requests, time one account-price lookup in your ERP, and run a handful of real part searches to see how many near matches come back. Those three measurements, plus four questions to each vendor, settle build or buy.
The case study's own self-check starts the same way:
Count the price requests your team answered last week.
Note when each one arrived and when the customer got a price.
Mark the routine ones.
These are answers found by looking a figure up, with no judgement involved.
Time one account-price lookup.
Run it against your ERP during a busy hour, and note the slowest result.
Run ten real part searches.
Use the searches your customers actually type, and count the near matches each one returns.
Then put four questions to each vendor, in writing:
- Where does the price in an answer come from? It may be the platform's own price book, an index, or a call to your system.
- What checks the caller before a price is shown? Ask whether it verifies the sign-in and the link to the company account.
- How many model calls sit between a question and a priced answer? Ask for a measured median, not a target.
- What exactly is licensed, and what is metered? Salesforce lists its required licences on Trailhead. Also, Algolia's Agent Studio docs, dated 28 July 2026, say agent requests count toward your search usage and may add charges.
If the answers show your prices live in the vendor's platform, buy. However, if they live in your ERP behind a sign-in check, build a B2B ecommerce AI assistant around a backend price service. Plan that service first, then choose the chat that sits on top of it.
Where should you go from here?#
Start with the case study of an assistant built this way, then the posts on product data and commerce architecture if the decision is still open. The B2B pricing case study shows the price service, the narrowing loop and the timings described above.
If product data is the weak link, the post on whether to build or buy a PIM (a product information management system) covers the same choice one layer down. If your platform cannot call a custom price service, see headless versus traditional ecommerce. Also, if AI tools outside your portal need your price and catalogue data, see whether to build an MCP server. For the general case, see custom software versus off-the-shelf software. For the same question about an internal assistant, see when building your own internal AI assistant beats a per-seat licence.
Atyantik's pages on ecommerce development, ERP development and API integrations describe the portal, the pricing system and the service between them. Still, the three tests above need none of that. Your own request log, one timed lookup and ten real searches are enough to decide.