Select an ERP through 3 demonstrations: a connected business workflow, a coherent data import and the intended staff permissions. A long module list is not enough. Ask each shortlisted system to demonstrate the same representative transaction and its exceptions, using a written expected result that your team can understand.
For a Zambian organisation, keep local requirements as a separate evidence track. The product examples here come from Odoo’s official documentation. They show how that platform describes imports and access control; they do not establish support for your statutory reporting, bank formats, industry obligations or existing integrations. Those requirements need their own applicable evidence before selection.
Which modules and controls should the demonstration prove?
Map the business process before naming the modules. Follow a customer request through quotation, fulfilment, invoicing and the record used to understand the result. Follow a purchase through authorisation, receipt and the resulting obligation. Identify where a staff member currently copies information, resolves an exception or decides which record is authoritative.
Turn that map into scenarios rather than a shopping list. “Inventory module” is vague. “Receive an item against an agreed order and explain how a partial receipt changes what remains outstanding” is a demonstrable requirement. Keep the scenario specific to your work without putting real personal or commercially sensitive records into a sales demonstration.
Decide the owner of each shared record. Customers, products, units and account references often appear in several workflows. If separate modules can each create conflicting versions, a connected-looking demonstration may conceal a reconciliation problem. Ask how the proposed setup identifies the same customer or item across the process and what happens when the record changes.
Permission tests deserve equal attention. Odoo’s access-rights documentation describes permissions for individual users and groups, with separate read, write, create and delete actions. Translate those distinctions into business responsibilities. Someone who needs to view stock does not automatically need to delete products, and someone entering transactions does not automatically need to administer other users.
Include a negative test: have the demonstrator sign in with the proposed operational role and attempt an action that should be refused. Record the result without granting extra access simply to complete the demonstration. Testing only an administrator account cannot establish that ordinary staff receive the intended restrictions.
The documentation also warns that access-right changes can have detrimental effects, including leaving no user able to change them. Keep administration recovery in the requirements. A narrowly restricted operating role and a recoverable administration arrangement are complementary controls; one should not accidentally destroy the other.
Use the following original demonstration script to make competing proposals easier to compare. It is a requirements tool, not an endorsement or an implementation report.
| Scenario | Demonstration evidence | Question that a module list cannot answer |
|---|---|---|
| Customer request to obligation | Linked records and unchanged customer identity | Where does re-entry occur? |
| Partial fulfilment | Outstanding quantity and related follow-up | Can staff explain what remains to be done? |
| Master-data correction | Change effect across connected records | Does the correction alter historical meaning? |
| Staff access | Allowed task and deliberately refused task | Does the ordinary role match its responsibility? |
| Data import | Mapping, validation result and imported relationships | Is the source meaning preserved? |
| Recovery rehearsal | Restored test environment and recorded limitations | What would happen if migration had to be abandoned? |
How do you assess migration before committing to the system?
Inventory the source records and their relationships. Identify current masters, open transactions, historical records and attachments separately. Agree which are required in the replacement and which can remain in a searchable archive. Importing everything without understanding its purpose can make the new system harder to trust, while importing too little can leave staff unable to explain open obligations.
Odoo’s export-and-import guide documents Excel and CSV imports, column mapping and a test step before import. Use those capabilities to ask for evidence from your proposed migration, not merely a screenshot of an import button. A successful file upload does not prove that the correct source column became the correct destination field.
Retain stable identifiers where appropriate. The guide explains that external IDs can help update imports without creating duplicates and recreate relationships between records. It also states that related objects should be imported before records that depend on them. Your dependency map should therefore show which customers, categories or other reference records must exist before transactions can link to them.
Inspect ambiguous values before the rehearsal. The same documentation highlights date-format confusion, including day-month inversion. Include representative dates, blank values and identifiers with meaningful formatting in the test set. Compare the meaning after import, rather than accepting that the destination cell looks tidy. A readable record can still contain a misinterpreted date or a broken relationship.
Treat a repeated import as a separate scenario. Ask what happens if the operator reruns an amended source file. Where stable IDs are part of the design, demonstrate that intended records update rather than multiplying. Keep rejected rows and the reason for rejection available so unresolved data does not disappear from the migration report.
Prepare a rollback route before the first live import. Odoo explicitly warns that imports are permanent and cannot be undone through a simple reversal. Testing and backups therefore belong before the irreversible operation. A migration plan should identify the recovery set, who can restore it and which records created afterwards would need reconciliation.
Reconcile by business meaning as well as record presence. Check open orders against the obligations people still recognise, inspect representative linked records and explain excluded data. Do not invent a universal discrepancy allowance. Any tolerance should come from a documented business decision; an unexplained difference remains an unresolved migration issue.
Finish selection with an evidence register: demonstrated, configuration required, external dependency or unverified. Keep local compliance and integration questions in that last category until applicable evidence resolves them. A vendor statement about broad international support should not silently become a claim about your particular Zambian workflow.
Spout’s web development page offers context for related application requirements. To explain the digital work you are considering, get started with your process map and redacted demonstration script. The next discussion can establish scope without presuming that an ERP implementation, payroll localisation or specialist assurance service has already been agreed.
By Spout Team. AI-assisted drafting by Codex, grounded in the linked primary documentation.