A business systems project should not begin with a software demonstration. By that point, the conversation is already being shaped around what a product can show rather than what the business needs to improve.
A proper Discovery Session creates a view of the whole operating model before anyone recommends ERP, CRM, integration, automation or custom development.
Start with the commercial reason for change
The first question is not which features are required. It is what the current setup is costing or preventing.
Is revenue being lost because follow-up is inconsistent? Are margins unclear? Is stock tying up cash? Are orders delayed by manual checks? Does reporting take days? Are employees repeating work because systems do not share information? Is the founder unable to step away because too much control sits in their head?
These outcomes create the basis for prioritisation. Without them, a project can become a long list of requests with no clear definition of value.
Follow real work from beginning to end
Discovery should follow representative transactions across departments. A sales enquiry may touch CRM, pricing, stock, production, purchasing, delivery, finance and customer service. Looking at one department alone misses the handoffs where delay and error usually appear.
The session should examine:
- How customers, products, suppliers and prices are created and maintained.
- How quotations become orders and how availability is confirmed.
- How work is planned, delivered, checked and invoiced.
- How exceptions such as changes, returns, shortages and credit issues are handled.
- How management information is produced and which figures are difficult to trust.
- Which steps exist only because the systems do not work together.
Separate the requirement from the current workaround
People naturally describe what they do today. That does not always describe what the new system should do.
If a team exports data to Excel, edits it and uploads it somewhere else, the requirement is not necessarily a better export. The real requirement may be accurate information flowing automatically between purchasing, stock and finance.
An experienced consultant should challenge the workaround and explain the best-practice process that a modern platform can support. The customer supplies the business knowledge. The consultant is responsible for turning that knowledge into a coherent operating design.
Define the phases and the risk
Discovery should produce a practical route, not an attempt to change everything at once. The strongest first phase is usually the smallest scope that creates useful control and provides a foundation for later improvements.
That route should identify data migration, integrations, reporting, testing, training, ownership and the periods when disruption would be most damaging. It should also be honest about which current systems should remain.
What should you receive after Discovery?
You should understand the problems worth solving, the proposed operating model, the platform options, the recommended phases, the major risks and the next decision. You should not need a technical requirements document before the first conversation.
Cloudsaber provides this initial consulting without charge because a sensible recommendation depends on understanding the business first. Learn more about our Discovery process or review how we move from understanding to implementation and adoption.