“Next best action” is a phrase that has grown larger than the job it can do. Vendors use it for journey builders, generative creative, channel optimizers, and full marketing stacks. A buyer who only heard the phrase can reasonably ask what the system is supposed to own.

A useful answer is narrower. A next-best-action problem is one bounded choice among actions you already approve, including the choice to do nothing, scored against one business result you already track. Strategy, content, consent, and delivery stay outside the learner.

That definition is what BanditBuzz is built around. This post explains the problem shape, what the product does and does not do, and where the method stops being the right tool.

Who owns which part

Think of three owners, not one product that replaces your stack.

You own the plan. You choose the goal, audience, campaign dates, approved offers and creative, channel rules, budget, and legal limits. BanditBuzz does not invent or approve any of those.

BanditBuzz owns the repeatable choice. For each eligible person, it picks among the actions you named, including nothing. For scheduled outbound work, it can also pick a local time inside days and hours you allow.

Your customer tools own the experience. Your product, email platform, and journey tools still render the message, apply consent, and send or show it. They remain the source for delivery and engagement reports.

If you remove BanditBuzz from that picture, you still have a campaign. If you remove your plan or your execution tools, you do not. The learner sits between a declared goal and tools that can carry out a named pick. See the product overview for that placement in plain terms, and pricing for what is free versus paid.

The marketing team sets the decision, BanditBuzz makes one bounded choice, and customer tools execute it.

The current product boundary. Strategy and execution stay outside the learner.

The unit of work is one decision point

A decision point is a named place where the same question repeats for many people. Examples: which win-back offer to show after a churn risk flag, which support save script to try on a call, whether to send a postcard this week or wait.

That unit needs four facts:

  1. A name. Stable enough that later analysis can group choices under it.
  2. A flat list of options. Strings your execution path understands, such as offer_10_off, postcard, or nothing.
  3. One reward definition. An event name, a window in days, and optionally a value field when you care about magnitude rather than only conversion.
  4. A person identifier set. Email, phone, address, or other keys you already collect. The decide call and the later result event do not need to share the same key.

BanditBuzz does not ask you to register an action bank, journey graph, or content object before the first choice. Options are strings in the request. You map each string in the tool that will execute it. Offer, channel, and creative can sit inside one string when that is how your stack works; the current learner treats that combined treatment as one flat option and does not learn those parts separately.

Real-time pull and scheduled push are the same learner

People meet your brand in two ways.

Sometimes the person is already in front of you: a site session, an app screen, a support call. Your code needs an answer now. That is the pull path: POST /decide returns a choice, a decision ID, and a policy label.

Sometimes nobody arrives, and you still have a standing question for every person you know: should anything happen to this person right now, and if so which approved action? That is the push path. One declaration (PUT /decisions/{name}) turns on eligibility, a per-person cooldown, optional local-time limits, and a destination for actionable picks.

Both modes share one decision point, one policy, one holdout, and one scoreboard. Pull answers “when” because the person’s arrival answers it. Push answers “when” through eligibility and cooldown, then can learn a release time inside windows you set. The setup view shows the decide and events shapes for the pull loop and the declaration that enables push.

What BanditBuzz does not do on either path is write copy, approve offers, or press the send button. It returns or delivers a pick. Your tools execute it.

One goal, one window, business events as rewards

The reward block is the contract that makes “best” mean something. You name the event that counts as success (purchase, renewal, signup), how many days after the decision that event may arrive, and optionally which property holds value.

That design has consequences:

  • Channel clicks are not the default objective. You can learn from purchases, renewals, cancellations, and other results you send back, even when another tool performed the action.
  • Delayed results are normal. Attribution runs in batches after identity joins. A decision made with email can later match a purchase sent with phone or address.
  • Young choices wait for their window. An option is not punished for rewards that have not had time to land. A choice becomes a zero only after the full window closes, unless a reward arrives earlier.
  • Last eligible decision wins. When windows overlap, the latest qualifying decision for that person gets the event. That is a clear product rule, not multi-touch measurement. BanditBuzz does not reverse a reward for a later return or chargeback. If the result can reverse, send a settled event as the reward.

The free policy uses Beta-Bernoulli Thompson sampling, the probability-matching rule introduced by William R. Thompson in 1933. Each option keeps a conversion posterior built from matured decisions. At decide time the policy samples those posteriors and picks the winner. There is no exploration-rate dial to tune. About 10% of people, assigned by a stable hash per decision-point version, form a holdout so the scoreboard can report lift against a control rather than against last year’s campaign.

Policy updates are not real time. Attribution, maturation, and posterior recount run on a nightly batch. That matches how rewards actually arrive. Work on delayed rewards in contextual bandits, such as Howson, Pike-Burke, and Filippi (2022), supports keeping outcomes pending until they become available rather than forcing a same-session feedback wire.

What stays outside the learner

Not every marketing task is a next-best-action problem. Keep these outside BanditBuzz on purpose.

Fixed launches and required messages. A product recall notice, a legal notice, or a one-time launch blast is not a place for exploration. Send it with your existing tools. Do not put it in a learner that sometimes picks another arm.

Content generation. BanditBuzz does not write subject lines, images, or offers. If you want generative creative, keep that in a studio you trust, then pass only approved action names into the decision list.

Consent and suppression. Your ESP and CRM still own unsubscribe, preference centers, and legal gates. Push excludes people with an unsubscribe event by convention, but that is a safety floor, not a full compliance system.

Journey orchestration. Branching logic, wait steps, and multi-step programs belong in the tools that already run them. BanditBuzz answers one choice at a time. It does not replace a journey builder.

Paid media bidding. There is no Meta or Google Ads connector today. Real-time choices can drive surfaces your code controls. Scheduled picks currently go to Klaviyo, BigQuery, Snowflake, S3, or a CSV download.

Competing optimizers on the same choice. If BanditBuzz and a channel optimizer both assign the same decision, you measure a mixed policy. Neither control group answers a clean question. Give one system each decision point.

Myopic choice is a limit, not a bug

The policy optimizes each decision against its declared reward. It does not model your full funnel, inventory, or long-term relationship as a single planning problem.

That limit is intentional when the rest of the world is a black box. Poon et al. (2025) make a related argument in a different domain: when future context cannot be modeled cleanly, myopic contextual decisions remain a tractable and sound approach. Lifecycle marketing has the same structure. You rarely have a faithful simulator of every downstream step. You do have a repeatable choice and a measurable result.

Myopic also means the method will not solve every pacing or long-horizon question by itself. Including nothing lets the policy learn when waiting beats acting for the declared reward window. It does not by itself set optimal weekly frequency across many overlapping campaigns, or automatically discount old creative when tastes change. Action learning currently keeps full history; only timing uses a shorter window. There is no automatic response to seasonality or creative wear-out yet. Work such as Fiandri, Metelli, and Trovò (2024) on sliding-window Thompson sampling is on the follow-up list for non-stationary rewards, not a claim about the live product.

Greenewald, Tewari, Murphy, and Klasnja (2017) separate a no-action baseline from an intervention effect, and show why repeated clock-tick act-or-wait choices are a different problem from assigning one future action time. BanditBuzz’s push loop uses cooldown as the pacing contract and learns timing inside allowed windows. It does not reconsider a person at every clock tick.

How BanditBuzz implements this definition

The public surface stays small on purpose.

  • Pull: POST /decide picks and logs an option for a person who is present.
  • Record: POST /events records what a person did, with any identifiers you have at that moment.
  • Push: one declaration adds eligibility, cooldown, destination, and optional local-time limits.
  • Scoreboard: per-option counts, lift versus the stable holdout, and for push the considered / acted / skipped view.

The standard tier is free and context-free. The paid contextual tier uses the same API shapes and a compact per-person context when available. BanditBuzz replays the paid policy on the free decision log using the doubly robust approach of Dudík, Langford, and Li (2011). The preview becomes ready only after its evidence and overlap checks pass. Its running 95% range helps a buyer judge the estimate, but checkout does not yet enforce a positive lower bound. Missing context, holdout, and standard fallback remain free.

Treat /decide as a remote dependency. BanditBuzz has not published load-tested latency percentiles, an SLA, a rate limit, or a tested maximum option count. Do not put checkout or login behind the call without a client deadline and a local default. Send an idempotency_key on decide and events so retries do not double-log.

Other current limits matter for planning:

  • Different decision points assign holdout independently. The product does not yet stop one person from entering two points, receiving two actions, or affecting both scoreboards.
  • There is no multi-touch credit, reward reversal, traffic floor or ceiling, or pinned option.
  • Buyer surfaces do not yet offer a full decision, propensity, context, and reward export for external retraining.
  • Team roles, scoped keys, change audit logs, and formal compliance packages (data residency commitments, DPA, SOC 2) are not shipped yet.

Those gaps are listed because a sound next-best-action definition includes what the system refuses to pretend to own.

When this framing helps, and when it does not

Use this framing when you have approved actions, a clear business result, and a place where the same choice repeats. Win-back offers, save scripts, catalog drops, and “email versus SMS versus wait” decisions fit. The learner earns its keep when organic conversion under nothing is a real alternative, and when the reward arrives outside the channel that performed the action.

Do not force every marketing problem into this shape. Brand campaigns with no per-person action set, one-shot compliance sends, creative exploration that has not been approved, and paid-media auction strategy are different jobs. So is asking a language model to explore treatments without a statistical policy; that is a separate failure mode from the decision layer described here.

“Next best action” should mean one bounded choice you already allow, scored on one result you already trust, with a control group you did not have to design by hand. Strategy, content, consent, and execution stay with you. The learner owns the pick. That is the whole job.