A distribution company wants to use AI to prepare sales quotes. Inquiries arrive by email, often with attachments. Staff read the line items, look the products up in the ERP, check prices and stock, and then write the reply. The board hopes automation will cut the time customers spend waiting.
At the first meeting, a vendor shows a system that turns a sample inquiry into a finished quote in a matter of seconds. The demo is impressive. The conversation quickly moves on to price, timeline and which AI model to use.
Except nobody has checked yet why preparing a quote takes so long. Maybe retyping data really is the problem. Or maybe the quote sits for two days waiting for a manager's sign-off, even though in most cases that sign-off is no longer needed. In that case, automating document creation won't remove the main cause of the delay.
You recognize a good AI implementation partner not by how fast they show you a solution, but by whether they can work out what result the company is after, why it isn't getting it today, and what really has to change.
The first conversation: what are we after, and why aren't we getting it today?
A discovery conversation doesn't have to be a multi-day audit. At the start, the point is to understand the business goal, the size of the problem and what it costs. "We want to generate quotes automatically" describes an idea for a tool. "We want to answer customers faster, without hiring more salespeople and without pricing mistakes" describes the result you expect.
The vendor should want to know how many inquiries come in, how long they take to handle, what goes wrong most often and which cases have been stuck for a long time. But one question matters just as much: why does the company run this process the way it does?
Why does a salesperson look the product up by hand when the company has a catalog? Why are prices checked in several places? Why does every quote go through a manager? And why is that rule still in force if the way prices are set has changed since it was introduced?
This isn't about mechanically asking "why" five times. It's about getting to the causes and checking whether the answers hold up in day-to-day work. Sometimes a cumbersome procedure is there to control a real risk. Sometimes it's a leftover from an old system, one that nobody has questioned in years.
A good vendor should be able to sum up the first findings in their own words and separate what is already known from what is still a guess. If they say "You lose most of your time generating quotes," they should be able to say how they know. If they haven't checked yet, they shouldn't present a quote generator as the answer.
A demo can help show what the technology can do. It shouldn't replace the conversation about what's causing the problem.
The workshop: knowing how the process runs isn't enough
The first conversation sets a direction. A workshop lets you check how the work actually flows, ideally with the people who prepare quotes every day taking part, not just the board and IT.
The team can walk through a few closed cases, from the customer's message to the reply going out. They can see where the data comes from, who makes the decisions, what happens outside the ERP and CRM, where the delays build up and which exceptions create extra work.
A map of the activities is only half the job. For every important step, you also need to ask what it's there for. What does it protect against? Who gets information from it? What risk would appear if it were removed? Is there a simpler way to achieve the same thing?
Suppose every quote in this company needs a manager's approval. The team discovers the rule was introduced a few years ago, when salespeople worked prices out themselves and could give away too large a discount. Today, standard prices and discount limits are stored in the ERP, but the procedure hasn't changed. The manager still approves even the quotes that fall within the rules.
The first idea might be to use AI to prepare approval requests, send notifications and remind the manager about overdue quotes. That would speed up some tasks, but the queue of decisions would stay.
One more "why?" leads somewhere else: do standard quotes need manual approval at all? Maybe approval only needs to stay for unusual discounts and other exceptions.
Before the company removes the step, though, someone has to check whether the manager is also keeping an eye on customer risk, payment terms, product availability or commitments made in contracts. Not every inherited procedure is redundant. The value of the workshop lies in verifying what a step is for, not in assuming that everything manual should go.
The workshop should produce more than a description of the current process. It should also explain which steps to keep, change or challenge, and why.
A better process first. Technology after that
After that kind of groundwork, a responsible partner may propose something different from what the company originally asked for.
In our example, the target process could be simpler: standard inquiries go straight to quote preparation based on current data, with no extra manager approval, as long as they meet the agreed conditions. Non-standard cases still need a decision from someone authorized to make it. For both groups it's clear who owns the result and what to do when information is missing.
Only now is it time to choose the tools. An AI model can help recognize products and terms in a free-form email. Prices and stock should come from the systems that hold them, and discount terms can be checked with ordinary rules. We covered how to match technology to each step in the part on choosing between an LLM and simpler tools. If the existing ERP can handle the simplified path, there's no need to build a separate quote approval app.
In that version, part of the benefit comes from removing an unnecessary task, not from automating it. AI stays useful where it actually solves a problem, for example in interpreting ambiguous messages from customers.
So a good proposal should show the target way of working, the expected result, what can be removed, what needs automating and which assumptions still have to be checked. It should also leave room for the conclusion that, in a given area, changing a procedure or connecting two systems pays off better than bringing in AI.
A technology partner shouldn't be attached to the idea the client brought to the first meeting. They should be attached to the result the client wants to achieve.
Understanding the business is no substitute for AI and engineering skills
A well-run workshop doesn't prove the vendor can build something that works. Once the target process is agreed, they have to be able to turn it into a realistic technical design and point out its limits.
For sales quotes, they should understand how to get current data out of the ERP, how to match product names against the catalog, who can approve exceptions and when AI should hand a case to a person. They should be able to tell the difference between preparing a proposal and carrying out an action, such as sending the quote to the customer, and know how to confirm what actually happened.
You also need specific answers about AI quality: how it will be measured, which real cases the solution will be tested on, which mistakes are unacceptable and how you'll keep checking the results after launch. Then there's data security, integrations, exception handling, maintenance and the cost of running the whole solution, not just the models.
Ask for examples of earlier projects and ask how they run acceptance tests. The point isn't to get confidential details about their clients. It's to see evidence that the team understands the difference between an attractive prototype and a system the company can rely on every day.
A good partner has to combine the ability to challenge the process with the ability to safely deliver what the analysis shows actually makes sense. One without the other isn't enough.
Discovery should lead to a decision, not to another workshop
Not every project can be priced reliably after one conversation. A paid analysis phase can make sense when someone needs to study how the work flows, find the causes of delays, check whether procedures can be changed or verify access to systems.
A phase like that should have an agreed scope, cost, deadline and deliverables. The company should receive a description of the business goal and the problems identified, a map of the relevant part of the process, an assessment of whether its key steps are justified, a proposed change and a list of assumptions and risks. Where possible, it's a good idea to compare the current version with the proposed one and say how the expected benefits will be verified.
If the decision depends on a technical test, the vendor should spell out exactly what the test is meant to confirm. Running a workshop or building a prototype doesn't prove the project will pay off.
Discovery doesn't have to be a mandatory, paid first step in every engagement. When the problem, the process and the integrations are already understood well enough, you can go straight to a project with a limited scope. What matters is that the analysis can still be used if the company picks a different vendor or decides not to go ahead.
A worthwhile discovery phase can also end with a decision not to build the planned system. If the analysis shows that removing an unnecessary approval solves the main problem, that may be a better outcome for the client than buying yet another application.
How to compare partners before you sign
Now picture two vendors. One opens with a demo of a quote generator, like the one at the start. The other asks about the goal first, analyzes the process and questions whether some of its steps make sense. That's an important difference, but how the first meeting is run doesn't settle the choice. The first vendor may be perfectly willing to test their assumptions, and the second may run convincing workshops without being able to deliver the result.
Before signing, check five things:
- Understanding the goal. Can the vendor explain which business result the company wants to improve, where the current problem comes from and what still needs checking?
- Asking "why?". Did they learn not just how the tasks are done, but also why? Did they point to steps that could be simplified or removed, and check what such a change would lead to?
- Solution design. Do they propose a better process before choosing technology? Did they consider a version without AI, with less automation or built on the systems you already have?
- Credible delivery. Can they justify the architecture, the integration approach, the data requirements, how AI quality will be checked, how risk is controlled and how the system will be maintained?
- Terms of the investment. Is it clear what the company gets after each phase, how the result will be verified, who is responsible for what and when the project can be scaled back or stopped?
If a vendor proposes going straight to implementation, they should explain why enough is already known. If they propose a long discovery phase, they have to show which important unknowns it will clear up. Either way, what counts is evidence, not the names of the phases or how polished the presentation is.
A good AI implementation partner starts by asking why the company wants to change something. Then they check why the company works the way it does today, what's worth keeping, what should change and what can be dropped. Only then do they match technology to the process they've designed, and take responsibility for checking the result. That way the company doesn't pay to speed up tasks it may not need to do at all.