Odoo discovery worksheet for UK implementation teams

Reviewed 5 November 2026. Use this worksheet during UK Odoo discovery. Copy the field sets into the programme's decision register and complete them with process owners, data owners and the empowered client product owner. The purpose is to produce an evidence-backed blueprint, not to turn a workshop into an unexamined feature list.

1. Establish the programme frame

Start with one controlled record for the whole discovery. Every later requirement and prototype should trace back to this frame.

• Business outcome: Describe the operational or financial change the organisation needs, including the decision or control that will be better after implementation.
• Organisations in scope: List legal entities, VAT registrations, base currencies, operating locations and any group reporting relationship.
• Processes in scope: Name the end-to-end journeys, not only application names. Include the start event, finish event and principal owner for each.
• Current estate: Record accounting, operational, integration, spreadsheet and reporting products, including versions and contractual dependencies.
• Users and controls: Identify role groups, approximate populations, approval boundaries, segregation-of-duties needs and external users.
• Constraints: Record immovable business events, close calendars, regulatory obligations, source-contract dates, infrastructure restrictions and access limitations.
• Decision authority: Name the client product owner, executive sponsor, finance owner, operational owners, data owners and technical decision-makers.
• Out-of-scope candidates: Make deliberate exclusions visible and record which future phase or existing system owns them.

A user count alone is not a scope description. Entity variation, workflow complexity, data quality, integrations and decision availability often have a greater effect on delivery effort.

2. Capture each current workflow with evidence

Run one structured record for every priority workflow. Use real documents and representative cases rather than a generic description of best practice.

• Workflow name and owner: Use language the organisation recognises and name the person accountable for the outcome.
• Trigger and preconditions: Identify what starts the work, which master data must exist and which approvals or schedules apply.
• Steps and actors: Record each hand-off, system, role and decision in the current journey, including rework and exception paths.
• Inputs and outputs: Attach representative quotes, orders, invoices, bills, receipts, pick lists, project records, reports or other evidence with sensitive values controlled appropriately.
• Volumes and peaks: Capture transaction counts, line counts, document sizes, peak periods and growth assumptions that could affect design or testing.
• Rules and variations: Record pricing, tax, approval, credit, stock, project, currency, entity and customer-specific rules, stating when each applies.
• Pain and control gaps: Distinguish duplicate entry, missing controls, poor visibility and slow hand-offs from mere preference for a different screen.
• Future outcome: Describe the intended future journey and the operational evidence that will demonstrate it works.

Include at least one normal case and the exceptions that create real work: partial delivery, credit note, backorder, returned goods, rejected approval, currency difference, failed integration or late adjustment where relevant.

3. Build the requirement register

Give every requirement a stable identifier and keep it through blueprinting, estimation, testing and change control. A requirement is not ready for estimation until its business meaning and acceptance evidence are clear.

• Requirement ID and title: Assign a durable reference and a concise outcome-led name.
• Source and owner: Link to the workflow evidence and name the process owner who can decide the requirement.
• Necessity: Explain the statutory, operational, financial, control or differentiating need. Separate essential outcomes from desirable presentation changes.
• Phase: Assign the requirement to discovery, the first operational release, a later phase or an explicit non-goal, with the dependency behind that choice.
• Standard or exception: Record whether standard Odoo behaviour satisfies the need, whether configuration or an integration is proposed, or whether a development exception must be assessed.
• Proposed solution: Describe the future behaviour, affected roles and data, not just the name of a module.
• Estimate and assumptions: Attach the effort or commercial estimate to written assumptions, including client inputs and external dependencies.
• Acceptance evidence: Define the scenario, records, expected result and approver that will close the requirement.
• Upgrade and ownership impact: For exceptions, record documentation, support and future-version considerations before approval.

If two requirements conflict, keep the conflict visible until the product owner resolves it. Do not average incompatible processes into an untestable configuration instruction.

4. Classify standard-first decisions without banning exceptions

For each material requirement, compare four routes: standard configuration, an existing supported integration, controlled development and a revised operating procedure. The cheapest initial route is not automatically the lowest-cost route to own.

Use standard capability for generic needs where the process fit is sound. Examine industry and differentiating needs deliberately. Development may be justified when the requirement is important, the standard path is demonstrably unsuitable and the organisation accepts the upgrade and support responsibility.

Record the evidence behind the classification. A statement such as “the business has always done it this way” is not sufficient proof of necessity. Equally, a development request should not be dismissed before its operational or statutory purpose is understood.

Every approved exception needs a business sponsor, proposed behaviour, acceptance scenario, estimate, documentation owner and upgrade review. Deferred exceptions retain their decision and intended phase so they do not re-enter the first release through informal requests.

5. Write the prototype script before configuring

A prototype should answer specific blueprint questions. Choose a small set of end-to-end journeys that exercise the highest-risk assumptions rather than attempting to demonstrate every screen.

• Prototype question: State the assumption being tested, such as whether a proposed approval, stock route, company boundary or VAT journey supports the real workflow.
• Data set: Identify representative companies, accounts, taxes, parties, products, projects, prices, users and opening records needed for the test.
• Actors and permissions: Name the roles that will perform and approve each step, including any cross-company restriction.
• Normal path: List the start record, principal steps, expected documents, postings, stock effects, notifications and reports.
• Exception path: Include the failure, return, cancellation, partial case or adjustment most likely to expose a wrong assumption.
• Expected evidence: Define the screenshot, report, journal, stock move, approval trail or reconciliation that the process owner will inspect.
• Decision: Record whether the workflow is accepted, requires configuration, needs an exception review or changes the proposed operating procedure.

Use Odoo 19 for current-capability validation unless the engagement explicitly names another version. Odoo 20 announcements and event demonstrations do not close an Odoo 19 prototype question.

6. Assign the five delivery workstreams

Discovery should establish ownership beyond the solution consultant. Complete a responsibility record for each of the five workstreams and name the client decision-maker who coordinates across them.

• Solution: Identify the Oakland design owner, client process owners, localisation reviewer, report owners and exception approvers.
• Migration: Name who extracts, cleanses, approves mappings, operates imports, resolves source exceptions and signs reconciliation for every data object.
• Testing: Name scenario owners, expected-result approvers, environment owners, defect triage participants and the person who accepts regression evidence.
• Training: Identify role-based learning owners, local champions, representative-data contributors and the people responsible for measuring adoption.
• Governance: Name the product owner, sponsor, scope-change authority, risk owners, release decision-makers and the keeper of the decision log.

Shared responsibility means the person with business knowledge stays accountable for meaning. Oakland can provide import structures and mechanics, but the client data owner resolves source duplicates and business codes. Oakland can facilitate testing, but process owners approve the operational outcome.

7. Define migration and integration inputs during discovery

Do not defer all data questions until after the solution phase is sold. Discovery needs enough evidence to size and sequence migration and integration work.

For each data object, record source, owner, approximate volume, quality concerns, required history, target purpose, external-ID rule, dependencies and reconciliation report. Inspect representative extracts early enough to reveal missing codes and inconsistent master data.

For each integration, record the system owner, data of record, direction, trigger, frequency, endpoint mechanism, authentication, sandbox availability, error recovery, monitoring and reconciliation. A logo on an architecture diagram is not an integration specification.

Identify bank-feed availability and history separately for each institution. Identify MTD digital records and digital links across the entire VAT journey, not only inside the accounting product. Statutory treatment and exemption questions go to the qualified accountant.

8. Convert findings into phases and commercial scope

Group requirements into releases around operational coherence and dependencies. A phase should leave users with a supportable working outcome rather than a collection of unrelated configured screens.

The discovery proposal itself has a fixed fee against agreed workshops, prototype questions and blueprint outputs. Subsequent implementation phases are priced in GBP against the approved blueprint, named work packages, acceptance evidence and assumptions. Migration and integrations remain separately visible.

List Odoo subscriptions, third-party software, bank providers, middleware, infrastructure, travel, specialist review and client internal effort outside or inside the service fee explicitly. Support, service windows and response expectations enter the proposal only when operationally approved.

Do not turn an early estimate into a promise of elapsed duration or savings. The schedule depends on client availability, source quality, external providers, decision speed and test outcomes as well as delivery effort.

9. Define acceptance and release evidence now

For every phase, define the conditions that will allow the business to accept it. Include requirement-level scenarios, migration reconciliations, integration recovery, role permissions, reports, training readiness and any accountant review.

Plan at least one mock go-live for the complete release sequence. The rehearsal should exercise final extracts, dependency-ordered imports, configuration checks, access, integrations, reconciliations and operational smoke tests. Where appropriate, use a production copy without exposing live operations to uncontrolled risk.

Record technical and functional readiness separately. Name the go or no-go authority and the evidence they will inspect. Define hypercare triage, severity, local champions, adoption reporting and exit criteria before cutover.

A blueprint is complete enough for a fixed-scope phase when material assumptions have owners, the high-risk workflows have prototype evidence, and acceptance can be judged without relying on verbal recollection.

10. Run the discovery close-out review

Before approving the blueprint, ask each workstream to confirm its inputs and unresolved decisions. The close-out is a governance gate, not a presentation of slides.

• Solution owners can explain the future workflows and every approved exception.
• Data owners have inspected representative extracts and accepted their cleansing and reconciliation duties.
• Test owners can trace priority requirements to scenarios and expected results.
• Training and operational owners have identified local champions and adoption measures.
• Governance has recorded scope, dependencies, exclusions, commercial assumptions, release gates and the change-control route.
• Finance has identified VAT, bank, opening-balance and statutory-review questions that need specialist confirmation.
• The proposal distinguishes current Odoo 19 capability from any separate Odoo 20 evaluation.

Keep the prototype evidence, requirement register, decision log, source inventory and responsibility assignments together. They form the baseline for delivery, estimation and later change control.

Educational sources and use boundary

The worksheet applies practices discussed in the public OXP2026 sessions on discovery and requirement control, implementation responsibilities, migration and import practice and testing and readiness. These sessions are educational sources only; featured organisations are not Oakland customers or references.

Use versioned product documentation and your own prototype for capability decisions. Use HMRC sources and a qualified accountant for statutory decisions. The worksheet supplies delivery structure, not a claim that one discovery format fits every organisation.