An ecommerce refund workflow brief defines what happens after a customer asks for money back: who reviews the request, what evidence is needed, how the financial action is confirmed and what happens to the returned stock. For a Kenyan online store, these decisions should be agreed before a developer turns them into buttons and automated messages.
Bring the workflow to your ecommerce website development team. A refund is not simply a change of order colour in the dashboard. Customer communication, money movement and physical inventory can follow different paths, and the website must not imply that one action has completed all three.
This is an operational requirements guide, not legal advice or a ready-made returns policy. Have the responsible business team approve your commercial terms and any applicable obligations separately. The examples are fictional and do not describe an actual customer's order.
Separate a request from an approved refund
Start by naming the stages your team actually needs. A customer may submit a request, staff may ask for more information, and a manager may approve an amount. These events should not automatically tell the customer that money has already been returned.
Use plain status descriptions in the brief. For example, a request received message can acknowledge the case and explain the next review step. A payment completed message should depend on reliable confirmation of the financial action. If the provider has not confirmed the outcome, keep that uncertainty visible to the authorised staff member.
Record who may make each decision. A support agent might collect information but not authorise money movement. A stock handler might inspect an item without changing the financial record. Our ecommerce staff access guide discusses these responsibilities as an access-planning task.
Avoid defining the process only around a happy-path demonstration. Include a request that is withdrawn, one that needs clarification and one that is not approved. Staff should know how to close each case with an explanation and a traceable record, rather than leaving every incomplete case open indefinitely.
Establish the record that connects the work
The refund case should refer to the correct original order and the relevant item or items. For a partial request, identify the quantity and amount under review without treating the entire order as refunded. Keep the case reference visible in staff communication so people do not have to reconstruct its history from unrelated messages.
Do not ask the customer to send passwords, payment PINs or full private account screenshots. Define the minimum information needed to find the order and understand the request. If supporting photographs are useful for a product inspection, explain what they should show and how they will be handled.
Create a brief record template with an order reference, affected items, reason, review owner, approved amount, payment outcome and stock decision. Not every field belongs in the customer's view. Separate private operational notes from the explanation a customer is intended to receive.
Agree where the authoritative record lives. If staff also use a spreadsheet or messaging inbox, decide which system controls the status and how other records are reconciled. Two independent records can disagree even when each person believes they completed their own step correctly.
Check what the payment integration actually supports
WooCommerce's refund documentation distinguishes automatic refunds through compatible payment gateways from manual records that still require the money to be returned separately. It also warns that directly changing an order status does not itself return funds. These distinctions are useful questions to raise even when your store uses another platform.
Ask the developer which capabilities exist for each payment method in your own configuration. Do not assume that because a checkout accepts a payment it can also return it automatically. The proposal should state what is automated, what requires a separate provider action and how completion is verified.
For an illustrative mixed-payment order, a customer may have paid a deposit and later a balance. The team needs a rule for identifying the relevant payments and the approved amount. The developer should not use a browser-entered number as the only authority for how much can be refunded.
Define the response to a timeout or unclear provider result. Repeating the action immediately could be unsafe if the first request succeeded but its response was delayed. Require a way to inspect or reconcile the original attempt before retrying, with access limited to the staff who need it.
Plan partial refunds without losing the remaining order
A refund can concern one item while the rest of the purchase remains valid. Write down what the customer should see in that situation. The remaining items, outstanding actions and previous payments should still make sense after the partial adjustment.
Consider an illustrative order containing three products, with only one accepted for a return. The brief should identify the affected product and quantity, the approved monetary adjustment and the state of the two unaffected products. Avoid a single global refunded label that makes the remaining work appear cancelled.
Agree how charges and discounts are handled before implementation. A developer cannot infer your intended commercial treatment from the product price alone. Ask the responsible business owner to approve the calculation rules and provide example cases with expected results for testing.
Keep these examples in an acceptance worksheet. They can demonstrate whether the system follows the agreed rules without publishing private orders or making real financial transactions. Use sandbox or mocked provider responses for technical tests, with any later production checks explicitly authorised.
Treat stock inspection as a separate decision
Returning money and returning inventory to saleable stock are different events. A damaged item may need inspection, while an unopened item may follow another route. Define who decides whether returned stock is available, held for review or excluded from sale.
If a customer returns one size of a garment, the system should not increase availability for every size. The stock adjustment needs to refer to the actual product option and quantity. Where an item is replaced instead of refunded, record the replacement separately so staff can understand what was sent and what came back.
Include a place to record the inspection outcome and the responsible person. A general note saying resolved does not explain whether stock was restored, disposed of or still held. Keep the terminology consistent with the catalogue and warehouse process your team already understands.
Ask how the website behaves when the financial and stock decisions occur on different days. A refund case should remain understandable during that gap. Staff need to see the outstanding task without reopening a completed payment action simply to update an inventory note.
Write messages that match the real state
Prepare separate customer messages for receipt of a request, a clarification request, an approved next step and verified completion. Include the case or order reference and a practical contact route. Do not promise a fixed processing time unless the business and provider arrangement support it.
A useful acknowledgement says what has been received and what happens next. It should not imply approval before a review. Similarly, a message about an approved refund should not state that the customer has received funds unless that fact has been established through the intended verification process.
Keep the language consistent across email, the customer account and any connected CRM. Our order notification planning guide covers event ownership and notification boundaries. Refund cases extend that discussion with financial evidence and return-stock decisions, rather than replacing the wider order journey.
When a case needs human attention, specify the queue and owner. Sending an automated acknowledgement is not the same as assigning someone to resolve the request. Review cases that have no next action so a customer cannot become stuck in a loop of polite but unhelpful messages.
Agree acceptance evidence before launch
Ask for a demonstration using fictional orders and sandbox or mocked payment responses. Include an approved full refund, an approved partial refund, a declined request, an unclear provider response and a repeated action attempt. Check the customer's view as well as the staff dashboard.
For each case, verify the expected calculation, authorised staff action, payment evidence, communication and stock result. Record what passed and what remains unsupported. A successful demonstration of one gateway should not be described as proof that every payment method behaves identically.
The handover should explain how to find a case, inspect the last action and escalate an unresolved outcome. Include the person responsible for maintaining message templates and the commercial rules. If a plugin or provider arrangement changes, those assumptions need another review.
Send the proposed policy decisions, payment methods, staff roles and example cases when you request an ecommerce quote. This gives the developer a defined workflow to estimate and test, rather than a vague request for a refund button.
Frequently asked questions
Does changing an order to refunded send money back?
Not necessarily. Platform status and money movement are separate unless the configured integration explicitly connects them. Verify the provider-supported process and its completion evidence.
Can we handle some refunds manually?
Yes, if the agreed workflow records the separate financial action and staff responsibility. Do not mark money as returned solely because someone created a manual note.
Should returned items automatically go back into stock?
Only when that follows your approved inspection rules. The stock decision should identify the actual product option, quantity and condition.
Is this a returns policy template?
No. It is a development brief for implementing approved business decisions. Establish your policy and obligations separately, then translate those decisions into the workflow and acceptance cases.
