QUICK OVERVIEW
What to take away from the article
- First, design the order path and data responsibility.
- Expect changes, cancellations, split shipments and complaints.
- Custom development is meant to address a specific need; the current agenda can be provided by the existing system.
Map the order beyond the basket
Write down what should happen from product selection to order fulfillment. When is the availability checked, when are the goods reserved and who deals with the missing item? Which status can trigger a message to the customer and which creation of the document?
Before the technical proposal, review both the regular order and the problem case. For example, a customer pays, but part of the order is out of stock. If the procedure is agreed upon after launch, workers will get used to manual workarounds. They are then more difficult to replace with a reliable connection.
Products, prices and inventory need order
One product must have an understandable identifier across the e-shop, warehouse and documents. Differentiate between variants, packages and sales units. Otherwise, one click can mean a piece in one system and the whole package in another.
For the price, determine the main source, the validity of the price list and the discount rules. For B2B customers, separate the approved terms from the general public offer. Availability and deadline should be based on data that the system understands, not on a manually maintained note for each order.
Documents trigger agreed rules
Ordering, paying, sending and receiving are different events. The technical proposal should clearly state which event creates the relevant document or document in the economic system. The accounting and tax setup of a specific company must be agreed with its accountant; the article does not determine the moment of tax liability.
An example of a different process setup is Odoo: its documentation differentiates the invoicing of ordered and delivered quantities. Therefore, when integrating, it is not enough to send the information "the order exists". It is also necessary to transfer the correct status and quantities according to the chosen procedure.
Exceptions are part of the proposal
The customer can change the address, the payment can be delayed and the order can be split into two shipments. When making a return or complaint, you must be able to follow up on the original purchase and record the next procedure. All these situations should have a place on the agenda.
Automatic retransmission may not create a second order. The failure should be displayed to the human with information about what has already been done and what remains. The team also needs an alternative procedure in the event of a connection failure, so that it can track the orders in progress.
- Order change after payment.
- Partial shipment and subsequent reshipment.
- Cancellation, return and complaint.
- Repeat transmission of the same event.
Select the first functional path and only then expand
For the first version, choose a clear assortment and a limited number of process variants. Verify one complete journey: purchase, payment, warehouse, shipping, communication and documents. Only then add more complicated discounts, additional markets or individual configurations.
The same applies to the sale of packaging, advertising items or corporate textiles. Each assortment may need different documents and approval. A custom app makes sense where it facilitates these idiosyncrasies; it is advisable to base the repeatable agenda on existing and verified parts of the system.
