Next WrldThe scene repeats often. A company asks for a meeting to quote software, two or three people sit down, and the first hour goes explaining the basics.
Who asks what, through where? Where is it recorded? Who approves and who learns late? Nobody brought that data ordered, so everything advances on “it more or less works like this”.
It isn’t disinterest. Nobody told them what to bring. And what is understood there determines scope, timing and quote seriousness.
Preparing doesn’t require tech knowledge. It requires telling the work well.
Tell the process as it happens today
First tell the process step by step, without improving it from memory.
Who initiates the request? Who reviews, decides, executes and verifies? What happens when something gets stuck?
Following a real case end to end helps. No “in general we do”. Better: “last week this happened, and these were the steps”.
That shows rules, people, decisions and coordination. Technology comes afterwards, as consequence of that circuit.
No need to have everything perfect or documented. The software company helps define and order. What speeds everything is arriving with honest context, not closed answers.
List tools and what lives in each
Second list what you use today and which information lives in each place.
Where is the order built? Where is approval kept? Which part lives in email, which in chat, which in the accounting system?
A simple list suffices: tool, what you use it for, who uses it and what it leaves unsolved.
That map shows where loading duplicates, where visibility is lost and where errors and rework appear. Often the problem isn’t missing a new system, but information split across places that don’t talk.
Maybe the answer is custom software, maybe ordering what exists, integrating two tools or changing an internal rule. The criterion is one: the least complexity needed to correctly solve the problem.
Define what you want to change and how you will notice
Third is the goal, said in operations terms.
What should work differently in a few months for the project to have been worth it? Fewer errors? Faster decisions? Less manual follow-up? Fewer duplicated purchases?
Think how you will notice it with what you have today: how many follow-up inquiries arrive, how long an approval takes, how many times the same data must be asked.
If this worked well, what would we stop doing by hand? What would stop depending on one person’s memory?
Order priorities and tell edge cases
Every process has its usual path and exceptions. And exceptions usually define whether software works.
That is why order priorities: what is critical, what can wait, what would be desirable someday. Saying it upfront avoids over-quoting when the urgent is a small part.
And tell edge cases honestly: urgent purchase without prior approval, supplier changing price last minute, partial delivery, invoice arriving before goods.
How often do they happen? How are they solved today? Who can skip the normal path?
Hiding these cases costs dearly. What isn’t said in the first meeting appears later, when changing it costs more.
What to physically bring to the meeting
Last is bringing real material.
The spreadsheet you really use, not a neat version made for the occasion. A real order example, a typical approval, an invoice with a common error.
People also matter. Whoever operates the process daily has information in no manual.
And bring business questions, not tech ones: what should be solved first? Which part should not be touched yet?
Supplier purchases: the same meeting, two versions
See everything in a common process: supplier purchases, with its need, order, approval, purchase, reception and payment circuit.
The problem is the same: nobody knows each purchase state, approvals get lost and occasionally an order duplicates or something incomplete is paid.
First version: unprepared
The general manager and someone from admin attend, but not whoever makes daily orders.
“We need a purchasing system”, they say. Each team orders their way: some by email, others by message. Sometimes one person approves, sometimes another, depending on amount.
They don’t know where each state is recorded. “I think there is a spreadsheet”, one says. Nobody brought it.
The software company has to assume too much. The quote will be broad, with assumptions and margins to cover the unknown. And another meeting will be needed just to understand basics.
Second version: with context
Whoever operates purchases attends. And tells a real case.
“The workshop warned shortages by chat. I built the order in the spreadsheet. I sent it by email to the owner. As it exceeded the usual amount, management also approved. I issued the order and sent it to the supplier. On receiving, we controlled against the remittance. If complete, we passed the invoice to admin for payment.”
They bring listed tools: spreadsheet for orders, chat for urgent, email for approvals, accounting system for payment. And they say clearly: approval isn’t in one place, and reception is controlled on paper.
They define the goal: knowing each purchase state without asking by chat, avoiding duplicates and detecting incomplete receptions before paying. And how to notice: less follow-up and fewer observed payments.
They order priorities: first, state visibility; then, clear approval by amount; later, history per supplier. And they tell edges: urgent phone purchase recorded afterwards, partial delivery, price change between order and invoice.
With that context, the company asks well from day one. Quoting stops being blind calculation.
The difference is context.
A short list to arrive prepared
On one sheet, preparation summarizes like this:
- Process told step by step, with a real case.
- Tools listed, with what lives in each.
- Goal as operations change, and how you will notice.
- Ordered priorities: what is critical and what can wait.
- Edge cases told honestly.
- Real material and the people operating the process at the table.
It is practical sense. And it doesn’t require having everything solved: it requires showing reality to think together the simplest answer working.
Three mistakes stalling any quote
First is asking for “a system” without telling the process. Without circuit, people nor rules, only a generic idea can be quoted. And the generic is paid dearly when it hits reality.
Second is hiding the real spreadsheet. That file sustaining operations shows which data matters and where control breaks. Showing it speaks of honesty, not disorder.
Third is bringing whoever doesn’t operate the process. If only deciders attend, you talk about how it should work, not how it works. And software ends designed over an ideal not matching day-to-day.
Clear context, serious quote
Asking for a quote isn’t asking price for a product. It is inviting another company to understand how you work to propose the simplest way to improve it.
Whoever tells their operation well receives better questions. Whoever defines what they want to change can decide with judgment whether to build, order, integrate or wait.
The rule is simple: clear context, serious quote.