Order Management System: A Complete Requirements Guide for a Business

What is an order management system — and what it must do in an Israeli business

An order management system is the place where an order comes in, receives a status, is checked against the customer and inventory, moves to fulfillment, is issued in the appropriate document, and ends in delivery, cancellation, or return. It is not just a form and not just online order management software. It connects sales, the warehouse, finance, shipping, and service.

In an Israeli business, the system must handle an order that arrived from WhatsApp, a phone call, a field sales rep, a website, a store, or a combination of them. It needs to keep the order source, the price list, the discount, the address, the payment method, the inventory allocation, and the documents. If one detail stays in Excel or in a private mailbox, the next employee may see a partial picture.

Before choosing an order management system for a business, define what counts as a valid order: a request that was received, a quote that was approved, a payment that was received, or a document that was opened. Also define who is allowed to change it, when inventory is reserved, and what happens when not all items are available.

The right system is not the one that shows the longest list of features. It is the system in which a new employee knows what to do when an order comes in, a manager sees what is stuck, and accounting receives data it can trust.

If the order is part of a broader relationship with the customer, it is worth completing the picture with a CRM system requirements document: the full guide and a work template to copy and understanding what is CRM? and why it is not just sales software.

The lifecycle of an order in Israel: WhatsApp, phone, field sales rep, website, and store

The lifecycle begins with receiving the request and ends when the order has been supplied, returned, or closed for a documented reason. At every stage there must be a role owner, a status, a next action, and a rule that prevents an incorrect transition.

1. Order intake

• WhatsApp: identify the customer by phone number, open an order, save the conversation or a link to it, and complete missing details.
• Phone: select an existing customer or create a new customer, record products, price, address, and payment method.
• Field sales rep: assign to a rep, region, customer, price list, and credit terms. Define whether the rep may approve a discount or only send a request.
• Website: receive items, quantities, coupon, shipping, payment, and invoice details without re-typing.
• Store: connect a sale at the register with the customer balance, inventory, and returns from other channels.

2. Review and approval

After intake, the system must check customer details, address, availability, price, discount, tax, payment terms, and whether manager approval is required. An incomplete order should not disappear; it should receive a status such as "awaiting completion" and state exactly what is missing.

3. Allocation and picking

After approval, the system allocates inventory by warehouse, location, batch, or expiration date if these are relevant. The warehouse should see a clear picking list, including approved substitutions, missing items, and the actual quantity.

4. Document and payment

The system issues the required document according to the type of business and the transaction, transfers data to the invoicing provider, and records success or failure. A failed payment should not automatically become a dispatched order.

5. Shipping and delivery

Address, contact person, delivery window, shipping company, tracking number, shipping cost, and proof of delivery if available should be saved. When there are several shipments for the same order, each shipment needs its own status.

6. Closing, service, and return

An order is closed only after it has been defined what happened to every item and every amount. A return, credit, or exchange must remain linked to the original order, to the financial document, and to the inventory that came back.

Order management system requirements document template — section by section for copying

Copy the following sections into your working document. In every line, fill in the business answer, not the name of the feature you hope to get.

1. System purpose

• What is the main problem: duplicate orders, price errors, lack of inventory, delayed documents, or lack of tracking?
• Which ordering channels are active today?
• What needs to improve in the first stage?
• Who uses the system every day?
• Which actions will remain outside the system?

2. Order details

• Which mandatory fields are required to open an order?
• Is it possible to save a draft?
• Which statuses exist: new, under review, approved, in picking, sent, delivered, cancelled, returned?
• Who is allowed to change a status?
• Is every change documented with user, date, and time?
• Is it possible to duplicate an order without accidentally copying old prices or addresses?

3. Business rules

• Under which conditions is a discount approved?
• When is inventory reserved?
• What do you do when an item is missing?
• Is it permitted to split a shipment?
• Which orders require manager approval?
• What happens to an order that was not paid?

4. Receipt and approval

• How is a returning customer identified?
• Which details are sent to them for approval?
• Is the approval received on WhatsApp, via a link, by phone, or by email?
• What counts as proof of approval?
• What happens if the customer changes a quantity after approval?

5. Warehouse and shipping

• How many warehouses exist?
• Are there locations, batches, expiration dates, or serial numbers?
• Who issues a picking task?
• Is it possible to substitute an item only after approval?
• Which shipping details must be saved?
• How do you update the customer about a change?

6. Documents and finances

• Which documents are produced and at which stage?
• Which document is sent to the customer?
• How is a failed charge documented?
• How are partial payment or open credit handled?
• How is a credit linked to the original order?
• Who approves a change in amount after a document has been produced?

7. Reports and acceptance by the business

• Which reports must be available on launch day?
• How are open orders measured by age, channel and owner?
• How do you find an order stuck between approval and picking?
• Which report checks the gap between system inventory and actual inventory?
• Which test scenarios must pass before going live?

Acceptance questions for a supplier

• Show us an order that arrived from WhatsApp, was changed, split and sent in two shipments.
• Show what a manager sees when the invoice was not produced.
• Show how a single line is cancelled without cancelling the entire order.
• Show how customer, order, payment and document data are exported.
• Show the activity history of a user who changed a price.

Entities and base data: customers, inventory, price lists, promotions, taxes and documents

A good order management system starts with clean base data. If the same customer appears in three forms, or if every channel has a different price without explanation, automation will only create mistakes faster.

Customers

Keep a customer ID, business or person name, company number or relevant details, phone numbers, addresses, contacts, preferred channel, payment terms, credit limit, assigned price list and communication consents. Separate the billing address from the shipping address, and allow several contacts for the same account.

Items and inventory

Every item needs a SKU, name, unit of measure, barcode if there is one, base price, supplier, weight or volume if the shipment depends on them, and active or inactive item status. Define available, reserved, damaged and pending receipt inventory. Do not settle for a single "quantity in stock" field.

Price lists and promotions

Document a price list by customer, channel, region, quantity or period. Define whether promotions accumulate, what prevails in the case of two discounts, and who is allowed to deviate from the price. Every price in an order must be kept as approved, even if the price list changes later.

Taxes and documents

Define the tax types relevant to the business and the way the system passes them to documents. A distinction must be made between order, approval, invoice, receipt, delivery note and credit. A document that is created must be linked to the order and allow the source to be traced.

Israeli integrations that must work: invoices, charging, deliveries, ERP and WhatsApp

An integration is not a logo connection. It is a data flow with failure rules: what is sent, when, who receives the response and what happens if the external service is unavailable.

Invoicing integration

Check which data is passed: customer details, lines, quantities, discounts, tax, payment method, and address. Make sure the system receives a document number, stores a link, and displays an error that can be handled. Ask whether correcting an order creates a corrective document or modifies an existing document.

Clearing

The system must distinguish between a payment attempt, authorization, charge, cancellation, and refund. A transaction approved by the clearing provider but not recorded on your side must appear for handling, and must not be reopened without review.

Shipments

Check shipment creation, label printing, receiving a tracking number, status updates, and handling delivery failure. If several items leave from different warehouses, make sure the integration does not present them as one shipment.

ERP and financial system

Define which system is the source of truth for each data item: customer, item, inventory, price, order, and document. Two-way synchronization without clear field ownership creates overwrites. If you are comparing off-the-shelf software with custom development, accounting software: beyond the books and reports explains when a system should adapt to the process and not the other way around.

WhatsApp ordering system

Define how the customer is identified, which questions the automated response is allowed to ask, when the conversation moves to a representative, and how final consent is recorded. Do not let the system guess an address, product, or quantity when there are several options. Business automation: when connecting tools stops being enough helps decide when a central process is needed and not just another connection.

Edge cases and exceptions: cancellations, returns, refunds, partial orders, and procurement

The real test of an order management system is not the regular order. It begins when a customer cancels an item that has already been picked, when part of the quantity is missing, or when the amount paid does not match the document.

Cancellation

Define up to which stage cancellation is allowed, who approves it, whether the inventory returns to available, and what happens to the payment. A full cancellation is not the same as cancelling a single line. Keep a cancellation reason that can be reported on.

Return and exchange

Open a return request with a reason, item condition, photos or documents if required, and the person responsible for inspection. After the item is received, the system must decide whether it returns to available inventory, is set aside, or is rejected. An exchange requires a link between the returned item and the item that was sent.

Refund

The refund must refer to the original lines and amounts. Define handling of shipping, discount, tax, and partial refund. Make sure the system prevents a double refund on the same line.

Partial order

When only some of the items are available, present the customer with the options: wait, partial shipment, exchange, or cancellation. Keep an open balance with a due date and an owner. Do not close an order just because part of it went out.

Procurement and stock shortages

If an order creates a need for procurement, document the link between the order and the procurement and receipt requirement. Define whether future stock may be sold, who approves it, and what the customer is told. A forecast that is not connected to open orders can mislead procurement.

Permissions, security, and control: who sees what, which alerts, and which reports

Permissions should reflect a role, not just a department. A sales rep needs to see their own customers and open an order; a warehouse worker needs to see picking and stock; a manager needs to approve exceptions; accounting needs to see documents and payments.

Define view, create, edit, cancel, export, and approval permissions for each role. Check in particular price changes, address changes after approval, customer creation, draft deletion, and refunds. Secure login with a one-time code by email is required, as well as a full activity log: who did what, when, and from which address.

Alerts should arrive only when there is a required action: a failed payment, stock below threshold, an order with no activity, a discount beyond the limit, a document that was not issued, or a shipment that was not delivered. A flood of alerts with no owner creates noise.

Basic reports should include orders by status, channel, employee, and customer; time between stages; cancellations and returns by reason; sales by item; stock gaps; payments that were not completed; and orders that were received but not closed. Check that the report explains the source of the data and not only shows a number.

How to choose a vendor: comparison questions, total cost of ownership, and contract traps

Compare vendors using identical scenarios, not a list of features. Give each vendor a complex order and ask to see the full path, including an integration failure and recovery.

Ask:

• Which fields and processes can be configured without development?
• Who is responsible for the connection to invoicing, payments, shipping, and WhatsApp?
• What happens to the data if the engagement is terminated?
• In what format can customers, orders, documents, and the activity log be exported, and for how long is the data available for export?
• Who approves process changes after go-live?
• How are incidents documented, and what is visible in the operations panel?
• What is included in implementation, training, and testing?

Total cost of ownership includes the service, setup, data cleanup, connections, documents, users, maintenance, training, future development, and the cost of internal work. A low quote can become more expensive if every small change is billed separately.

Read the exit clauses, data ownership, export, data retention, price changes, renewal, notice period, user limits, and liability for external services carefully. Your data can be exported for 30 days after the engagement ends; the software itself belongs to the vendor. Ask to see the export process before signing.

30/60/90-day implementation plan — including data, training, and success metrics

Days 1–30: Decisions and infrastructure

• Mapping the ordering channels and existing statuses.
• Choosing a business owner and an operational owner for the system.
• Cleaning the customer list, items, price lists, and addresses.
• Defining required fields, permissions, and approval rules.
• Deciding which system is the source of truth for each data point.
• Writing acceptance scenarios: a regular order, cancellation, out of stock, and a return.

The success metric at this stage is an approved decisions document, not a pretty screen. Every field needs an owner, and every exception needs a way to be handled.

Days 31–60: Build, connections, and testing

• Setting up screens, statuses, and document templates.
• Connecting invoicing, payments, deliveries, and the chosen ordering channel.
• Loading test data and checking for duplicates.
• Running orders end to end in a controlled environment.
• Training reps, warehouse, accounting, and managers according to scenarios.
• Documenting actions that must not be performed manually.

Success metrics can include the rate of orders that go through without re-typing, the number of orders without an owner, the gap between system inventory and actual inventory, and the handling time for an irregular order.

Days 61–90: Gradual rollout and improvement

• Starting with one defined channel or user group.
• Daily checking of stuck orders, documents, and connection errors.
• Collecting questions from the field and separating a bug, a lack of training, and a change request.
• Expanding to additional channels only after the first stage is stable.
• Comparing the metrics to the starting point defined before implementation.
• Approving the list of improvements for the future by impact, not by who asked first.

Do not move all the history before the new structure has been tested. Start with clean and required data, define a way to access history, and check sample records before a full load.

Summary: how to start the requirements document today, and what to ask of every vendor

Start with one real order: a WhatsApp message, customer details, price list, items, payment, picking, invoice, delivery, and return. Write down who touches it at each stage, what data passes through, and what happens when something goes wrong. This is a better starting point than a general feature list.

Then copy the requirements document template from the article, fill in the missing fields, and invite vendors to demonstrate those same scenarios. Ask for answers about data, permissions, documents, integrations, export, and total cost of ownership — not just about the order screen.

If your process requires a CRM, automations, a dashboard, documents, and operations in one place, the alcyone14 team builds and operates a system tailored to the business; you can read about automation and AI inside one system and come to a conversation with the requirements document you filled in.

Frequently asked questions

Is an order management system also suitable for a business that receives orders only on WhatsApp and by phone?

Yes, provided it centralizes the orders that come in from those channels and prevents double typing. Check customer identification, saving the conversation or a link to it, order confirmation, price list, inventory, and document production.

Must an order management system also include inventory management?

Not always, but it must receive reliable information about availability, reserved inventory, and shipped inventory. If inventory is managed in another system, define in advance which system is the source of truth and what happens when the connection fails.

How do you connect an order system to invoices and clearing?

Define which data passes at each stage and what comes back to the system: document number, payment confirmation, failure, or refund. Ask the supplier to demonstrate both a failed transaction and a change or cancellation after a document has been produced.

How long does implementing an order management system take?

The time depends on the number of channels, the quality of the data, the number of integrations, and the complexity of the processes. Instead of relying on a general estimate, divide the work into mapping, building, testing, training, and a gradual rollout, and define acceptance criteria for each stage.

What should appear in a contract with an order management system supplier?

The contract should clarify the scope of the setup, the connections, the training, the responsibilities of the parties, process changes, permissions, data export, and termination terms. Make sure the data can be exported for 30 days after the engagement ends, and that you know in which format and by which process.