Classify an online store order as parcel delivery, own delivery or collection using a fixed source hierarchy: use stable method IDs where their meaning is unambiguous, then apply a managed title mapping, and block unknown values. Words such as ‘free’ or ‘standard’ say nothing reliable about the operational process that needs to follow.
Classification directs the entire order flow
A wrong choice affects more than a shipping label. Parcel delivery may go to Sendcloud, own delivery requires a zone, date and route planning, and collection needs a location or time slot. The point at which an order counts as complete differs too. Fulfilment classification therefore belongs early in the workflow and needs to be stored against the order as an explicit, explainable outcome.
Start with technical identifiers that a plugin consistently supplies. Known semantic methods such as local pickup can be recognised by ID. Commercial or custom methods require a configuration table linking the source shop, method ID or exactly normalised title to one fulfilment type. Avoid free substring rules: ‘collect or have delivered’ contains both words and is therefore not a safe basis.
Source hierarchy for the decision
| Priority | Source | Use |
|---|---|---|
| 1 | Stable WooCommerce method ID | Directly, when the meaning is technically established |
| 2 | Shop-specific configuration mapping | For custom methods and plugins |
| 3 | Exactly normalised title | Only as a managed and tested fallback |
| No match | Unknown | Stop before subsequent logistics actions |
Also record which source determined the outcome. Operations can then see that ‘Avondroute Noord’ was treated as own delivery through the shop configuration. In Connect this classification can select the appropriate configurable workflow.
Fictional example: free is not a fulfilment type
Fictional example: delicatessen Smaakloods displays ‘Free shipping from €75’. For light parcels, this still means parcel delivery; for chilled products, the same marketing wording activates an own-delivery route. Classifying by the word free would treat both orders identically.
The team therefore uses the underlying method ID and a shop-specific mapping. The fictional code `free_shipping:parcel` becomes parcel delivery; `cold_route:north` becomes own delivery. A new plugin unexpectedly supplies `weekend_special`. That order is not automatically sent to the default carrier; it appears as an unknown method with order context. After checking the process, an administrator deliberately adds the correct mapping and has only the blocked step reassessed. This example is fictional and shows why a commercial title is not the operational truth.
A test set for every checkout change
- A paid parcel order with and without free shipping.
- Own delivery within and outside the available postcode zone.
- Collection with the required location and any time slot.
- The same visible title with two different method IDs.
- A new, deliberately unknown method that needs to stop safely.
- An old order whose title is later renamed in WooCommerce.
For each case, check not just the ‘parcel’ or ‘collection’ label, but also which subsequent steps do and do not start. A parcel order must not reserve a delivery stop; a collection order must not create a parcel with the carrier. Show in Desk the source method, chosen classification and recovery action. The broader technical relationship with WooCommerce and AFAS is described on the integration page.
Manage the mapping as versioned business configuration. For every rule, record which shop it applies to, who approved it and from when new orders fall under it. Do not silently change historical orders when a title or method is later renamed. They need to retain their original classification and subsequent actions unless an employee deliberately starts a reassessment. Report monthly which method values were used and compare that list with the active checkout. This reveals unused mappings and new variants before they cause an incident.
Also discuss with customer service which words they see. ‘Own delivery’ is clearer to an employee than a plugin ID; the underlying ID remains available for investigation. Separate the technical source value from the operational label. This makes it possible to change plugins without rewriting every instruction and dashboard, while retaining an exact trace of which source rule classified the order.
Assign one process owner to review new methods before publication and check the first orders after launch. Checkout management then becomes part of fulfilment management.
Want to turn your current shipping methods into a verifiable fulfilment map? Let Yindle map the sources and routes together.