A new ERP implementation usually begins with enthusiasm: better visibility, fewer spreadsheets, faster reporting, and more connected operations. Interest in Odoo 20 gives businesses another reason to review how they work.
But selecting a software version is only one part of the decision. Before discussing applications, customization, or deployment, a business needs to define what it wants to improve—and how it will recognize success.
Whether you are bringing several disconnected systems together or adopting ERP for the first time, these questions will help you prepare a practical implementation brief.
1. Which business problems should the implementation solve?
Start with the difficulties your team encounters during an ordinary working week.
Does preparing a quotation require checking several spreadsheets? Do salespeople promise delivery dates without reliable stock information? Does management wait until month-end to understand outstanding payments?
Write down the problem, who it affects, and its business consequence.
For example:
- Problem: Sales and warehouse teams maintain separate stock records.
- Consequence: Availability must be confirmed manually, delaying quotations.
- Desired outcome: Both teams work from an agreed, current stock position.
This gives your implementation team something concrete to investigate. “We need better efficiency” expresses an ambition; a specific operational problem provides a starting point.
2. What must be included in the first phase?
It is tempting to introduce sales, purchasing, inventory, accounting, manufacturing, HR, and every other function together. Each additional process, however, adds decisions, data preparation, training, and testing.
Define the smallest connected scope that delivers a useful business result.
For a trading business, that might mean following an order from quotation through delivery and invoicing. For a manufacturer, product structures and production requirements may change the starting point.
The first phase should be manageable, but it must still account for dependencies. Introducing sales without considering how stock availability and delivery will be handled can leave important gaps.
Record what belongs in the first phase, what comes later, and what will continue temporarily in another system.
3. How do your processes actually work?
Ask the people who perform the work to describe it using recent examples.
A process document may say that every purchase follows an approval procedure. In practice, urgent purchases may happen by phone and be documented afterwards. Both situations matter.
Include normal transactions and exceptions:
- Partial deliveries and backorders.
- Customer returns and exchanges.
- Changes to confirmed orders.
- Credit sales and overdue payments.
- Damaged stock and inventory adjustments.
These examples become useful demonstration and testing scenarios. They also reveal where the business needs to clarify its own procedures before configuring software.
4. Is your data ready to move?
Data preparation often requires more attention than expected.
Customer records may be duplicated. Product names may be inconsistent. Units of measure may differ between purchasing and sales. Opening stock quantities may not match physical stock.
Identify the information needed for the first phase and assign someone to prepare it. This may include products, variants, customers, suppliers, price lists, opening balances, and stock quantities.
For each dataset, decide:
- Who owns its accuracy?
- Which fields are required?
- How will duplicates and obsolete records be handled?
- Who will approve the imported results?
A trial import should happen early enough to expose problems before launch.
5. Where is customization genuinely necessary?
For every requested customization, ask what business requirement it supports.
Some requirements can be addressed through configuration. Others may need a change in working practices, an integration, or custom development.
A useful discussion starts with the outcome: “We need approval before granting a discount above an agreed limit.” It should not start and end with reproducing the exact screen used in an old system.
Custom development can be valuable. It also needs documentation, testing, maintenance, and consideration during future upgrades. Include those responsibilities when assessing its value.
6. Which edition, hosting arrangement, and integrations fit your needs?
An Odoo 20 proposal should identify the intended edition and hosting arrangement clearly. Ask your implementation provider to verify the availability of each required capability in that specific setup.
Discuss integrations individually: email, payment gateways, delivery services, existing websites, reporting tools, and other business systems.
For each integration, establish what information moves, in which direction, how frequently, and what happens when the connection fails.
An email connection, for example, involves more than sending a test message. Recruitment applications, sales enquiries, and replies to existing conversations need appropriate routing and ownership.
7. Who will make decisions and support users?
Assign an internal project owner who can coordinate departments and resolve outstanding decisions.
Also identify a knowledgeable person for each process in scope. These people should review requirements, participate in testing, and help colleagues adopt the agreed workflows.
The implementation provider brings technical and application knowledge. Your team brings knowledge of customers, products, responsibilities, and everyday exceptions. Progress depends on both contributions.
Reserve time for this work in the project schedule. Training and testing are difficult to complete well when everyone is expected to fit them around an unchanged workload.
8. What must be proven before going live?
Define acceptance criteria before the final demonstration.
Can the team complete a representative order? Are opening balances approved? Do permissions match responsibilities? Can users handle a return without assistance? Do notifications reach the correct people?
Test with realistic examples and named users. Record unresolved issues, their business impact, and who is responsible for resolving them.
Then agree on the cutover plan: final data preparation, responsibilities during launch, support arrangements, and the action to take if a critical process cannot operate.
Turn the answers into an implementation brief
You do not need a lengthy specification to begin. A concise brief covering business problems, first-phase scope, process examples, data ownership, integrations, and acceptance criteria will make early discussions more productive.
It also helps you compare proposals on the work involved, rather than on price alone.
At Axon Communications, we help businesses plan Odoo implementations around their operational requirements. If you are considering Odoo 20, bring your current challenges and a few real transaction examples to a discovery discussion.
Book a Discovery Meeting to discuss your requirements and practical next steps.