An order is more than a total
If your business already receives orders but keeps chasing choices, balances or dispatch details through chat, begin with one complete order record. It connects the customer's choice with the work required to fulfil it. The current details layout separates items, money and delivery or booking information into tabs. That makes it easier to inspect the relevant part without treating a chat thread as the only source of context.
Begin with identity before taking action
Confirm the reference and customer before editing a note, copying details or using a fulfilment control. Similar product names and repeat customers can make an apparently familiar order the wrong one. Copy only the information the receiving operator needs; an order ID is often enough for a support investigation.
Keep state changes distinct
A comment saying paid does not collect money. A tracking number does not prove delivery. Deleting an order is not a refund or a shipment cancellation. The workspace brings those records closer, but each action still has its own consequence and confirmation.
Evaluate the exceptions as well as the happy path
Open a representative physical order and, if relevant, a service order to inspect the different tabs. Check how missing information and outstanding balances appear. This page does not claim every external message, payment or courier event is automatically imported. Define who verifies and updates the parts that remain manual.
UNDERSTANDING THE WORKFLOW
Confirming payment and accepting an order are different decisions
Receiving money answers one question. Accepting the order answers another: can you fulfil the agreed items and conditions?
What changed in the implementation The inspected merchant commit 3f1bab2 introduces a direct-payment strip and separates confirmation from acceptance. Its description explains why the order remains available after confirmation: the merchant still needs to act on it. This is implementation evidence, not a declaration of a public launch date.
Use the separation deliberately First verify the direct payment through the actual receiving account. Then check the product, quantity and fulfilment commitment before accepting. A customer’s payment screenshot alone should not collapse those checks into a single assumption.
If payment is not found, retain the distinction between an unresolved claim and an accepted order. Use the available workflow rather than inventing a status in a message.
Bound the claim This explanation does not promise automatic bank checking, availability for every payment method or a particular refund process. Those are separate capabilities.
The order-workspace page owns the broader feature description. This article explains the operational value of keeping two decisions separate. Publish a dated release note only once the corresponding deployment and account behaviour have been verified.
An order workspace helps you separate money from fulfilment
An order can be awaiting money, awaiting dispatch or awaiting a customer decision. Describing all of those situations simply as “pending” makes the next action harder to identify.
What the inspected surfaces support The merchant order workspace has separate navigation and dedicated money and delivery components. That supports an explanation of distinct operational views. It does not imply that every displayed status is automatically updated by an external system.
Start with the question you need to answer. Use the money information to understand recorded amounts and the delivery information to understand fulfilment. Reconcile contradictory evidence instead of assuming one summary label explains everything.
Keep a clear next action For an illustrative order with a recorded balance and no shipment, decide whether payment follow-up or fulfilment preparation comes first under your process. Do not treat opening a tab as performing the action.
Avoid feature inflation An organised workspace is not proof of universal courier integration, automated accounting or guaranteed notification delivery. Describe those only where verified separately.
Link this explanation to the existing order-workspace capability page and task-specific help. Its role is to explain the decision structure, not duplicate every button label in a second manual.
Bring this checklist to your evaluation
- Verified order identity
- Items and options inspected
- Money reconciled separately
- Appropriate delivery or booking workflow
Compare the workflow before choosing software
Already handling orders? Use the practical business-software checklist to test a representative order, the money record and the handoff to the next person. You can use the checklist with any provider.
Check the workflow that matters to your business
Read the relevant setup and troubleshooting guide, then explore getting started with oBizee. Confirm current account availability and terms before committing.