Every ticket gets a playbook.

01What is a strategy?

One sentence: a strategy is the plan a ticket follows from purchase to delivery.

Every day, tickets are bought across many accounts and marketplaces. Each purchase needs the same care: check it arrived correctly, keep an eye on it, and deliver it before the event. Doing that by hand for thousands of tickets doesn't scale.

So instead, every purchase gets assigned a strategy — a playbook that says exactly what to do and when. Inside, every rule is the same simple sentence: "when X happens (and only if Y), do Z — with safety rules P." The system follows the playbook automatically, and people step in only when something needs a human.

02The ticket's journey

Two fixed points, one path between them.

Every journey is stretched between two moments we always know:

• The purchase — the moment the purchase order appears in Reach. This is the starting line.
• The event date — the concert, game, or match itself. This is the deadline everything works backward from. If an event gets postponed, all scheduled steps automatically shift with the new date.

Every journey ends in one of three ways

Nothing is allowed to just trail off. Every ticket lands in exactly one final outcome:

03The three timing windows

Different moments call for different work.

Between purchase and event, a strategy organizes its work into three windows. This is the core idea behind every playbook:

Steps in the first window count forward from the purchase ("2 days after we bought"). Steps in the countdown count backward from the event ("72 hours before showtime"). And when the countdown starts, the routine check-ups automatically stand down so they never get in the way of the delivery push.

04Reacting to surprises

The clock isn't the only thing a strategy listens to.

Real life doesn't wait for the schedule. If something happens to a ticket — at any point in the journey — the strategy reacts immediately:

That last one matters: switching playbooks is a normal, first-class move. The system records exactly when a ticket moved, from which strategy to which, and why — so there's always a clear paper trail.

When tickets go bad, the strategy has real options

Say the tickets on a sale turn out to be unusable — the account got locked, or the seats vanished. The strategy doesn't just raise an alarm; it can actually fix the situation:

• Un-assign the bad tickets from the sale (keeping a snapshot, so it can be undone) and assign other tickets we already own that are just as good or better.
• Shop for replacements on the wholesale marketplaces we buy from — equal or better seats, within a price limit, with a human approving the purchase.
• Flag the account so it shows up in a review list (and gets labeled in AMP), and create a task for a person — an ops teammate or the puller who owns the account — with Slack alerts, reminders, and escalation if it sits too long.

05One sentence builds everything

Every rule in every playbook is the same sentence.

You don't write code to build a strategy. Every rule you create reads like this:

The trigger library

The common triggers are built in: New Purchase, New Sale, Purchase Canceled, Event Date Change, Error Raised, Status Change, Criteria Matched — plus the clock triggers. And when you build a trigger with filters you'll want again (say, "FIFA errors only"), you can save it as a custom trigger with a name. It joins the library and any strategy can use it. The library shows where each one is used — and editing a shared trigger warns you it affects every strategy using it.

Not sure a trigger is set up right? Each one can show a quick simulation: "this would have fired 14 times in the last 30 days" — so you know what you're signing up for before it goes live.

Required triggers — every playbook answers the basics

Some things every playbook simply must have an answer for. An event playbook must say what happens on New Purchase, New Sale, and Purchase Canceled — those aren't optional. The builder shows a checklist ("Required triggers: 2 of 3 handled") and won't let you publish until they're all covered. Most playbooks don't write those answers themselves — they just inherit the standard answer (next section).

A strategy also declares its scope: most govern a whole event, but a strategy can be scoped to a single sale or ticket — say, a special playbook for one problem sale. Sale-scoped playbooks have a smaller required list — New Purchase and Purchase Canceled (with Error Raised recommended) — because the sale already exists.

Inheritance — define it once, in the Base strategy

There is one Base strategy at the root. It holds the standard answer for the required triggers: what normally happens on a new purchase, a new sale, a cancellation. Every other strategy inherits those answers automatically and only overrides what it does differently.

In the builder, inherited handlers appear ghosted with an "inherited from Base" chip. Click to override — the handler is copied into your strategy as editable. Remove the override, and you're back to inheriting. The Base itself (currently v3) is edited like any strategy, with one caution: change the Base and every inheriting playbook picks up the new default — the builder warns you before you publish that change.

Routines — the reusable sequences

Sequences you use over and over — the standard account health check, the full ticket-link delivery ladder — are saved as named routines. A trigger can fire a one-off sequence or a routine from the library; either way the whole proven sequence comes with it.

When a routine is improved, existing strategies keep using the version they were built with until someone deliberately upgrades them. No surprise changes.

Policies — the renamed safety rails

Safety rules aren't blocks you place; they're settings attached in the inspector, at two levels. Strategy-level policies cover the whole playbook: autonomy (dry-run / ask-first / automatic), the never-ending-pending cutoff, daily action caps. Per-trigger policies tune one handler: its retry ladder per error type, cooldowns, and what happens when a human task it created goes stale.

06Trigger & action reference

Everything in the builder, in one place — triggers, actions, routines, policies.

Triggers — built-in

Triggers — schedule (the clock is a trigger too)

Triggers — custom (saved to the library)

Do this — actions: flow & branching

Do this — actions: delivery

Do this — actions: inventory & allocation

Do this — actions: account health

Do this — actions: human tasks

Do this — actions: lifecycle

Policies — the safety rails (set in the inspector, not placed on the canvas)

Routines — reusable sequences

07Versions & safety

You can never break a running strategy by accident.

Who decides which strategy a ticket gets?

• Each event has a default. New purchases for that event automatically enroll in it.
• Smart rules can override the default — e.g. "FIFA purchases → FIFA Aggressive", "tagged no-fulfill → Manual". Most specific rule wins, and you can preview how many sales a rule would affect before applying it.
• A person can always pin a specific ticket to a specific strategy. A human pin beats every rule.

08Coming next: spotting purchases earlier

Phase 2 — designed today, built later.

Today, a journey starts when the purchase order appears in Reach. Phase 2 will start watching even earlier, using two additional signals:

• Cart activity — the earliest hint that a purchase is happening (also the noisiest).
• Purchase-confirmation emails — arriving within seconds of a buy.

The job of Phase 2 is simple: if those early signals fire but no purchase order shows up in Reach within a grace period, raise the alarm — a purchase happened that our system of record doesn't know about yet. Once the PO exists, Phase 2's job is done and the normal journey begins. Nothing about today's strategies has to change when it arrives.

09The Fulfillment screen

Strategies is where you design. Fulfillment is where you watch it happen.

The Fulfillment view shows every running journey, grouped by event: