Replacing the spec-sheet scavenger hunt
Technical sales runs on answering the same forty questions. The library that answers them already exists. The problem has never been the information.
iKREATE DIGITAL LABSSix minute read
Somewhere in most technical companies there is a person who spends six hours a week answering questions they have answered before. Not because the answers are secret, and not because they enjoy it. It is because the answers live in a library that is technically public and practically unreachable, and the buyer would rather ask a human than open nine PDFs to find one paragraph.
The friction is retrieval, and it is filtering your pipeline
A technical pre sale is long, and most of it happens before anyone identifies themselves. An engineer evaluating a supplier reads, compares, forms a view, and only then makes contact. By the time a name appears in your inbox the decision is often mostly made.
So the questions asked during that silent phase matter more than the ones asked on a call. Can this supplier hold what I need? What does this material do at this temperature? Is my design going to come back with problems? Those questions get asked at eleven at night, by someone who will not fill in a form to receive a number, and who has three other tabs open on your competitors.
This is where the real cost sits, and it is invisible. Slow retrieval does not just delay deals, it filters them. The buyers who persist through a bad site are the ones already committed to talking to you. The ones who quietly gave up are not in any report, and they were the ones you had not earned yet.
Why a generic chatbot makes this worse
The obvious move is to put a chat window on the site. It usually backfires, and the reason is worth being precise about.
A generic assistant pointed at your website reads your marketing copy. Ask it a materials question and it will answer with a rephrased version of your homepage, because that is the only thing in front of it. When it does not know, it does not say so. It produces something fluent and plausible instead, which is what language models do in the absence of grounding.
In a technical domain a confident wrong answer costs more than no answer, because somebody acts on it.
A buyer told the wrong shrink rate designs around it. A buyer told the wrong temperature rating specifies it. And you will not find out, because the failure is silent on your side. The engineer simply concludes the tool is unreliable, extends that judgment to the company behind it, and closes the tab. You have spent trust to save effort.
What actually makes an agent domain grounded
The interesting engineering in an agent like this is not the model. Every serious model is capable enough. It is everything arranged around the model, and four decisions carry most of the weight.
The corpus is the product
Datasheets, process knowledge, tolerance standards, the design guidance that already exists, cleaned up, structured, and scoped to what your operation actually does. This is unglamorous work and it is the whole job. A capable model working from a good corpus outperforms a better model guessing, every time, and the gap widens as questions get more specific.
Scope is declared, not discovered
Decide in advance what the agent answers from, and what it must refuse. An agent that will attempt anything is not more capable, it is unbounded, and unbounded is another word for unpredictable. The boundary between what the library supports and what needs a person should be explicit in the system, not something that emerges from how a question happens to be phrased.
The behavior layer takes the most iteration
Hedging in ranges rather than absolutes. Asking a clarifying question when a description is too thin to answer responsibly. Saying plainly that something needs a human. Most of the build time goes here rather than into retrieval, because this is the layer a technical buyer is unconsciously testing. They are not checking whether it sounds knowledgeable. They are checking whether it knows what it does not know.
Evaluate against answers somebody will sign
Agents are easy to demo and hard to assess. A conversation that feels impressive is not the same as one that was correct. Build the evaluation set from the questions your team already answers by hand, because those have known good answers from people who have done the work. The bar is whether your own senior engineer would put their name on the transcript.
Knowing where it has to stop
The most important design decision is usually a refusal. Pricing, lead times, and commitments are human judgments with commercial consequences, and an agent that guesses at them will eventually guess wrong in a way that costs real money or a real relationship.
So the useful pattern is an agent that moves a conversation toward a quote and then hands off cleanly, rather than one that attempts the quote. Alongside that sit the unglamorous requirements that make the thing safe to run in public: a defined escalation path, a transcript you can audit, and a human approval step anywhere the output leaves the building. None of this is exciting. All of it is the reason the tool can sit on your site at all.
A worked example
We built one of these in a domain where being wrong is expensive, which is the honest place to test the idea.
What it changes commercially
The first change is the obvious one. The forty questions get answered properly, at two in the morning, without a form gate, and the person who arrives afterward already understands your constraints. Your sales engineer starts three conversations further along than they used to, and spends their time on the judgment calls that actually need them.
The second change is less obvious and may matter more. Every conversation is a record of what buyers genuinely want to know, in their own words, before anyone is performing for a salesperson. That is a better source of product and content direction than most research a company pays for, and it accumulates on its own.
Neither of these is really an argument about AI. It is an argument about retrieval, which is the same problem technical companies have had since the first spec sheet went into the first binder. The tools finally caught up with the problem. What matters now is whether you point them at a real library, or at your homepage.