acilox / solutions / aftercare
🛍️ AI Copilots & Automations

Aftercare

Post-purchase resolution agent that reads an inbound "where's my order / this arrived cracked / I want a refund", pulls the real order and carrier facts, cites the governing policy clause, and resolves the case end-to-end — tracking answer, exchange, carrier claim, save-the-sale offer, or refund — with a scored return-abuse guardrail and a human gate on anything that moves money.

100%
Return-abuse recall
0
False abuse flags
100%
Decisions cited to clause
<60s
Demo to value, no API keys

Why this exists

Post-purchase tickets — WISMO ("where is my order"), returns, exchanges, damaged items, and lost parcels — are the highest-volume, lowest-margin queue in ecommerce, and they're where the money quietly leaks: a refund issued when a free exchange would have saved the sale, a reship on a parcel that was actually delivered, a serial returner refunded on autopilot. Generic support bots deflect FAQs but don't *resolve* — they can't read the order, can't cite the policy, and can't be trusted to issue money. Aftercare owns the outcome instead: it classifies the message, pulls the order and full carrier scan history, finds the exact governing clause, and takes the action — with every decision cited to the order fact and policy clause behind it, a save-the-sale offer computed before any cash refund, a continuous return-abuse score that ranks rather than trips, and a human-in-the-loop gate on anything risky. It's the fastest of the Studio demos to stand up, and the one that most directly prices its own value in refund-avoided dollars.

How it's wired together

inbound

auto

hitl

custom agent loop

risk
continuous abuse score
volume + rate

resolve
track / exchange / claim / refund

cite
order fact + policy clause

email

chat

helpdesk

classify intent
WISMO · return · exchange
damaged · claim

order + carrier facts
commerce · tracking adapters

policy retrieval
structured → lexical + vector · RRF

CaseScope
typed contract
intent · order state · policy eval
save offer · risk · confidence

policy engine
window + abuse gated

execute action
refund · exchange · claim

review queue
approval executes

audit log
hash-chained

Aftercare architecture overview

How it works, end-to-end

  1. Intent classification, then facts before any decision

    A transparent, whole-word classifier labels the message — WISMO / return / exchange / damaged / claim — and the agent pulls the order, line items, value, and full carrier scan history before deciding anything. A WISMO with no carrier scan for a threshold number of days becomes a proactive carrier claim and reship, before the customer has to ask twice.

  2. Evidence-cited resolution against the governing clause

    Hybrid retrieval first filters policy clauses to the ones whose applicability actually matches the item class and reason, then fuses lexical and vector ranks — so a damaged case cites the damage clause and an out-of-window return cites the window clause, every time. No citation, no auto-action; the return window is measured from delivery, not order placement, so slow transit never eats the customer's window.

  3. Save-the-sale before refund

    An exchange or store-credit offer at a small uplift is computed and surfaced before any cash refund, with the refund-avoided value tracked as a first-class KPI on the dashboard. The agent's job is to resolve the case *and* to protect the margin, and the console shows exactly how much it saved.

  4. A return-abuse guardrail that's a scored signal, not a counter

    A continuous risk score blends absolute return volume with the return rate (returns ÷ orders), so a loyal forty-order customer with four returns clears while a four-order customer with three returns is flagged — the case a raw count line gets backwards. Crossing the score threshold routes to a human regardless of intent.

  5. Policy-gated autonomy and an audit that's a hash chain

    A first-match-wins policy decides auto vs human review: big refunds over a settings-driven threshold, escalations, low confidence, and abuse flags all hold for a person, and every refund / replacement / claim is gated on both the policy window and the abuse score. Every action — agent or human — writes to a SHA-256 hash-chained log that detects any tampering with history.

  6. HITL approval actually executes — and MCP exposes it read-only

    Approving a queued case runs the proposed resolution's adapter actions (refund / replacement / claim + reply) and marks it human-actioned — approval is a real action, not a status flag. A read-only MCP server exposes cases, the CaseScope, policy clauses, a customer's abuse score, and order tracking to any assistant. Run it with `aftercare mcp`.

The choices that matter

Decision

Return abuse is a scored signal, not a threshold on a counter

A raw `return_count >= N` line flags loyal high-volume customers and misses low-order serial returners — it gets the important case backwards. Blending volume with rate ranks customers instead of tripping on a count, and the eval reports the separation margin between the weakest true abuser and the strongest legitimate customer while gating false flags at zero.

A continuous score needs a tuned threshold and an adversarial corpus to defend. That's what makes it trustworthy enough to hold a refund.

Decision

Every money-moving action is doubly gated

Refunds, replacements, and carrier claims all check clause eligibility — measured from delivery — and the abuse score before executing. A late damaged report or an out-of-window claim routes to a human rather than auto-acting. The agent is allowed to be helpful only inside the policy it can cite.

Double-gating sends more cases to review than a looser bot. For anything that issues money, that's the correct bias.

Decision

HITL approval executes, it doesn't just flip a flag

Approving a held case runs the real adapter actions and records the refs, so the review queue is a control surface, not theatre. A status-only approval that leaves the refund un-issued is a silent failure waiting to happen; the integration test asserts approval actually executes.

Wiring approval to real actions is more than a boolean toggle. It's the difference between a queue that works and one that lies.

Decision

One corpus, two consumers

A single labelled synthetic corpus is the source of truth for both the demo seed and the eval ground truth, so the showcase and the backtest can never silently disagree. Every connector (Shopify / helpdesk / carrier) and the LLM default to deterministic mocks, so it runs end-to-end with zero API keys and zero real store credentials.

Mock output trails live systems until credentials are set. The point is a run any evaluator can reproduce in under a minute.

Built on

Python 3.12FastAPI · UvicornSQLAlchemy 2.0 · AlembicPostgreSQL 16 · pgvectorRedis · RQPydantic v2 · structlogHTMX · Jinja2Fernet · PyYAMLAnthropic SDK · sentence-transformers