Prospect Investigator: preparing for better customer conversations
An industrial-automation sales inquiry is the starting point for an AI-assisted research tool that helps turn public information into better preparation and more relevant customer support.
What you’ll get from this article
For sales engineers and people shaping customer-facing work:
- How large language models (LLMs) can support company research beyond the original inquiry.
- What the engineer contributes, and how source references support review.
- How that preparation can support focused customer materials and shared team knowledge.
- Why the process needs business-specific configuration and continued refinement.
A customer inquiry often starts with one product or technical question. In a small industrial-automation sales team, answering that question can leave little time to understand the wider situation behind it.
I built Prospect Investigator to make that broader preparation more practical. It is a personal project that uses large language models to help research public information about a company and prepare a structured report. I use those reports to prepare customer conversations.
The purpose is to recognize relevant ways to help. Imagine a customer asking about a machine-safety product while public information points to a planned paint-shop refurbishment. That finding could prompt a question about hazardous-area equipment. It does not establish a requirement: the engineer still needs to check whether the project is current and whether that support would be useful.
Mermaid source
flowchart TB
A[Machine-safety inquiry] --> B[Public paint-shop announcement]
B --> C[Engineer checks relevance]
C --> D[Focused customer question]
The report gives the engineer something to investigate, not a finished judgment. Its source references let them inspect original excerpts and open the underlying pages. Their industry experience and conversations with the customer add context that public research may miss. A customer can quickly explain that an announced project has ended, or that an unpublished one is taking shape.
That understanding can support more precise questions, focused product materials and a shared brief for colleagues joining the work. A library of communication scenarios can also make practical experience available to engineers facing unfamiliar situations.
The principle is to respect the customer’s time: learn what we reasonably can beforehand, then provide information relevant to their actual needs.
Mermaid source
flowchart TB
A[Public findings] --> C[Engineer judgment]
B[Customer knowledge] --> C
C --> D[Relevant questions, materials and shared brief]
Early experience has been encouraging. I compared a generated report with a sales engineer’s own research and found the contributions complementary. The engineer told me that having such a report would be a major help.
A sales engineer also pointed out that a report can provide useful topics for later conversations, even when prepared after the first contact. Research can be repeated for the same company, using updated contact notes, new information and different hypotheses to guide the next report. What we learn can inform later conversations and our wider understanding of the market.
The tool is being shaped through use. After each report, I record what helped and what did not, then refine sources, checks and the workflow. Research depth must fit both the business question and the cost of investigating it. Adapting the approach to another business would require its own questions, sources and interpretation criteria.
There is no public online demo: meaningful use requires preparation and substantial processing. For now, I am developing the project through real work. If you are exploring similar questions or would like to exchange experiences, feel free to get in touch.
Full article
In my sales work in industrial automation, the starting point is often a question from a customer. Someone needs information about a product, an application or a technical problem.
Answering that question is the immediate task. Understanding the situation around it can help us give a more useful answer: what the company builds, where the product will be used, and what else we need to clarify.
In a small team, it is difficult to find time for that research alongside calls, technical questions and other day-to-day responsibilities. I wanted to make deeper preparation a more consistent part of our work.
That is why I started building Prospect Investigator. It uses AI to help research public information about a company and organize the findings into a report. I use those reports alongside my own experience and what we learn directly from customers, to prepare more relevant questions and identify useful ways to help.
The research around an inquiry
Researching a company means bringing together information scattered across public sources: its website, project announcements, industry publications and other material available online. Much of the work is repetitive: locating relevant pages, checking what they tell us about the company’s activities, and looking for projects, applications or recent developments that matter to the inquiry. Those findings then need to be brought together into a useful picture.
As the number of sources grows, it becomes harder to keep track of what matters and how the findings connect.
Prospect Investigator helps with that work. Language models help interpret the collected material and organize it into a report that the engineer can examine. Public information can be incomplete, outdated or ambiguous, so the report needs to make its findings open to scrutiny.
In the report interface, the engineer can open a citation, read the original excerpt and follow a link to the source page. This lets them examine what supports a finding and whether the interpretation is justified. The source may still be outdated or leave important questions unanswered. Establishing what matters now often requires the engineer’s experience and a conversation with the customer.
Reading a substantial report carefully still takes effort. But I find assessing the findings, questioning them and deciding what to explore a more rewarding use of a sales engineer’s attention. There is something concrete to work with, while the engineer’s experience remains essential.
That matters for the employee as well as the business. A useful tool should help someone work effectively and experience the satisfaction of doing their job well.
What the engineer brings
During early use, I compared a generated report with a sales engineer’s own research. I found the two contributions complementary, and the engineer told me that having such a report would be a major help.
An experienced engineer brings knowledge that may never appear in public sources. They can recognize a relevant connection, question an interpretation or see a possibility we did not anticipate when configuring the research. Some of that knowledge is difficult to capture in explicit rules.
They can also speak with the customer. A publicly announced project may already be finished; a new machine or investment may be taking shape without any public announcement. A short conversation can change what the research means and where the work should go next.
Public findings, customer statements and an engineer’s hypotheses need to remain distinguishable. A possibility worth exploring should not quietly become an assumed customer need.
Imagine a customer asking about a machine-safety product. While the engineer works on that request, the report surfaces a public announcement about a planned paint-shop refurbishment. Equipment for potentially explosive atmospheres might be relevant, giving the engineer another question to explore.
A focused follow-up could be: “Is the paint-shop refurbishment still planned, and are there any requirements for equipment in hazardous areas that you would like us to help with?” The customer can clarify whether the project is current and whether that support would be useful.
The value is a broader view of the company around a concrete inquiry. It helps the engineer notice another possible area of support that might otherwise remain outside the conversation.
Mermaid source
flowchart TB
A[Machine-safety inquiry] --> B[Public paint-shop announcement]
B --> C[Engineer checks relevance]
C --> D[Focused customer question]
A sales engineer recently pointed out another use for these reports. After the initial conversation, once the obvious topics have been covered, it can become harder to find something useful to discuss next. A report can provide further points to explore with the customer, even when it is prepared after that first contact. Its usefulness extends into later conversations.
The research can also be repeated for the same company, using updated contact notes, new information and different hypotheses to guide the next report.
That is the practical contribution I look for: relevant information that helps us ask better questions, check our assumptions and understand the customer’s situation more clearly. What we learn in those conversations can guide the next contact and contribute to our wider understanding of the market.
Preparation should help the customer too
One principle behind this project is simple: I do not want to ask customers to spend their time explaining things we could reasonably have learned beforehand.
Preparation should make room for shorter, more precise questions. It should help us establish what remains unclear and whether we have something useful to contribute. The customer’s original question remains the immediate task; further discussion should follow what is relevant to their situation.
The same principle applies to the materials we provide afterward. If a customer is working through two or three specific issues, sending an entire product catalogue gives them another sorting task. I would rather provide information selected for the machine, application or project being discussed.
In the wider workflow, the research supports that preparation alongside other tools. One example is Scenario Spotlight, which turns structured material into application-focused PDF product sheets.
A shared library of communication scenarios can help make practical experience available across the team. An engineer encountering an unfamiliar situation can draw on suggested questions, email patterns and guidance on possible next steps. They do not have to invent an approach from scratch or already know every scenario. The purpose is to help them respond competently and with less preparation effort, while adapting the guidance to the customer in front of them.
These materials need the engineer’s judgment and the context gained from the conversation. Their value depends on relevance to the customer’s actual situation.
The customer should feel that we have made an effort to understand and help.
Keeping colleagues informed
Sales work often involves more than one person. A colleague may join a project, provide specialist support or cover an absence.
A shared brief helps them understand what has been learned, what remains uncertain and what needs to happen next. It can also reduce the need for the customer to explain the same situation repeatedly.
Maintaining that context takes work. An engineer may have a productive conversation and then struggle to find time to turn it into comprehensive documentation.
The approach I am developing starts with a lighter contribution: recording the relevant points and incorporating them into the wider case context. The person still needs to capture what happened. The system helps organize that information into something others can use.
This extends the purpose of the research beyond the report. It becomes part of keeping useful knowledge available as the work progresses.
Mermaid source
flowchart TB
A[Public findings] --> C[Engineer judgment]
B[Customer knowledge] --> C
C --> D[Relevant questions, materials and shared brief]
Fit the research to the decision
The right report depends on what we need to decide.
An inquiry provides a starting point, but we may still know little about the company behind it. We need enough context to understand the request. Later, specific questions or hypotheses may call for more focused research. The approach can also support initial research into an unfamiliar company, before any conversation has taken place.
The same collected information can support different summaries. A useful process therefore needs choices about inputs, sources, research depth and the form of the output.
My current application is shaped by industrial automation. General areas such as control systems or machine safety provide context for what might be relevant. Another business would need its own questions, source choices and interpretation criteria.
That adaptability is a direction I want to develop further. It requires understanding the business process as well as configuring software.
Research depth also has a cost. Reading more sources and performing more analysis consumes resources, and those costs matter increasingly as the number of companies grows. The question is how much additional investigation is useful for the decision at hand.
A tool shaped through use
The early feedback is promising, but the project needs continued work in real sales situations.
After each report, I record what helped and what did not. That feedback informs changes to sources, checks, the workflow and the importance given to particular information. This is an ongoing process of refinement.
I expect that fitting the tool well to the work will take repeated use across many reports.
What I have now is a practical way to explore a depth of preparation that would otherwise be difficult for our team to sustain.
There will be no public online demo here. A meaningful investigation requires substantial processing and preparation around a real business question. I do not want to create a simplified exercise that consumes resources without providing corresponding value. Being deliberate about computation is also part of how I want to use AI responsibly.
The next step is to keep improving the tool through use, while paying attention to what it makes possible for the people involved: better preparation, more relevant support and more time for the conversations from which business relationships grow.
If you are exploring similar questions, or would like to exchange experiences with this kind of project, feel free to get in touch.