AI support that resolves instead of replying.

Every support bot answers questions. Ours takes the action — then writes down exactly what it did.

cancels the order  ·  changes the shipping address  ·  issues the refund
resends the license key  ·  updates the subscription

Billing unitPer resolution.
Not seats. Not conversations.
Writes intoShopify · Stripe
Your backend via API
Every actionSpend-limited, approval-gated,
logged immutably
The metric Same ticket, two scoring systems

We sell on zero-touch resolution. Never deflection.

Deflection counts a ticket as a win when it leaves the queue. It does not ask where it went. A customer who reads a help article and gives up is, on that scoresheet, a success.

Zero-touch resolution counts a ticket only when the thing the customer asked for has actually happened, and no human being touched it. It is a harder number. It is also the only one worth paying for.

Here is the same ticket, scored both ways.

The resolution log One ticket · every action · human touches · elapsed

Every closed ticket produces one of these.

Not a transcript. A record of what was done — which systems were written to, which rule permitted it, and whether a person was involved. This is what you audit, and what you get billed against.

TKT-8814 refund.partial Zero-touch Specimen
ChannelEmail
Opened14:22:07Z
Closed14:23:19Z
Elapsed1m 12s
Human touches0
  • 14:22:07ZInbound email received“Two of the four mugs arrived cracked. I don't want a return label, I just want money back for the broken ones.”
  • 14:22:09ZIntent classified → refund.partialConfidence 0.94 · customer matched on email to order #1042
  • 14:22:11Zshopify.orders.get(#1042)Read-only. 4 × ceramic mug @ £13.50, fulfilled 6 days ago, no prior refund
  • 14:22:14ZPolicy evaluated → rule R1£27.00 ≤ £50.00 limit · returning customer · no refund in last 90d → AUTO
  • 14:22:52Zshopify.refunds.create — £27.00 GBPIdempotency key rf_8c21f4 · 2 line items · restock: false
  • 14:23:04ZReply sent, refund confirmed with referenceCustomer told the amount, the card, and the 3–5 day timing
  • 14:23:19ZTicket closed — zero-touchNo human queue entry created at any point
RSTR STRATEGIES · rstrstrategy.com POLICY v7 @RSTR_Strategy

SPECIMEN. Constructed to show the format — the merchant is not named and the figures are illustrative. This tag stays on until there is a real customer log to put here. Published logs carry the actual ticket, the actual calls, and the actual timestamps, because a resolution log with invented fields is just a screenshot.

Action coverage Select a row for scope and rule

What it is actually allowed to do.

A generic bot has one tool: send a message. This is the full write surface, the exact API scope behind each action, and the default rule that governs it. Every scope is narrow on purpose — the agent gets the permission the action needs and nothing adjacent to it.

Card details are never read or stored. Payment-method changes are handled by sending the customer a Stripe-hosted update link — the agent has no path to raw card data.

The permission layer Interactive · nothing here is a real merchant

Nobody hands refund authority to an AI on trust.

So the interesting part of this product is not the model — it's the layer that decides whether the model is allowed to act. Set the parameters below and watch the policy resolve. Execute writes to the simulated audit log and draws down the daily budget, exactly as it would in production.

Daily agent budget£128.50 / £500.00
AUTO-EXECUTE RULE R1
Audit log — simulated

Thresholds, caps and allow-lists shown here are an example policy. Yours is configured per account, versioned, and changing it is itself an audited event.

From our own ticket data n = 40,000

Across 40,000 tickets, 61% were one of five requests.

Support volume feels infinitely varied from the inside. It isn't. Nearly two thirds of everything a store receives is five questions wearing different clothes — and all five have a definite, checkable action sitting behind them.

That is the whole thesis of this company in one number. You do not need an agent that can discuss anything. You need one that can finish five things, reliably, without supervision.

n = 40,000 tickets. Share of total volume.

    Pricing model What each unit rewards the vendor for

    Priced per resolution, because that is the thing being delivered.

    Every billing unit creates an incentive. It is worth knowing which one your vendor is optimising for before you sign. Select a model to see who it pays.

    Monthly, by resolution volume, in bands. A ticket the agent could not finish is not a resolution and is not billed — which is the only version of this that is honest.

    Where we don't fit Read this before booking a call

    Cases where you should not buy this.

    Every vendor has these. Most make you discover them in month three. Here are ours, in advance.

    Under ~500 tickets a month

    The integration and policy work costs more than the support hours it saves. Come back when volume is a real line in your budget.

    No API on your backend

    We can read a knowledge base and answer. We cannot take actions in a system that has no programmatic way in. Shopify and Stripe are fine — a bespoke admin panel with no API is not.

    Voice and phone support

    Not supported. Email, chat, and helpdesk tickets only. We would rather say so than run a pilot that quietly fails.

    Regulated financial refunds

    Consumer-credit, insurance and regulated payment flows carry obligations we are not set up to satisfy. Out of scope, deliberately.

    You are happy on Fin or Decagon

    They are well funded and good. If their pricing works at your volume, stay. Our ground is the merchant they price out or under-serve, with deeper action coverage than a generic bot.

    You want it fully autonomous on day one

    Everyone starts read-only in shadow mode, then earns write scopes action by action. If that sounds slow, we are the wrong vendor — write access to refunds is where bugs cost real money.

    Talk to us Reply within one working day

    Send your five most common tickets.

    The fastest way to find out whether this works for you is to show us the actual queue. Send the requests you get most, and we will come back with which are resolvable end-to-end, which need approval gates, and which we cannot take.

    • 01We map your five most common tickets to concrete actions and API scopes.
    • 02You get a draft policy — caps, thresholds, allow-list — before any integration work.
    • 03Shadow mode first: the agent proposes, you approve, nothing is written until you say so.
    Enter your name.
    Enter your company.
    Enter a valid work email address.
    Tell us at least one.
    Not the right answer — try again.