The warehouse cannot release an order until someone checks a spreadsheet. Finance is waiting for a stock adjustment. Customer service has promised an update, but nobody owns the exception.
At roughly 10-20 system users, these situations stop being occasional communication problems and become operating-model problems. The number is not a licence milestone or an automatic reason to implement ERP. It is a useful warning point: more people are creating, changing, approving and interpreting the same orders, inventory records and financial events. The ERP conversation must therefore move from features to ownership, dependencies, controls and implementation risk.
Ten to twenty users is a coordination threshold, not a headcount rule
A five-person team can have serious system problems, while a 20-person team with simple, well-separated workflows may operate reliably. What matters is how many people touch the same transaction, how often they work concurrently and whether decisions cross team boundaries.
Consider a common 15-user ecommerce operating pattern:
- Four warehouse users receive, pick, pack and transfer stock.
- Two customer service users manage order changes, returns and delivery questions.
- Two finance/admin users reconcile payments, refunds, supplier bills and reporting.
- Two purchasing or inventory users replenish stock and manage discrepancies.
- Two ecommerce users maintain products, variants and channel settings.
- An operations manager handles exceptions and priorities.
- An owner or commercial lead reviews cash, margin and service performance.
- A systems administrator monitors integrations and access.
One order may involve customer service, warehouse, finance and systems administration before it closes. One new product may pass through purchasing, catalogue management, inventory and accounting. The user count is only a proxy for the real issue: informal coordination becomes less dependable as handoffs multiply.
This is why adding licences to an existing setup does not resolve the underlying strain. Before choosing or configuring Odoo, the business needs to define how work should move and who can make each decision.
How work moves through a 15-user ecommerce operation
The operational reality is easier to see when an order or stock event is followed from start to finish. Each handoff introduces a decision, dependency or exception that needs an owner.
| Workflow | Details |
|---|---|
| Order release | People involved: Ecommerce, customer service, finance, warehouse Required handoff or control: Decide who may release a held or changed order Common failure as the team grows: Warehouse waits for approval while different teams see different instructions |
| Picking and packing | People involved: Warehouse, inventory, customer service Required handoff or control: Record short picks, substitutions and damaged stock before dispatch Common failure as the team grows: The parcel decision is made physically but not reflected consistently in records |
| Receiving and put-away | People involved: Purchasing, receiving, inventory, finance Required handoff or control: Confirm quantity, condition, cost discrepancy and inventory location Common failure as the team grows: Stock exists in the building but is not reliably available for sale or reporting |
| Stock transfer | People involved: Warehouse, inventory planning, operations Required handoff or control: Confirm source, destination, transit status and receipt Common failure as the team grows: Both locations assume the other team owns the discrepancy |
| Return and refund | People involved: Customer service, warehouse, finance Required handoff or control: Connect item condition, restocking decision and financial treatment Common failure as the team grows: A refund is processed without a clear stock disposition, or vice versa |
| Product or variant creation | People involved: Purchasing, ecommerce, warehouse, finance Required handoff or control: Approve SKU, variant, barcode, category and accounting data Common failure as the team grows: Duplicate or incomplete records create downstream picking and reporting confusion |
| Integration exception | People involved: Ecommerce administration, operations, finance Required handoff or control: Identify failed, duplicated or delayed transactions and assign repair ownership Common failure as the team grows: The problem is discovered only when a customer, warehouse user or reconciler notices |
| Reporting and close | People involved: Finance, operations, owner Required handoff or control: Agree definitions and reconcile transaction states Common failure as the team grows: Teams debate which extract is correct instead of acting on the result |
These are not merely software steps. They are operating agreements. A system can record a transfer, for example, but the business still has to decide when ownership changes, who resolves a variance and what evidence is required.
The pressure increases when there are several inventory locations, receiving zones or dispatch points. At that stage, the warehouse operating model needs to be designed around physical stock movement, timing and accountability-not just a list of locations in the system.
Scaling symptoms that show informal coordination is failing
The strongest indicators are repeated workarounds, not the user count itself. One isolated spreadsheet may be sensible. A network of spreadsheets, messages and verbal approvals sitting beside the operational system usually signals that the process boundary is unclear.
Watch for these patterns:
- Status chasing becomes routine. Staff ask whether an order is safe to release, whether stock has been received or whether a refund was completed because the agreed status is not trusted.
- Side records become operationally essential. A spreadsheet or message thread contains information needed to fulfil orders, reconcile inventory or close the month.
- Approvals depend on finding one person. Orders, stock corrections or purchase decisions stop when a particular manager is unavailable.
- Users share access or accumulate permissions. Access reflects convenience rather than responsibility, making actions and approvals harder to interpret.
- Inventory corrections fix symptoms without resolving causes. Quantities are adjusted, but nobody determines whether the variance began in receiving, transfer, picking, returns or an integration.
- Reports produce competing answers. Finance, warehouse and ecommerce teams use different definitions, cut-off times or extracts.
- Integration failures are found downstream. Missing or duplicated activity is discovered during packing, customer enquiries or reconciliation rather than through an owned exception process.
The commercial cost appears as a chain. A late receiving update affects available stock; customer service then investigates an order; the warehouse pauses dispatch; finance later reconciles the variance. No single task looks catastrophic, but the same uncertainty is being handled repeatedly by different people.
For a grounded ecommerce operator context rather than an abstract feature discussion, see the LatestBuy case study.
Ownership and approval rules must precede configuration
An ERP implementation cannot create accountability that the business has not defined. Before configuration begins, each important transaction needs an accountable owner, an execution role and an exception rule.
The accountable owner is not necessarily the person doing the work. A warehouse team member may enter a stock adjustment, while the inventory lead owns the policy and reviews adjustments above the organisation's agreed threshold. Customer service may initiate a refund, while finance owns its reconciliation and the operations lead decides unusual exceptions.
A minimum ownership map should cover:
| Decision or record | Details |
|---|---|
| Order hold, release or cancellation | Accountable role: Customer service or operations lead Control to define before implementation: Release reasons, approval conditions and audit evidence |
| Stock adjustment | Accountable role: Inventory or warehouse lead Control to define before implementation: Permitted reasons, review thresholds and root-cause follow-up |
| Purchase and receipt variance | Accountable role: Purchasing lead, with finance input Control to define before implementation: Quantity, cost and supplier discrepancy handling |
| Return, restock and refund | Accountable role: Returns owner, warehouse and finance Control to define before implementation: Item condition, stock disposition and financial completion |
| New SKU or variant | Accountable role: Product data owner Control to define before implementation: Required fields, duplicate checks and approval rights |
| Reporting close | Accountable role: Finance lead Control to define before implementation: Definitions, cut-off rules and reconciliation responsibility |
| Integration exception | Accountable role: Named systems owner Control to define before implementation: Detection, triage, repair approval and downstream validation |
Approvals should be deliberate rather than universal. Requiring a manager to approve every routine action creates another bottleneck; allowing every user to resolve every exception removes useful control. The right design separates normal work from events that need review.
Before discussing screens or modules, ask three questions: who owns the result, who may change the record and what happens when the standard path fails? If those answers are disputed, configuration is premature.
When disciplined ERP implementation becomes justified
ERP becomes a serious option when several teams depend on the same operational records, recurring exceptions cross system boundaries and the current setup cannot support agreed ownership without extensive side processes. The case is stronger when fixing one local workflow simply moves the problem to another team.
Use this decision framework before committing to implementation:
| Current condition | Sensible next step |
|---|---|
| One team has an inefficient but contained process | Standardise the workflow and remove unnecessary steps before changing systems |
| Multiple teams maintain conflicting order or stock records | Map the end-to-end transaction and assess whether system boundaries are causing divergence |
| Product, customer or inventory data is unreliable | Assign data ownership and complete enough cleanup to estimate migration risk |
| Integrations fail but nobody owns detection or reconciliation | Create a dependency register and exception process before redesigning interfaces |
| Reporting is disputed because definitions differ | Agree reporting definitions, cut-offs and reconciliation rules first |
| Workflows are understood, owners are named and dependencies are documented | A scoped Odoo implementation review can test business fit and implementation risk |
The business case should name specific operating costs: repeated data entry, delayed order release, inventory corrections, reconciliation effort, dependency failures and duplicate systems. It should also recognise the cost and risk introduced by implementation itself, including internal owner time, product data cleanup, integration validation, testing, training, cutover preparation and post-launch governance.
The right comparison is therefore not "old software versus new software". It is the cost and risk of maintaining the present operating model versus the cost and risk of changing it with discipline.
Sequence the work around dependencies and cutover risk
A safer implementation sequence follows end-to-end workflows rather than configuring one department at a time. Orders, inventory, purchasing, returns and finance are connected; designing them in isolation can leave gaps exactly where responsibility changes hands.
| Sequence | Details |
|---|---|
| 1. Define scope and operating model | Accountable lead: Executive sponsor and operations lead Dependency or exit check: In-scope workflows, locations, entities, channels and exclusions are explicit |
| 2. Map standard and exception paths | Accountable lead: Process owners Dependency or exit check: Order, receiving, transfer, return, refund and reporting exceptions have named owners |
| 3. Prepare master data | Accountable lead: Product data, inventory and finance owners Dependency or exit check: SKU/variant complexity, product data cleanup and inventory locations are understood |
| 4. Map integrations and reporting | Accountable lead: Systems owner and finance lead Dependency or exit check: Order/integration dependencies, data direction, failure handling and reconciliation are documented |
| 5. Design roles and approvals | Accountable lead: Process owners with implementation lead Dependency or exit check: Permissions support responsibilities; exception approvals do not block routine work |
| 6. Test complete scenarios | Accountable lead: Named test lead and operational users Dependency or exit check: Realistic orders, short picks, transfers, returns, refunds and reporting outcomes are validated |
| 7. Rehearse cutover and support | Accountable lead: Sponsor, operations and systems owners Dependency or exit check: Open transactions, stock baseline, issue triage and decision rights are ready |
Data work should begin before migration becomes urgent. SKU/variant complexity needs to be quantified, duplicate and incomplete product records need owners, and physical inventory locations must align with the proposed operating model. Moving poor data unchanged only makes later testing harder to interpret.
The same discipline applies to integrations. For a Shopify operation considering a broader Odoo environment, the Shopify-to-Odoo migration context is useful only after the business has mapped which system creates each order, product, stock and financial event. Interface design cannot compensate for unclear source ownership.
Testing before switching must cover complete business outcomes, not only whether a record can be entered. A test order should move through release, allocation, picking, dispatch and financial treatment. Exceptions such as short picks, cancellations, returns and failed dependencies need equal attention.
Detailed migration and cutover planning should then address open orders, inventory baselines, pending receipts, returns in progress and reconciliation checkpoints. After launch, named governance and post-go-live support remain necessary so issues are triaged, decisions are recorded and temporary workarounds do not quietly become permanent.
Run this readiness check before committing scope
A readiness check should expose unresolved decisions before they become change requests, test failures or cutover delays. Review the following with operations, warehouse, ecommerce, finance/admin and the internal project sponsor:
- [ ] Every core workflow has one accountable owner and a capable backup.
- [ ] Standard paths and common exceptions are documented in operational language.
- [ ] Order, stock, purchasing, return and reporting states have agreed meanings.
- [ ] Approval rules distinguish routine work from material exceptions.
- [ ] A product data owner can explain SKU/variant complexity and cleanup priorities.
- [ ] Inventory locations match physical receiving, storage, transfer and dispatch activity.
- [ ] An inventory baseline can be established and reconciled for cutover.
- [ ] Every integration has an owner, direction, dependency and failure-response process.
- [ ] Finance has defined reporting cut-offs and reconciliation requirements.
- [ ] Operational users are allocated to scenario design, testing and training.
- [ ] Cutover planning includes open transactions rather than only static data.
- [ ] The budget recognises internal time, data work, testing, integration validation and support.
- [ ] Scope changes have an approval process and a clear impact assessment.
Do not reduce the result to a false-precision score. A "yes" supported by a named owner and evidence is more useful than several optimistic answers. Treat unresolved source-of-truth questions, disputed stock ownership and unknown integration dependencies as high-risk items. These are reasonable grounds for a specialist scope and risk review before implementation commitments are made.
Frequently asked questions about ERP at 10-20 users
Does reaching 10-20 users mean an ecommerce business needs ERP?
No. The number is a diagnostic prompt, not a rule. ERP consideration becomes more relevant when those users share orders, inventory, approvals, integrations and reports, and when recurring workarounds create operational risk across teams.
Which users matter when assessing complexity?
Focus on users who create, change, approve or rely on operational transactions. A warehouse picker, inventory planner, customer service agent and finance reconciler may create more interdependence than several occasional reporting users. Roles and handoffs matter more than the raw account total.
What should be costed before an implementation decision?
Cost the known work around data cleanup, integration validation, testing, training, cutover, internal project ownership and support. Also identify recurring operational costs in the current model, such as reconciliation, corrections and duplicate entry. User count alone is not enough to estimate implementation cost.
How long should implementation take for 10-20 users?
There is no reliable duration based on user count. Timing depends on scope, data condition, integration dependencies, number of inventory locations, exception complexity, tester availability and cutover constraints. Ask for a milestone-based plan with dependencies and decision owners rather than a date based only on licences.
Who should own the project internally?
One sponsor should hold decision authority, but ownership must be distributed across process specialists. Operations, warehouse, ecommerce, finance/admin, product data and systems each need named responsibilities. The implementation partner should not be expected to make internal policy decisions on the business's behalf.
What is the largest avoidable implementation risk?
A major avoidable risk is configuring unresolved processes and migrating unreliable data before ownership is clear. Inadequate end-to-end testing compounds that risk because problems appear only when orders, stock, integrations and finance meet during live operation.
If several of these signals are familiar, the next step is not another generic software demonstration. Bring a user-and-role list, three recurring exception examples, your inventory location model, key integration dependencies and the report that creates the most disagreement. Syceed can use that evidence in a practical implementation readiness and scope conversation focused on sequencing, ownership and avoidable risk.
For the next step, compare the decision against LatestBuy case study.
About the author
Shaun Campbell - Project Director, Syceed
Shaun Campbell is Project Director at Syceed and an Australian ecommerce operator with practical experience across online retail, Odoo implementation, migration planning, inventory workflows and operational systems cleanup.