One workflow, documented properly.
Every Novatek workflow is written down before it is run. This is a complete example — a refund request in an e-commerce operation — at the level of detail a new starter can actually work from.
Every SOP starts with who owns it.
An undocumented owner is how a procedure quietly goes stale. Each one carries a version, an owner, a review date and the systems it touches.
| Procedure | SOP-CS-014 · Refund request, standard |
|---|---|
| Version | 3.2 — supersedes 3.1 |
| Owner | Team Lead, Customer Support |
| Approved by | Client operations manager |
| Review cycle | Quarterly, or on any policy change |
| Systems | Help desk · commerce platform · payment dashboard |
| Service level | Acknowledge 4h · resolve 1 business day |
| Applies to | Orders under the approval threshold, inside the returns window, standard payment methods |
Nine steps, with the decisions made explicit.
The steps most SOPs skip are the decision points — where an agent has to judge something. Those are exactly the steps that need writing down.
-
Step 1
Verify the customer
Confirm identity against the order record using the agreed verification fields before discussing any order detail.
- If verification fails, do not confirm or deny order details
- Offer the account-recovery path instead
- Log the failed verification attempt
-
Step 2
Locate and read the order
Open the order, check status, fulfilment date, payment method and any prior contact on the same order.
-
Step 3
Check eligibility
Test the request against three conditions: inside the returns window, item category eligible, and condition as described.
- All three met → continue to step 4
- Any one failed → go to exception E1
- Ambiguous condition → go to exception E2
-
Step 4
Check the value threshold
Refunds at or below the agreed threshold proceed. Above it, authorisation is required before anything is promised to the customer.
- Never tell a customer a refund is approved before authorisation exists
-
Step 5
Process the refund
Issue to the original payment method only. Record the reference against the order.
-
Step 6
Confirm to the customer
Confirm the amount, the method and the realistic timescale for it to appear — including that the timescale is set by their bank, not by us.
-
Step 7
Tag the contact
Apply the refund reason tag from the agreed taxonomy. This is what makes the contact-driver reporting possible, so a lazy tag costs the client real insight.
-
Step 8
Note for the next person
Write the note for whoever picks up the next contact on this order, not for yourself.
-
Step 9
Close
Close only when the refund is issued and confirmed. A pending authorisation stays open with a follow-up set.
What to do when it does not fit.
The quality of an SOP is decided here. Without documented exceptions, agents improvise, and improvisation is what customers experience as inconsistency.
| Code | Situation | Action | Escalates to |
|---|---|---|---|
| E1 | Outside the returns window | Explain the policy; offer the goodwill option if within the discretionary band; otherwise decline politely and record the reason | Team lead if the customer disputes |
| E2 | Item condition disputed | Request photographs; do not decide on the call; set expectation of a decision inside one business day | Team lead, then client if unresolved |
| E3 | Above the authorisation threshold | Submit for authorisation; tell the customer it is being reviewed, not approved | Client operations |
| E4 | Original payment method closed | Do not refund to an alternative method; follow the alternate-payee procedure | Client finance |
| E5 | Suspected fraud indicators | Take no action on the order; do not alert the customer; escalate immediately | Client fraud team, same day |
| E6 | Third refund request from the same account this quarter | Process if eligible, then flag the pattern in the weekly pack | Reported, not escalated |
How we know it is being followed.
A procedure nobody checks is a suggestion.
- Process adherence is a scored criterion worth 20 points, and skipping verification zeroes the contact outright.
- Refunds above the threshold are reconciled against authorisations weekly.
- Exception codes are reported in the weekly pack, so a rising E2 rate surfaces a product or listing problem.
- Every version change is logged with what changed, who approved it and when the team was retrained.
Version history
| 3.2 | Added E6 pattern flag after three months of repeat-request data |
|---|---|
| 3.1 | Authorisation threshold raised; step 4 rewritten |
| 3.0 | Verification fields changed after client security review |
| 2.4 | Timescale wording changed — customers were reading it as a guarantee |
Version 2.4 is a real kind of change: the procedure was correct but the phrasing produced repeat contacts. Contact-driver reporting is what surfaced it.
Which of your processes is undocumented?
Most operations have one everybody relies on and nobody has written down. Show us that one, and we will map it and produce the first draft of its SOP.