Documentation

How REX decides

This guide is for teams integrating REX. It explains what data REX reads, how it decides which customers need attention, what it will and won't do on its own, and what every number on the dashboard means. Nothing here is a black box: every score REX shows can be traced back to the signals below, and every action to the rule that allowed it.

What REX reads

REX works with the systems you already have. The more it can see, the better it judges. What it can't see, it tells you: each customer page lists anything a score was calculated without.

When you connect Stripe, REX imports every customer and subscription straight away, not just the ones whose payment has already failed. Payments that are already failing are picked up at import.

Sending REX your data

Stripe needs no code. Everything else is one authenticated POST with your workspace's API key (Authorization: Bearer rex_…).

customer_id is your ID for the customer, the same one Stripe holds (cus_…). Sending the same external_event_id twice is safe: REX handles each event once.

How REX reaches customers: phone calls and SMS go through Twilio, and emails through Resend, from REX's own accounts. Every attempt is recorded with its real result.

Three questions, answered separately

For every customer, REX asks three separate questions:

1. Risk: how likely are we to lose them?
2. Priority: how much does acting now matter?
3. Contact: may REX reach out right now?

They're kept apart on purpose. A loyal, engaged customer isn't more likely to leave; they're more worth keeping. And a high-risk customer who asked not to be called stays high-risk, but REX doesn't call them.

Risk: how likely are we to lose them?

Risk is a score from 0 to 100. It's the sum of the warning signs below, capped at 100. Each sign shows on the customer page with its points and where it came from.

Levels: 65 and above is high, 35–64 is medium, below 35 is low. Your rules can treat levels differently. For example, you can let REX call high-risk customers automatically and ask for approval on the rest.

Priority: how much does acting now matter?

Priority puts customers in order. It's calculated as:

Priority = risk × a year of the customer's revenue × urgency

A customer paying ₹4,999 a month at 80% risk, in a normal situation, has a priority of 0.8 × ₹59,988 × 1 = ₹47,990. The command center sorts every queue by priority, and each customer page shows this sum.

Urgency reflects the situation itself:

Value tiers are relative to your own customers, not fixed amounts, so they mean the same thing whether your plans cost $49 or ₹20,000. The top 20% of your paying customers by monthly revenue are high value, the next 40% mid, and the rest low. The tier decides whether a customer is worth a phone call at the end of the escalation ladder: low-value accounts are handed to your team instead.

Contact: may REX reach out right now?

Before any call, REX checks a gate. The gate isn't a score: a single failed check stops the call.

When someone on your team clicks Let REX handle it on a customer, that's a person deciding. REX calls even within the rest period. Do-not-call, "I'm handling this" and calling hours still apply.

After a failed payment: the escalation ladder

REX doesn't phone a customer the minute a payment fails. That feels pushy, and many failures fix themselves. It starts with the quietest thing that might work and escalates only while the payment is still unpaid.

A temporary decline (such as insufficient funds):

A card that can't be charged again (stolen, lost or expired): retrying is pointless, so:

• It stops the moment they pay. Every remaining step is cancelled.
• It stops if the case moves on for any other reason, for example when someone approves a different action.
• Pace: standard uses the timings above, gentle waits 1.5× as long, fast waits half as long.
• On by default for every new workspace. You can turn it off, or change the pace, in Setup → Set the rules.
• When it's skipped: in shadow mode, when a person clicks Let REX handle it (then REX calls straight away), and for fraud or a dispute, which always go straight to a person.

After a promise to pay

Customers often agree on a call to pay later: "I'll pay on Friday", or "send me the link in three days". REX holds the account until that day and doesn't charge the card early. It doesn't forget the promise either:

• Paid: the case is recovered, for the amount actually paid. REX checks your payment system directly, so a missed webhook can't leave a paying customer marked unpaid.
• Not paid: the case is marked promise not kept and moves to Needs a human. The offer log records the hold as not kept, so your team can see it before granting another.
• Paid early: the moment the payment arrives, the reminder and the check are cancelled.
• If your payment system can't be reached, REX tries again in six hours, up to three times, rather than calling a promise broken over a network error.

These follow-ups run on the calendar: a date agreed on a call is a real date.

Before anything fails: card-expiry reminders

Once a day, REX looks for cards on file that expire by the end of next month. It sends each customer one friendly reminder by email or SMS to update their card before the payment fails. A customer gets this reminder at most once every 25 days, and it's never a phone call.

Before anything fails: usage slipping

A customer rarely cancels out of the blue. Usage usually drops first. If you send REX a usage reading for each customer (active days in the last 30), it compares each reading with that customer's own normal, not with everyone else's:

• The customer's normal is the median of their earlier readings. REX keeps the last 12.
• Slipping means the latest reading is under 60% of that normal. It needs at least 4 readings, and a normal of at least 8 active days, so a light user who has always been light is never flagged.
• What REX does: once a day it opens a case and sends one short, helpful email offering a person to help. It's never a call, never a discount, and never "we noticed you're leaving".
• How often: at most once every 3 weeks per customer. A customer who already has an open case isn't nudged.
• Outcome: the case closes as nudged. If the customer later fails a payment, their risk already carries the usage signal.

POST /v1/usage
{ "customer_id": "cus_123", "active_days_30": 7 }

What REX may offer on a call

What REX may agree to is set by your rules. Everything it agrees is written to the offer log, so the same customer can't be granted the same concession month after month without your team seeing it.

Offers are real actions, not promises

When a customer agrees to an offer on a call, REX carries it out in your payment system straight after the call, through the same policy check as any other action:

• Pause: Stripe stops collecting until the resume date (pause_collection), and the failed invoice is voided, so the customer isn't charged while paused. REX doesn't retry the card.
• Cheaper plan: REX moves the subscription to the next plan down, meaning the most expensive active price below the current one in the same currency and billing interval. The change applies from the next bill, with no proration. If there's no cheaper plan, REX applies a coupon instead: 20% off for 3 months.
• Result: either way, the case closes as retained, and the customer page shows exactly what changed (for example, "Moved from Growth to Pro").

If your rules need approval for a cheaper plan, the case stops at Needs a human until someone approves it.

Offer limits

A concession works once. Given every month, it's a discount people learn to ask for. So:

• Once per 90 days: a customer can accept each kind of pause or price cut at most once in 90 days.
• On the call: REX doesn't offer the same concession again. A customer asking for a second pause, or complaining about price again after a plan change, is handed to your team.
• In the gate: if an offer still reaches your payment system, it's blocked by the offer_limit rule and recorded like any other blocked action.

Payment links

A payment link is a page in your payment system (for Stripe, the hosted invoice page), where the customer can pay, with a new card if needed.

• Delivery: REX sends the link by SMS, email or both, as you choose.
• Timing: it goes straight after the call, or on the day the customer asked for.
• What's recorded: each channel's actual result: sent, failed (and why), or not sent (for example, no email on file). The dashboard never says a link was sent when it wasn't.

Shadow mode

Every new workspace starts in shadow mode. REX works every failed payment through (who to call, what to offer, what to retry) and records each decision as "would have", without calling, texting or charging anyone. Review a few days of shadow decisions in the command center and the report. When you'd have made the same calls, switch REX to live.

Your rules become REX's policy

The choices in Setup → Set the rules generate the policy REX runs under. Nothing is left to judgment outside it:

• Always a person: fraud and chargebacks, whatever else you choose.
• Never automatic: anything your rules don't cover waits for a person.
• Always on record: every decision is stored with the rule that made it and why, and every action with its result.

The numbers on your dashboard

The command center's queues:

• REX is on it: detected, calling, or climbing the ladder.
• Needs a human: approvals and hand-offs.
• Waiting on the customer: they promised to pay by a date. REX checks the day after, and moves an unpaid promise to Needs a human.
• Recovered: paid, or kept on a pause or a cheaper plan.

Each queue is ordered by priority.

What REX keeps on record

• Every policy decision: what was proposed, the outcome (automatic, needs approval, blocked), the rule and the reason.
• Every action and its result: calls with their transcript, payment retries, pauses, plan changes, links, messages.
• The contact log: every call, SMS and email, and how it went.
• The offer log: every hold, link, retry, pause and plan change offered, whether it was accepted, and whether a promised payment was kept.
• The clock: every step REX has planned, taken or stopped, with the result or the reason. Open it from Command center → Coming up → The REX clock: Coming up, Done and Stopped tabs.

Today's limits

• Product usage and support signals come from connected tools. Without them, risk is scored from Stripe alone, and the customer page says so.
• Everyone calls from a shared REX number for now. Your own number is coming.
• Messages to Indian numbers need DLT registration for business SMS. International SMS may be filtered until then.