Rob Conant

Enterprise sales is a multi-player game. Most AI is single-player.
A typical deal in the semiconductor industry pulls in one or more applications engineers, a regional sales leader, maybe a global account manager, and an applications marketing specialist. <a href="https://www.gartner.com/en/sales/topics/sales-pipeline">Gartner puts the average B2B buying group at 11 active members</a>, each with their own perspective and their own ability to say no. A healthy deal means engineers talking to engineers, procurement working with sales and operations, execs aligning with product leaders. Everyone has a role, and like any good team, the ones who play together well are the ones who win.
But most companies are rolling out AI as if enterprise sales were a single-player sport.
<h2>Generic chat tools don&#39;t move the needle</h2>
They deploy Copilot, ChatGPT, or Claude across the org, and then wonder why productivity and win rate barely move. Each rep, each marketer, each applications engineer works their own slice of the problem with their own AI — an AI with no idea who else is on the deal, what the account&#39;s history is, or what the rest of the team already knows. It&#39;s not a surprise this doesn&#39;t move the needle: <a href="https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo">MIT&#39;s State of AI in Business 2025 report</a> found that 95% of enterprise generative AI pilots deliver little to no measurable P&amp;L impact, and the pattern shows up worst in workflows like sales that are inherently collaborative rather than solo.
The root cause is architectural. Chat interfaces are built single-player by design: one person types, one person reads the answer, and at best they forward the output to a teammate. At worst, that one person&#39;s thinking drifts in its own direction, quietly diverging from the rest of the team without anyone noticing. That&#39;s the opposite of how strong sales teams actually function, where a stakeholder map, an objection that came up on a call, or a competitive data point needs to reach five people, not stay with the one person who asked the question.
<h2>The cost of five solo plays</h2>
The cost shows up in familiar ways:
<ul>
<li>the same research gets redone by three different people on the same account.</li>
<li>Messaging drifts between the AE and the applications engineer because they&#39;re each getting a different answer from their own chat window.</li>
<li>A cross-sell sitting in plain sight in another region or business unit never surfaces, because no system connects the two reps who&#39;d need to see it together.</li>
</ul>
And this is not just theoretical — <a href="https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/unlocking-profitable-b2b-growth-through-gen-ai">one McKinsey case study of a global industrials company</a> found that once a shared research and intelligence layer was fully rolled out to the sales team, conversion rates rose 40% and lead execution sped up 30% — a result that came specifically from giving the whole team the same intelligence, not from individual productivity gains.
<h2>What multi-player AI actually looks like</h2>
A few markers, based on where the more sophisticated teams are already heading:
<ul>
<li>Shared Context. Context is aggregated at the <a href="/solutions/deal-room">account and deal</a>, person, and <a href="/solutions/application-room">application</a> level, not in a private chat history. Anyone new to the deal inherits what&#39;s already known instead of starting from zero.</li>
<li>Constantly Evolving. Every touchpoint — a call, an email thread, a CRM update, a piece of public news — enriches the shared context.</li>
<li>Automatic Connections. The system actively makes connections a human wouldn&#39;t have time to find: a rep in one region working the same application as a rep in another, an expansion opportunity implied by usage data sitting in a different business unit.</li>
<li>Multi Player. Collaboration is the default behavior, not a manual &quot;share&quot; button bolted onto an individually-oriented tool.</li>
</ul>
None of this is exotic — it&#39;s closer to how the best account teams already operate without AI. The tools that get this right don&#39;t look like a better chatbot. They look more like infrastructure for how teams already think about strategic accounts: shared, cumulative, and built for teams with multiple roles.
Enterprise AI&#39;s real unlock in sales isn&#39;t a smarter model. It&#39;s making the AI a teammate the whole deal team is playing with — not five people quietly playing five separate games.

Enterprise sales is a multi-player game. Most AI is single-player. Why generic chat tools barely move win rates, and what shared, team-level AI looks like.

Single-player AI doesn't cut it for sales

I joined a smart-metering company to run engineering, then took over sales and marketing. That was my first exposure to true Enterprise Sales: large deals ($1M+), large buying committees (up to dozens of stakeholders), and long cycles (12+ months was typical). Having a great product was important in these deals, but sales played a big role in the deal too: the customers (electric utilities in this case) were making a big bet on a supplier. Not only could a bad decision have a big negative impact on the company, but the individual stakeholders were often risking their careers on the decision. The decisions these utilities made were rooted in hard, measurable facts, but the final decision was a decision of people. A decision of confidence that the people had the capability and the commitment to deliver success.
In the age of AI this does not change one bit.
In my last post I talked about Credence Goods - products where the value of a deal is difficult to determine at the decision time. The perceived value is dependent on trust: trust of the company to deliver, trust that the unspecified or unmeasurable capabilities exist in the company and the product, trust that the product quality is high (even on things that are difficult to verify), trust that the company roadmap will continue to evolve in the right direction, and trust that the company will be a reliable supplier and partner. This is typical of Enterprise Sales - both large enterprise-software deals and most OEM sales. Enterprise Sales are built on trust.
You wouldn&#39;t know that looking at most AI sales startups. They often imply that sales success is determined by email volume and accurately reading online intent signals. And for the transactional end of the spectrum they&#39;re right: for high-velocity, lower-value deals, an AI that knows the product cold and answers instantly will often beat the average rep, and a lot of what buyers call &quot;distrust&quot; of AI there is really just unfamiliarity that will fade. But Enterprise Sales requires a different level of trust. Trust that an AI assistant or auto-generated email will not deliver.
We can bucket sales into product-led growth (PLG) and Enterprise Sales, or sales-led growth (SLG), and later we&#39;ll see how the impact of AI will be very different in those two models.
PLG is typically lower value, fast-closing deals, often with self-service signup and close. Slack is the classic example of getting started with a PLG GTM approach. A lot of the SaaS boom over the past decade has been PLG companies selling to other startups then expanding to more small and medium-sized customers. As PLG companies mature they sometimes move up to Enterprise Sales as they sell larger deals to larger customers.
Enterprise Sales or SLG is typically the higher value ($100k+), longer-cycle deals (often 12 months or more). Enterprise software companies like Salesforce, industrial OEMs like semiconductor companies, investment banks, consultants all fit in the Enterprise Sales category. This is less common in the SaaS startup world because Enterprise Sales requires more senior salespeople and the velocity isn&#39;t as high, so it doesn&#39;t automatically favor fast-moving startups.
The focus of the GTM for each of these is quite different. Below is a comparison.
<table>
<thead>
<tr>
<th></th>
<th>Product-led growth (PLG)</th>
<th>Enterprise Sales / Sales-led growth (SLG)</th>
</tr>
</thead>
<tbody><tr>
<td>Prospecting and Discovery</td>
<td>Product does the prospecting. Inbound signup, self-serve trial, freemium usage - the &quot;prospect&quot; finds you because the product&#39;s value is legible enough to try without a conversation.</td>
<td>Company must actively identify and pursue targets. Because the buyer can&#39;t self-qualify from a website, someone has to go find the accounts where the problem is real and start earning attention before any product is touched.</td>
</tr>
<tr>
<td>Qualifying</td>
<td>Behavioral/usage-based. Product analytics (seat count, feature adoption, usage frequency) substitute for a qualifying conversation - the data tells you if this account is worth pursuing.</td>
<td>Conversation-based, often multi-threaded. Because the value is unverifiable up front, qualifying means assessing the buyer&#39;s problem, budget, and internal alignment - and assessing whether they trust you enough to keep talking.</td>
</tr>
<tr>
<td>Closing</td>
<td>Self-service or lightweight sales-assist. Low price point and low perceived risk mean the buyer can decide alone - a credit card, not a committee.</td>
<td>Requires demonstrated trust: references, pilots, executive alignment, sometimes a champion who vouches for you internally. The close isn&#39;t a decision about the product - it&#39;s a decision about the supplier.</td>
</tr>
<tr>
<td>Deployment</td>
<td>Self-serve activation. In-product guidance, tooltips, and time-to-value emails carry the user to their first win - the product onboards itself, because if it needed a human to work, it wouldn&#39;t be PLG.</td>
<td>The moment of decision and the moment of proof are different moments, often separated by months. In enterprise software it&#39;s implementation and rollout; in OEM sales it&#39;s the ramp from design win to production. The buyer committed on incomplete information, and now reality either confirms the leap of faith or quietly erodes it - which is why a person has to shepherd it, not a workflow.</td>
</tr>
<tr>
<td>Expanding</td>
<td>Product-led expansion: usage triggers upsell (more seats, higher tier) with minimal human involvement.</td>
<td>Relationship-led expansion: account teams, executive sponsors, and a track record of delivery convert a pilot into a platform relationship - trust compounds instead of usage compounding.</td>
</tr>
</tbody></table>
There is a lot of innovation in AI for PLG companies - the VC-funded companies serving the VC-funded AI SaaS companies, and it&#39;s a crowded space with lots of companies doing similar things. But AI for Enterprise Sales? That&#39;s a totally different animal, with a totally different set of requirements.
The hard problem in AI for sales is: how can we use AI to increase trust in Enterprise Sales?
Stay tuned for thoughts on where and how AI is building trust in Enterprise Sales.

Enterprise sales runs on trust. The hard problem for AI sales tools is increasing that trust, not just automating emails or reading intent signals.

The Hard Problem: Building Trust with AI Sales

Munzer Dwedari

Eric Saund

Retrieval Augmented Generation (RAG) is a popular method that gives Large Language Models (LLMs) the ability to retrieve knowledge during answer time from live documents. The way it works is straightforward: given the user query, search millions of document chunks through semantic vector search, rerank the top n, then feed that to the LLM to generate the answer. The method has become standard in enterprise knowledge but it breaks when the knowledge domain is about complex technical products, like in semiconductor companies.
The complexity of technical questions arises when the answer requires navigation among the technical documentation. Traditional RAG only searches chunks that are semantically similar to the question/query. It is not able to navigate from a product page to a product family or datasheet to get the correct information. Hence, a smarter method is required where reasoning is part of the knowledge discovery.
Agentic RAG is a new method where the LLM is the driver of the knowledge discovery process, as described in the recent <a href="https://arxiv.org/abs/2501.09136">Agentic Retrieval-Augmented Generation</a> survey. Instead of a single RAG call, the LLM can decide which knowledge sources to search, what document URLs to follow and apply restrictions to the search space. Let&#39;s look at an example question based on TDK&#39;s public website. When a user asks &quot;Does RSEN-2030 contain PCBs?”, traditional RAG can find the RSEN-2030 product page but the answer is not there. The correct answer lies in TDK-Lambda&#39;s environmental page about “asbestos, PCBs, and mercury”. Agentic RAG first finds the RSEN-2030 product page, sees the link to the actual target page, and does a second retrieval step to get its content. The final answer correctly states that RSEN-2030 is a production product and that production products in the latest catalog are listed as &quot;Non-contained&quot; for PCBs, with references to both the <a href="https://product.tdk.com/en/search/emc/emc/power-line/info?part_no=RSEN-2030">product page</a> and the <a href="https://www.jp.lambda.tdk.com/en/environment/asbestos_pcbs_and_mercury.html">environmental page</a>. In this blog, we discuss how we think about agentic RAG at ept AI and how it affects technical product knowledge.
<h2>Our Approach to Agentic RAG</h2>
Knowledge Structure at ept AI
At ept AI, we manage knowledge as configured, governed sources that can be assembled for different channels, teams, and customers. A <a href="https://docs.ept.ai/docs/configuration/knowledge-sources/">Knowledge Source</a> can be a website, PDF library, community forum, GitHub repository, documentation, Zendesk or HubSpot knowledge base, or anonymized support tickets. A <a href="https://docs.ept.ai/docs/configuration/knowledge-source-configurations/">Knowledge Source Configuration</a> combines those sources into the exact body of knowledge a channel is allowed to use.
Our Agentic RAG Tool
<img src="/images/blog/agentic-retrieval/fig1.svg" alt="Fig. 1: AI workflow using Traditional RAG vs Agentic RAG. Unlike Traditional RAG, in Agentic RAG the LLM has the ability to do multiple loops of knowledge retrieval where it decides what the query is, and how the search space is constrained.">
Fig. 1: AI workflow using Traditional RAG vs Agentic RAG. Unlike Traditional RAG, in Agentic RAG the LLM has the ability to do multiple loops of knowledge retrieval where it decides what the query is, and how the search space is constrained.
Our agentic knowledge retrieval tool for LLMs is built around that knowledge base model. The tool description tells the LLM which Knowledge Sources exist in the active Knowledge Source Configuration, including each source name, ID, type, description, and source URL. The LLM does not search an anonymous pile of chunks. It chooses which Knowledge Source to search and what to search (see Fig. 1). This capability allows users to guide LLMs how to look for information for a given task like customer support, e.g.: &quot;first look in historical tickets, then in private documentation and finally the website before getting back to the user.&quot; Another benefit of this approach is that the LLM is in control of what queries get used for the search and can do repeated searches to optimize the search query. This turns many &quot;I don&#39;t have enough information&quot; answers to actual answers grounded in data. Yet, even within a Knowledge Source, the information can be too scattered and result in inaccuracies with vector search.
<img src="/images/blog/agentic-retrieval/fig2.svg" alt="Fig. 2: Query search constrained to two subsets of data of two Knowledge Sources. The colored overlayed boxes represent tags applied to a set of documents. One document can have many tags (overlapping colored boxes). The dotted boxes are the constrained search space chosen by the LLM.">
Fig. 2: Query search constrained to two subsets of data of two Knowledge Sources. The colored overlayed boxes represent tags applied to a set of documents. One document can have many tags (overlapping colored boxes). The dotted boxes are the constrained search space chosen by the LLM.
This shift to agentic knowledge retrieval is <a href="https://developer.nvidia.com/blog/traditional-rag-vs-agentic-rag-why-ai-agents-need-dynamic-knowledge-to-get-smarter/">not a new phenomenon</a>. With the introduction of GPT-5, tool use has become much more reliable with LLMs (see <a href="https://openai.com/index/introducing-gpt-5-5/">GPT-5 performance on Toolathon</a>). What we found at ept AI is that for our customers, often large companies with a large portfolio of technical products, e.g. semiconductors, require a more granular search into their data. In addition to Knowledge Source selection, we added the capability for our system to tag data with industry-and-company-specific taxonomy and allow the LLM to constrain its search space to any subset of the tagged data (see Fig. 2). This matters most in industries where the source type changes the authority of the answer. In semiconductors and electronics, a casual webpage, a marketing catalog, a selector guide, a compliance page, and a datasheet do not carry the same weight. For engineering decisions, the answer often needs to be grounded in official datasheets, family specifications, or technical information PDFs. Those documents are the sources teams treat as binding for part selection, operating limits, storage conditions, regulatory claims, and more. Agentic RAG lets us narrow toward those industry-specific, source-specific records instead of relying on whichever chunk happens to be semantically closest.
Consider a troubleshooting question about <a href="https://synaptics-astra.github.io/doc/v/latest/">Synaptics Astra documentation</a>: &quot;Playback audio doesn&#39;t match the behavior defined in the reference voice-assistant example.&quot; In this case, we have instructions in the system prompt to always search the &quot;latest version of documentation&quot; for that specific Knowledge Source. The LLM, having the full visibility of Knowledge Source tags, does not spread across mixed documentation branches or generic product pages. Instead, it stays entirely inside one Astra documentation version, <code>1.6.1</code> (the latest version at the time). The retrieved evidence includes the Astra Linux docs at <a href="https://synaptics-astra.github.io/doc/v/1.6.1/linux/index.html">synaptics-astra.github.io/doc/v/1.6.1/linux/index.html</a> and all retrieved documentation URLs for this response were from the same <code>1.6.1</code> branch, which is exactly the behavior we want for version-sensitive technical questions: once the version context is present, the search stays pinned to one documentation lineage instead of blending evidence across releases.
Putting the user in control is equally important. Users are now able to express retrieval intent in normal language: &quot;search the public website,&quot; &quot;look inside this datasheet,&quot; &quot;use the product page first,&quot; or &quot;only use official docs&quot;. Under the hood, that maps to Knowledge Source Configurations, Knowledge Source IDs, queries, and tags. This gives the user a practical navigation layer over complex knowledge sources. We have already seen customers use it internally to perform documentation discovery and summary to improve their knowledge base.
<h2>Performance Comparison</h2>
We test the new Agentic RAG method in two ways: quantitatively on a set of 100 single-fact questions, and qualitatively, by inspecting traces on selected questions where the answer requires navigating across product pages, documentation versions, and linked PDFs. The point of the evaluation is not simply, &quot;did the model answer?&quot; It is, &quot;did the model find the right evidence path, stay inside the right knowledge boundary, and give the user a source they can trust?&quot;
<img src="/images/blog/agentic-retrieval/fig3.svg" alt="Fig. 3: Quantitative Results. Panel A: bar chart comparing faithfulness for Traditional vs. Agentic RAG, 80% to 85%. Panel B: bar chart comparing average high-relevance retrievals per response, 4.37 to 6.">
Fig. 3: Quantitative Results. Panel A: bar chart comparing faithfulness for Traditional vs. Agentic RAG, 80% to 85%. Panel B: bar chart comparing average high-relevance retrievals per response, 4.37 to 6.
Our first test (Fig. 3) compares the new method to the old one based on 100 single-fact short technical questions (based on real production traffic). For the previous method, these questions are not particularly challenging and are mostly answered correctly. The goal of the test is to verify that the new method matches the correctness of the old method since now we have an LLM driving decisions for the knowledge retrieval. Indeed, we see that the new method produces answers that are similar to the old answer in 96% of the time. In addition, we also see that new LLM response&#39;s <a href="https://arxiv.org/abs/2505.04847">faithfulness</a> improves from 80% to 85%, meaning the LLM&#39;s answer is more grounded in data than the previous method. The previous method returns, on average, 4.37 retrievals with a high relevance score to the question whereas the new method returns 6 high relevant retrievals per response. Relevance here is measured using an <a href="https://arxiv.org/abs/2411.15594">LLM-as-a-judge.</a> Across the same 100 questions, traditional RAG returns 1,534 total retrievals, or almost 16 per response, while the new workflow returns 3,160. That is more retrieval work, but it is not just noise: the number of highly relevant retrievals increases. For technical support and applications engineering, that matters because the final answer is only useful if it is backed by enough precise evidence to be reviewed, cited, or escalated. In practice, we care less about the raw number of retrieved chunks and more about the shape of the evidence. A single loosely related chunk can produce a fluent but fragile answer. A larger set of high-relevance retrievals gives the model a better chance to compare sources, catch missing constraints, and cite the right document. The observed result is exactly the behavior we want: more focused evidence, higher faithfulness, and preserved answer correctness.
For the qualitative evaluation, we inspect 3 different questions on public websites where we have previously seen that the previous method fail. Consider a question about whether <a href="https://product.tdk.com/en/search/emc/emc/power-line/info?part_no=B84143A0008R105"><code>B84143A0008R105</code></a> (a TDK Power Line EMC Filters) can be used at 3000m altitude. A plain semantic match can find the part number page and the datasheet, but the governing detail lives in technical information about altitude derating. The agent searches broadly, finds the relevant datasheet family and technical-information PDF, then narrows retrieval to those documents. The final answer does not stop at &quot;usable&quot; or &quot;not usable.&quot; It explains that standard conditions apply up to 2000m and that 3000m requires derating, giving the current derating factor of 0.925 and voltage derating factor of 0.880. That changes the response from a lookup into an engineering answer. The previous method found the part page, but it does not navigate to the technical-information PDF where altitude derating is defined, so it misses the 2000m baseline and the required 3000m derating factors.
Another example involves storage conditions for <a href="https://product.tdk.com/en/search/sensor/ntc/chip-ntc-thermistor/info?part_no=NTCG103JF103FT1"><code>NTCG103JF103FT1</code></a>, a Chip NTC Thermistor (Sensor). The product page itself is not enough. The useful information is in the NTCG series catalog linked from that product page. With the new method, the LLM first retrieves the product page, then constrains the search to the <a href="https://product.tdk.com/system/files/dam/doc/product/sensor/ntc/chip-ntc-thermistor/catalog/tpd_commercial_ntc-thermistor_ntcg_en.pdf">catalog PDF</a>, and answers with the storage temperature, humidity, and handling notes from that document. This is a common pattern in component documentation: the SKU page identifies the part, but the binding storage, handling, or reliability rule is often in the family-level catalog. The previous method only reaches the product page.
Version-sensitive documentation is another place where a constrained search space matters. In a Synaptics Astra question explicitly framed around ASTRA v1.5.0 and third-party software license information, the retrieved Astra documentation stays on the <code>1.5.0</code> branch, including the <a href="https://synaptics-astra.github.io/doc/v/1.5.0/EULA.html">EULA</a>, v1.5.0 release notes, and a software update user guide. The retrieval set also includes a small amount of non-versioned support material, but it does not mix Astra docs from <code>latest</code>, <code>main</code>, or other versions. The search space constraint is enabled by tagging the data and giving the LLM the visibility and ability to use these tags: the model recognizes that version is part of the retrieval intent and avoids blending documentation across releases, which otherwise would cause the model to hallucinate and answer based on outdated documentation.
<h2>Challenges and Limitations</h2>
While Agentic RAG as described above results in higher accuracy, less hallucination, and better knowledge navigation, it comes with a few challenges. One of the main challenges is prompting: guiding the LLM on how to use the new tool(s). If the prompt is too permissive, the agent may over-search, spend too many tool calls, and return slowly. If the prompt is too restrictive, it falls back into one-shot Traditional RAG behavior and misses linked evidence. The best balance is to set clear goals for the LLM and make every tool orthogonal and explicit: one tool should have a clear job, clear inputs, and clear guidance for when to use it. While our agentic knowledge retrieval tool offers a sophisticated way for LLMs to navigate technical knowledge, the orthogonality question becomes especially challenging when multiple search tools are available, such as internet search or product catalog lookup. Accurate and clear tool descriptions help the LLM avoid confusion about what each tool does and when to use it.
Traceability is the second challenge. Agentic systems are harder to evaluate because the final answer is only part of the behavior. We also need to inspect the path: which tools were called, which URLs were discovered, which tag filters were applied, and whether the answer comes from the right authority. Our in-house traces already record tool calls, queries, retrieved URLs, outputs, and more. That makes it possible to let us tune prompts without guessing and also allows us to inspect latency and improve upon the speed of the agent.
<h2>Conclusion</h2>
Agentic retrieval represents the third phase of applying LLMs to question answering. The first phase was Traditional RAG, in which a single LLM call is applied to retrieved knowledge chunks. The second phase was strong orchestration, where multiple LLM calls are deployed, but in a highly structured workflow. Today, two factors enable the Agentic RAG breakthrough. First, LLMs and their associated prompting methods have become reliable enough to trust the LLM to make its own decisions about what tools to call, what knowledge to pursue, and when it is ready to compose a final answer. Second, the associated infrastructure of knowledge organization, retrieval methods, and performance management have evolved to provide LLMs with effective tools and methodologies. These become especially important in specialized knowledge domains like engineering, sales, and support of technically sophisticated products. This post illuminates some of the methods we have found to be effective at ept AI.

How agentic RAG turns one-shot vector search into controlled, multi-step knowledge discovery—and why that matters for semiconductor and technical product teams.

What Agentic Retrieval Means for Technical Product Knowledge

Amit Rele

Your sales team is covering a lot of accounts. There&#39;s no way to give all of them the time it takes to really understand them — the stakeholders, the competitive threats, which product lines fit the customer&#39;s architecture, what&#39;s happened in every prior conversation. Some accounts get that attention. Others have enough history that the team assumes it&#39;s not needed. Most get whatever the rep can piece together beforehand. It&#39;s a capacity problem.
CRMs capture what happened. They don&#39;t tell you what matters next. They log the contacts you already know — not the stakeholders you&#39;re missing. And they don&#39;t understand semiconductors or hardware — they can&#39;t reason about product fit, application architectures, or which business unit to lead with in a given account. That&#39;s not a knock on CRM. It&#39;s what CRM was built to do.
Generic AI tools don&#39;t solve it either. They know nothing about your products, your deals, or your customers. A Copilot or ChatGPT license can make someone more productive in a general sense. It can&#39;t tell a rep which product line to lead with in a specific account, surface a cross-sell opportunity across business units, or generate a pre-call plan grounded in the actual history of that relationship.
Deal Room is built for that specific problem — and it works with your CRM, not around it.
<h2>What It Does</h2>
Deal Room is a persistent workspace organized around a single deal — its own stakeholder map, its own intelligence thread, pulling from CRM records, email threads, and meeting transcripts, updated continuously as new information comes in. It stays live and is shared across everyone working the deal.
Before every meeting, it generates a pre-call plan in minutes: named stakeholder hot buttons, competitive risks specific to this deal, product angles grounded in what&#39;s actually happened so far. One sales leader described the ask directly — pre-call planning summaries generated automatically, saving significant prep time. That&#39;s not a feature request. That&#39;s a real cost being measured.
Because it understands hardware, it can do things CRM never could. Pre-built battlecards comparing your product vs the competition. Application architectures that map where your products fit. Cross-sell signals that surface not just the lines the rep knows, but adjacent lines they might not pitch — a recently acquired product family, perhaps. In one case, a team used it to identify three relevant product lines for an account that had gone quiet. The customer responded to all three. That email became a team template.
When a rep leaves, the Deal Room stays whole. Every insight accumulated over the life of the deal is there for whoever picks it up next.
<h2>Who It&#39;s For</h2>
Deal Room is built for semiconductor and hardware sales cycles — long timelines, multiple stakeholders, deep product portfolios, design-win-centric pipelines. The buyers are VP Sales, Head of Sales, and CRO — the people accountable for revenue per headcount. The ept AI platform addresses technical depth and market intelligence through other products. Deal Room is the account intelligence layer for the reps running deals.
The underlying problem is structural. Most deal intelligence lives in the heads of the people who built the relationships. What changes when that intelligence becomes a shared, current workspace — accessible to every rep, every time — is not just one deal. It&#39;s what your whole team can carry into every meeting.
We build your demo from your own product catalog and accounts — so you see exactly how Deal Room would work for your team before you commit to anything. Usually 30 minutes. <a href="https://go.ept.ai/meetings/eptai-demo/ept-ai-demo">Request a demo</a>.

Deal Room is a persistent, shared workspace that turns CRM records, emails, and transcripts into account intelligence—pre-call plans, battlecards, and cross-sell signals grounded in hardware.

Deal Room: Account Intelligence for the Entire Sales Team

Your products fit more markets than you&#39;re currently selling into. The challenge isn&#39;t product fit — it&#39;s that understanding where the fit is, who the buyers are, and whether a vertical is worth pursuing requires research that&#39;s slow, time-consuming, with external dependencies and almost always out of date by the time a decision gets made.
Market size estimates live in expensive analyst reports. Competitive landscape mapping means hours of web searches and reading conference programs. The ecosystem of customers, partners, standards bodies, and competitors is scattered across trade publications, LinkedIn, and the heads of the three people on the team who&#39;ve worked that space and in your desired GEO before.
The result is a static snapshot that gets distributed across the company in PowerPoint. Roadmap and GTM decisions made on incomplete information, with months of latency between the market signal and the response.
Some teams try to close this gap with generic AI tools — asking ChatGPT to summarize a market or build a competitor list. That gets you part of the way because it doesn&#39;t connect the market picture with your specific product portfolio. It doesn&#39;t internalize your catalog, your existing customers, or where your products have historically won. The output is generic because the input is generic.
Application Room is different because it&#39;s built on your product knowledge. It understands your catalog — your datasheets, application notes, technical requirements — and uses that context to map an application area in a way that&#39;s specific to your company&#39;s position in it, not a generic overview any competitor could pull. We do that work for you, and we can do it for multiple segments concurrently so your team isn&#39;t starting from scratch every time a new market comes into scope.
<h2>Who It&#39;s For</h2>
Application Room serves the commercial team members responsible for identifying and entering markets — before individual deals are being worked.
Product Managers, Product &amp; Applications Marketing and Business Development who own market analysis and entry decisions and are responsible for translating market intelligence into roadmap direction and field-usable positioning.
Sales teams — use it to ground outreach in the customer&#39;s actual technical environment and to walk into industry events prepared. Rather than generic messaging, they enter conversations knowing the companies in the space, what&#39;s driving their buying decisions, and where the natural product fit is.
<h2>What It Does</h2>
Application Room is a market and ecosystem intelligence workspace. A user describes a target application, vertical, or use case and Application Room assembles a structured picture of that space:
<ul>
<li>Market trends, sizing and segmentation — addressable market, growth vectors, dominant application areas.</li>
<li>Ecosystem mapping — Tier 1 OEMs, emerging challengers, systems integrators, standards bodies, and the relationships between them</li>
<li>Competitive landscape — how competitors are positioned relative to your portfolio, where you have natural advantages, where the gaps are</li>
<li>Technical requirements — what buyers in this market actually need: performance specs, certifications, form factors, integration dependencies.</li>
</ul>
In yesterday&#39;s world, an analyst report from six months ago might have been adequate. In today&#39;s accelerated global market, it won&#39;t reflect what&#39;s happening right now — or in your specific geography. Application Room stays current as the competitive landscape and ecosystem evolve — so when an expansion conversation comes up, it&#39;s grounded in what the market looks like today, not last quarter.
From within an Application Room, a user can identify a target company and generate a deal workspace in a single action — carrying the application context directly into the account pursuit. Because Application Room understands the application landscape, it can also surface adjacent markets and use cases where your portfolio has a natural fit you hadn&#39;t considered — expanding the opportunity picture beyond the vertical you started with.
<h2>Where It Fits in the Sales Motion</h2>
Application Room operates at the top of the funnel — but not in the sense of marketing lead generation. It&#39;s the intelligence layer that determines which markets and accounts should enter the funnel at all.
Before the funnel: A team is evaluating whether to pursue a vertical or application area. Application Room is how they make that decision with data rather than intuition — mapping the opportunity, identifying the players, and surfacing the technical fit before any development or selling effort is committed. This is where the generic AI gap is most acute: a tool that doesn&#39;t know your products can tell you the market exists, but it can&#39;t tell you whether you have a credible position in it.
At funnel entry: Once the decision to pursue is made, Application Room feeds account selection. Rather than building from a generic company list, the team identifies prospects who fit the specific ecosystem picture the Application Room has assembled — with the right product lines and entry angles already mapped.
Deal initiation: From within an Application Room, a user can identify a specific prospect and generate a deal workspace in a single action, carrying the application context directly into the account pursuit. The rep doesn&#39;t start from scratch — they start with the market intelligence already in place.
We build your demo from your own product catalog and target application — so you see exactly how Application Room would work for your team before you commit to anything. Usually 30 minutes. <a href="https://go.ept.ai/meetings/eptai-demo/ept-ai-demo">Request a demo</a>.

Application Room maps markets using your product catalog—trends, ecosystem players, and competitive fit—so technical sales and BD teams pursue the right verticals.

Application Room: Market Intelligence for Technical Sales Teams

<h2>Some things don&#39;t sell on a datasheet alone</h2>
It&#39;a exciting what AI can do for sales, but it will be put into operation differently in different industries where we have different sales processes. My focus is on enterprise B2B sales, and in my experience in Internet of Things (IoT), smart grid / energy, enterprise software, and semiconductor sales, I&#39;ve seen a common thread in these enterprise B2B sales processes: they&#39;re built around trust and alignment.
Trust and alignment are critical in enterprise B2B sales because your customers are not just buying your product. They&#39;re buying you, your company, your product, and your future products. A formal framework for this comes from economists Phillip Nelson and, later, Michael Darby and Edi Karni. They sorted goods into three categories:
<ul>
<li>Search Goods. The customer can establish the value of through specs. A gallon of gas, or a clearly specified semiconductor product.</li>
<li>Experience Goods. The customer establishes the value only by experiencing your product. A meal at a restaurant, or a microcontroller software stack.</li>
<li>Credence Goods. The customer may not even be able to establish the value after consuming it. Like a medical procedure, a next-generation chip, an investment banker, or an enterprise software platform.</li>
</ul>
<img src="/images/blog/trust-curve-b2b-enterprise-sales.png" alt="Chart showing that in B2B enterprise sales, trust required to close rises sharply as customers move from buying a spec to buying the whole partnership">
<h2>It&#39;s the purchase, not just the product</h2>
Many enterprise B2B products fall into the Credence Good category: you&#39;re not buying a finished thing off a shelf. You&#39;re choosing a partner whose success has to stay intertwined with yours for the value to be realized.
The banker&#39;s advice only pays off if they keep working your interest through a multi-year process. The software platform only delivers if the vendor keeps investing in your use case and your roadmap. The custom subsystem only works if the supplier keeps engineering alongside you through revisions no one could fully spec up front.
That&#39;s why these decisions run on trust. Trust is a forecast about alignment — made before you have any evidence.
However much research the customer does, however much our salespeople help with the evaluation, however many executive meetings align the direction — when the customer finally chooses a supplier, they are taking a leap of faith. We - as salespeople - have to earn it.
<h2>An example: choosing a motion-control subsystem</h2>
A large surgical robotics company is choosing a new motion-control subsystem for its next-generation system. The company sells thousands of these multi-million-dollar pieces of equipment per year, and the reliability, accuracy, and precision of the mechanical subsystem are critical to how the robot performs.
The subsystem has to be custom designed for this next-generation system, so there is no historical data for this new motion-control subsystem — nothing to benchmark against, no installed base to point to.
The company is left to evaluate not just the technical reliability of the motion-control subsystem, but also the business integrity and reliability of the supplier itself, because it&#39;s committing to years of shared engineering, not a one-time delivery. The decision comes down to the credibility and track record of the supplier as much as the expected performance of the product.
<h2>Earning trust</h2>
That credibility and performance of the supplier is not something that shows up on a datasheet. It is something that is earned, every day, by great salespeople.
AI can help with this, but cannot replace it.
That is what we keep in mind every day as we serve salespeople at ept AI.

Trust - critical for enterprise B2B sales - is something that is earned, every day, by great salespeople.

All articles

Single-player AI doesn't cut it for sales

The Hard Problem: Building Trust with AI Sales

What Agentic Retrieval Means for Technical Product Knowledge

Deal Room: Account Intelligence for the Entire Sales Team

Application Room: Market Intelligence for Technical Sales Teams

When Your Product Can't Be Bought on Spec