In technical sales, inquiry and tender documents are often technically incomplete. A short conversation with the engineer responsible for an application can clarify something that several pages of specifications leave unanswered. Digital procurement platforms have brought more structure and consistency to the process, but sometimes at the expense of direct technical communication. Even something as simple as providing a clear route for technical questions can make a difference.

It shows something worth remembering whenever new technology arrives: a change can improve one part of a process while making another more difficult. And however the work is organised, the underlying goal remains the same: to understand the customer’s application and arrive at a technically appropriate solution.

I see AI through much the same lens. My perspective comes from years in technical sales and years of building software for practical purposes. AI has become part of that work and has considerably expanded what I can do. But those new possibilities also deserve careful judgement. Does the technology help the right information reach the person who needs it, in time? And is the effort involved worth the result?

Less noise, better timing

Most people working in business already have more information than they can comfortably process. Emails, CRM records, technical documents and shared folders contain years of correspondence and experience. Finding the right detail can take longer than expected, particularly when it comes from another colleague or an earlier project.

I see a practical opportunity for AI in making selected information available at the moment somebody needs it.

A new inquiry arrives from an existing customer. Two years earlier, a similar product was proposed and rejected because of its connection method. The explanation still exists in correspondence handled by another colleague, but nobody preparing the new quotation knows about it.

A system that recognises the relationship between the new inquiry and the earlier discussion could present a short observation:

A similar solution was previously rejected because of the connection method. Check whether that requirement still applies.

A link to the original correspondence would allow the salesperson to verify the information before preparing the offer. That single observation might prevent unnecessary work or suggest a question that would otherwise have been overlooked.

Making it dependable is the difficult part. The system must identify the correct customer and product, then judge whether an objection from two years ago still applies. It also needs to recognise when the evidence is too thin to say anything. Sometimes providing no additional information is the correct result.

An assistant that offers ten plausible signals for every inquiry could quickly become another thing to ignore. In safety-related work, however, a missing condition may have much greater consequences than an additional warning.

The same approach could support handovers. When someone covers for a colleague on holiday, relevant information may be scattered across sales emails, a technical support discussion and a revised quotation. A concise briefing assembled from authorised sources could help the colleague understand the situation without reconstructing every conversation from the beginning.

Connecting what the business already knows

Technical sales depends on more than customer history. Product specifications, operating conditions and experience from previous applications all contribute to a good decision.

These sources are rarely organised together. Customer correspondence may be recorded in a CRM, while technical documentation lives elsewhere. Application experience is often spread across service reports, specialist notes and emails.

Existing business platforms already provide summarisation and search capabilities. The harder work is deciding which information matters for a particular task and making it reliable enough to act on. The same verified product information and documented application experience could also support a tailored explanation accompanying a quotation, reducing the effort required to prepare customer-specific materials.

Historical records offer another possibility: investigating patterns that nobody previously recognised. A sales manager might want to examine whether inquiries with incomplete technical requirements tend to remain unresolved longer than those with clearly defined conditions. Language models can help extract comparable information from correspondence, while conventional analysis can examine patterns across the resulting data.

Those patterns require interpretation. A relationship in the records does not establish what caused it, particularly when the available information is incomplete or the circumstances differ between customers.

The deeper limitation concerns what was never documented. An order shows which product was purchased, while the reasoning behind that decision may remain in someone’s memory. No model can recover reasoning that was never recorded.

This makes everyday information capture worth reconsidering. Recording a few relevant observations through dictation after a customer conversation is considerably easier than preparing a formal report. A short explanation of why a solution was chosen, or what still needs confirmation, may become valuable to another colleague later.

That information also needs appropriate handling. Customer correspondence and historical records may be subject to confidentiality, access restrictions and legal retention requirements. Any reuse must respect those boundaries.

New possibilities for smaller, specialised software

AI can help create software as well as operate inside it. Capable language models now assist with analysing requirements, writing conventional code, preparing example scenarios and designing tests. This can lower the effort of developing some specialised applications. A tool that identifies particular signals in industrial correspondence may need a language model for only part of the job, with explicit rules, verified reference information and text matching handling the rest.

Building with AI has shown me how much design work sits behind an apparently simple result. Producing a plausible summary is relatively straightforward. Deciding which information matters, preserving evidence and checking whether the result deserves attention require considerably more thought.

AI can also help developers generate test scenarios, including unusual situations that might otherwise be overlooked. The expected results still need to be established independently. A model cannot prove its own work correct simply by generating more tests.

For smaller industrial companies, this creates an additional option. An organisation without advanced AI features in its existing business software may still find it practical to develop a focused workflow for a recurring task. Such a tool could operate alongside an established CRM or support a process that does not belong in the CRM at all. Its scope might be narrow, but that can be an advantage when the purpose is clear and the results are straightforward to evaluate.

The business has to describe the work

The easier software becomes to build, the more depends on someone explaining the work correctly.

An external development company can analyse documents, interview employees and propose a solution. But people inside the business still need to explain how the actual work happens.

A technical inquiry may follow a straightforward procedure until information is missing, requirements contradict one another or a particular application needs specialist approval. Experienced colleagues understand why these distinctions matter and what a suitable response should involve.

A process that looks simple in a diagram may involve exceptions, informal checks and accumulated experience that nobody has formally documented.

Clear operating procedures, technical guides and internal notes already help colleagues perform their work. With consistent structure, ownership, revision information and well-described exceptions, those materials can also become useful inputs for software development.

Specification-driven development, an established approach in which documented requirements and expected behaviour guide implementation and testing, fits naturally here. AI-assisted development tools can work with such descriptions more directly, helping developers prepare software implementations and test cases based on agreed requirements.

When a business procedure changes, a maintained specification makes the necessary adjustments easier to identify and communicate. The developers still have to implement and verify the changes, but the connection between the business requirement and the resulting software is clearer. Current documentation can support a new colleague today and a development project next year.

Business practitioners therefore have a direct part in shaping these systems. Their knowledge helps establish what correct behaviour looks like and how the finished application should be evaluated.

Making the effort worthwhile

AI can make an application technically possible without making it economically sensible.

A recurring task that consumes a few minutes hundreds of times each month may offer an opportunity to reduce effort. Another process may occur less frequently but involve technical or safety consequences significant enough to justify additional checks.

The costs are easy to underestimate. Historical information may be too fragmented to interpret reliably. Integration can be expensive, while changes in products and procedures create ongoing maintenance work. Reviewing generated information also consumes time, particularly when mistakes are difficult to recognise.

Attention has a cost too. An assistant that interrupts employees with marginal observations can reduce the benefit it was intended to provide.

Before committing to a solution, the practical questions are how often the problem occurs, what improvement is realistic and how to recognise a successful result. A small experiment using representative cases is often enough to establish whether the idea is worth pursuing.

Sometimes an existing software feature will be sufficient. In other situations, changing the underlying procedure may achieve more than introducing another application.

A focused AI workflow earns its place when it does something worthwhile that the alternatives cannot do as well, at a cost that makes sense for the organisation.

Starting with the work

People working in industrial businesses already know a great deal about where improvement is needed. They see where handovers become difficult and where important technical details go missing. There is no need to start with a grand AI project when an ordinary problem gives us something concrete to examine.

I also think this is a good moment to broaden what we learn, without giving up the depth of our own professions. A salesperson does not need to become a programmer, but understanding more about information, software and how processes are described can change the questions they ask. Being able to explain a decision clearly, separate a requirement from an assumption or record why an exception matters is useful even if nobody builds a system around it today.

I think back to those short technical conversations that settle what a formal inquiry leaves open. They work because somebody knows the application well enough to ask the right question. That expertise still matters, even when the tools become more capable.

There is plenty of work left to do in business, and I find that encouraging. We can examine familiar processes more carefully and try approaches that were previously too difficult or costly. We may not yet know what all those possibilities are. That seems a good reason to keep learning, and to pay closer attention to the work we already know.