Job store-refund-agent-approves-refunds-under-your-cap-by-written-rules · revised 12 October 2026
Let an agent approve refunds under your cap by your rules, and hand the rest to a person
An agent approves refunds only for orders that match your written rules and sit under the cap you set. It never refuses one; every other request goes to a named person.
You might be seeing
- Most refund requests are clear-cut but each one waits for a person
- You fear a tool will refund a damage claim before anyone looks at the photo
No passwords, keys, card details or admin invites needed to start.
What usually happened
Refund money leaves before anyone checks, so a tool that decides alone can pay out on a claim that needed a look. Answers that sound right can contradict your policy, and the business answers for what its tool does. The safe design is a rules table in code, a cap, a daily limit and a rule that anything unclear goes to a person.
Who it’s for: Owner or support lead of a store that spends hours each week on small, clear-cut refund requests.
Usually starts when: Refund emails pile up, most are plainly inside your policy, and you fear a bot will refund the wrong ones.
The result: Requests that match your written rules and sit under the cap you set are refunded by the agent through your store's own refund function, with a log of the rule behind each one. Anything outside the rules, or with a photo, a complaint, a legal word or a repeat pattern, goes to your named person. The agent never refuses a refund.
Check whether this job fits
Answer these without sending files, tickets, code or logins. Nothing is submitted unless you choose to contact us.
What you get
- The rules table
- The agent and its settings
- The log format
- The 14-day proposal lists
- The test results
- The stop-switch note
Included
- A rules table: return window, item types, largest refund, one refund per order and excluded items
- A cap per refund and a daily limit on the number and total value of refunds
- Photo, damage, wrong-item, legal, chargeback and repeat-refund cases always handed to a person
- Decisions made by code against the table; a model only reads the message to pick the request type
- A log of every request: type, rule, decision, amount and time
- 14 days where the agent only proposes and your person clicks each refund, then your person switches it on
- A stop switch and a list of the day's refunds
Not included
- Refusing or declining any refund: only a person does that
- Refunds above the cap or beyond the daily limit
- Judging photos or damage claims
- Chargebacks, disputes or legal replies
- Holding your payment or store keys: the agent runs in your account
- Any message to customers except one fixed confirmation line you approve
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
All 120 rule cases match the expected result, including both sides of your actual window and cap, a repeated request and a second refund on one order; 60 are buyer-held until acceptance. Expected approvals complete exactly once on the test store, and other cases go to your person without a refund. Any wrong or duplicate action fails the whole test.
Evidence: The test log and your table.
All 60 buyer-held handover cases, including photo, damage, wrong-item, complaint, legal, chargeback and repeat requests, reach the person and cause no refund; every missed handover fails the whole test.
Evidence: The expected outcomes and all handover results; a smoke test of these 60 cases, not a future rate.
30 hostile messages hidden in requests change no decision and cause no refund.
Evidence: The hostile-message log. A smoke test: it shows these 30, not every possible message.
Any refund above the cap or the daily limit, any refund of a hand-over case or any refund without a log row fails the whole test.
Evidence: The log compared with the store's refund history.
Your person sets the stop switch on the test store and the next 10 clear requests are queued for a person and not refunded.
Evidence: The stop-switch rehearsal log.
Sign-off. You re-run the acceptance checks with the steps we hand over, read the results and sign off in writing. Payment follows sign-off.
If it fails. If an agreed check fails, you do not pay for this scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- A written refund policy that fits in a rules table
- A store connection you create and revoke, with platform permissions stated in writing; a customer-run code layer exposes only the agreed refund actions
- A test store with invented orders
- A named person who clicks the refunds for 14 days, then switches the agent on
We stop and tell you if
- You want it to decline requests
- You want it to decide photo or damage claims
- You want the cap raised during the 14 days
- The policy cannot be written as rules
What could go wrong
Before automatic mode, your person clicks each real refund. A completed refund may be irreversible; the cap and daily limits bound what the agent can pay, and your person can stop future actions. The log supports investigation, but neither we nor the log can recover money already paid.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A wrong refund is paid. | Code enforces the cap and daily limits, and every refund has a log row; a completed wrong refund may be irreversible. |
| A hostile message talks the agent into a refund. | A model proposes the request type; code uses that type and order facts to apply limits and handover rules. The hostile-message suite must cause no refund. |
| A photo or damage claim is refunded unseen. | Those cases are handed to a person, tested as a set that must all be handed over. |
| Repeat requests quietly use up the cap. | A rule hands over repeat refunds from one customer, and the daily limit is a hard stop. |
A separate automated reviewer checks the work and the test results before hand-over. Your named person clicks every refund for the first 14 days, then switches the agent on, holds the stop switch and handles everything handed over. No human supervisor from us is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the rules table, cap, daily limit and who clicks the refunds
- Agree expected outcomes from redacted requests and order facts; keep acceptance cases unseen
- Build the decision code and the log on a test store
- Test 210 requests: boundaries, handovers and hostile messages
- Run 14 days of proposals only; your person clicks each refund
- Review separately, rehearse the stop switch and hand over
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date in writing before you accept, and work starts only after the agreed inputs are in place. An enquiry creates no charge or booking.
Need to keep it working?
Discuss the monthly check once the agent has run live for a month.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Use the refund rules in your platform, with an approval step on every refund.
- Keep refunds with a person and use the sorting job, which prepares each decision for you.
Questions
Can the agent say no to a customer?
No. It only approves refunds that match your table. Everything else goes to your person, who decides.
Who holds the payment keys?
You hold the platform credential in your own account and can revoke it; its actual permissions are written down, and code exposes only the agreed refund actions.
What stops it refunding too much?
The cap per refund and the daily limit are code. When the daily limit is reached, every further request goes to your person.
Does a pass mean it will be right next month?
No. A pass describes items like the test sample on the day of the test. It is not a promise about future items, and it does not replace your own checking.
Send an enquiry
Send us
- Your refund policy in plain words
- About how many refund requests a week, and the usual amounts
- Your platform and helpdesk
- No logins, keys, customer data or payment details in the first enquiry
Later, once you agree
- Redacted requests with the order facts needed to decide them and expected outcomes agreed by your named person; you keep 60 of the 120 rule cases and all 60 handover cases unseen until acceptance, replacing any used for fixes
- A test store with invented orders
- The cap, daily limit and confirmation line you approve
- The name of the person who clicks refunds and holds the stop switch
You keep your store, helpdesk and credentials; we build on a test store with invented orders. You install the agent and hold its platform credential, whose broader permissions are stated in writing; code exposes only the agreed refund actions. We never hold the credential, and you enable automatic mode after 14 days of approvals.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “store-refund-agent-approves-refunds-under-your-cap-by-written-rules” as the subject.