Better Late Than Never — The Stoked Dispatch, May 2026

May 13, 2026 | Ricky Chilcott | 14 minutes | 2654 words

Welcome to the May edition of The Stoked Dispatch — fashionably late, you might say. The calendar says May, the last Dispatch said March, and in between were 47 productive days I’d argue were worth waiting for. Better late than never, never too late, and so on. Pick your idiom.

This round’s theme: handbooks that read like real documents, map filtering that feels like real product discovery, and a rewards system that actually protects your budget.

Let’s get into it.

Headline Features

Handbook 2.0 — Real Formatting, and Now in Your Advocates’ Portal Too

Most of you know the drill. A prospect lands on your community site, mostly convinced but not quite. They want to know what they’re signing up for: How does the program work? What’s expected? What do they get? Without a good answer to those questions, they bounce, and your CAC goes up by one.

The Handbook is the answer to those questions. We shipped the v1 a while back as a public-facing page; this month it grew up.

What’s new:

Rich text formatting. The handbook editor now supports H2 and H3 headings, bulleted and ordered lists, and tables. Tables in particular are a big deal — reward tiers, communication channels, response time expectations, the kinds of things that just don’t read well as a paragraph. Add a table, move on.
It’s in the advocate portal too. Previously, your handbook lived at a public URL. Useful for customers who love your product and are considering joining; less useful for the advocates already in your program who still need to know how it works. Logged-in advocates now see a Handbook link in their sidebar that takes them to the same content inside their portal — same body, no “Apply to join” button, just the orientation guide they actually need.
FAQs are now rich text. Same editor as the handbook, same headings/tables/lists. Long-form answers, multi-step instructions with screenshots — all of it now formats properly instead of being smashed into plain text. Bonus: the public handbook and the advocate-portal handbook both pull the Advocate FAQs from your Library at the bottom of the page. (Previously the public version pulled Prospect FAQs by mistake. Fixed.)
Table keyboard shortcuts. Insert/remove rows and columns the way you would in a spreadsheet. Took us two weeks longer than it should have. Worth it.

Why a DTC brand cares: A good handbook reduces two costs at once. Future advocates self-serve their questions before applying (you don’t spend a sales call on basics). Active advocates have an authoritative source for “how does this program work” without having to ask you. The advocates who have a handbook to point to tend to be the advocates who pick up program details fastest — they help carry the program instead of leaning on you to explain it.

Both views ship on every plan tier. Existing handbooks still look good; the new formatting tools just make them look even better next time you edit. KB: Handbook now lives in the advocate portal too, Handbooks now support headings, tables, and lists.

Site Filter Sets in the Map Embed

Here’s a scenario that comes up a lot. You’re a bike brand. You sell e-bikes, cargo bikes, gravel bikes, and road bikes, in five frame sizes, with three drivetrains. Your advocate roster reflects that — they’re tagged accordingly. So someone lands on your embedded map and… sees nothing useful, because there are 40 tags and no way to make sense of them.

When someone is in the market for a $4,000 bike, the difference between “browse a giant pile of advocates” and “find the cargo-bike owner in Portland with the kid trailer” is the difference between a closed tab and a booked conversation. Making that path obvious is what Site Filter Sets are for.

What it is: A filter set is a dropdown menu you define for your map. It groups related tags under a friendly, marketing-grade label.

Example. Instead of exposing tags gravel-pro, trail-master, and expedition-tested, you’d create a “Riding Style” filter set with an option labeled Adventure that internally matches those three tags. Visitors see “Adventure”; the engine resolves it to the right advocates.

The visitor experience:

Below the location search, one dropdown per filter set you’ve enabled
Pick an option → matching advocate pins stay bright, non-matching ones dim (but still clickable)
The advocate card list prioritizes matched advocates first, then fills with nearby ones
A “Filtered by” chip row at the top with a Clear button
Multiple filter sets stack — “Riding Style: Adventure” + “Experience: Verified” both apply

Configuration: Settings → Tags → Site Filter Sets. Each option supports a custom label, an icon, an 80-character description, and a per-option match mode (Any/All for how the underlying tags combine). Long dropdowns can use dividers to visually group related options — useful when you’ve got eight choices and want to separate “Bike Types” from “Use Cases” without scattering them across separate filter sets.

One thing to know. The old ?tags=foo,bar URL pattern is gone. If you’ve got marketing URLs out in the wild using that format, they’ll now load an unfiltered map (no redirect). Set up filter sets instead — they generate friendlier ?filter[riding-style]=adventure URLs that are easier to share and harder to break.

Why a DTC brand cares: You can finally show prospects a map that guides them to the right advocate instead of dumping the whole roster. Landing page for the cargo bike? Embed the map with the Cargo filter pre-applied. Email campaign for off-roaders? Adventure filter, locked. The map stops being a list and starts being product discovery.

Available on all tiers. KB: Map embed filter sets, Filter set dividers.

Rewards Get Sharper — Attribution, Inline Requests, and Real Guardrails

If you’re running an advocate rewards program, three things separate the programs that work from the programs that quietly drift into “where did all the points go?” territory: proof (you can see what the reward was for), easy requests (advocates can request without leaving their flow), and guardrails (the same work can’t get rewarded ten times by ten different rules).

This month we tightened all three.

1. Activities can now require a subject. When you set up an activity definition, you can declare what it has to be tied to — a specific conversation, a specific introduction — and the request can’t be submitted without it. (Activity definitions that don’t set a subject type still work like before.) Before, even reward-eligible activities could float on their own (“I had ten conversations this week”), and admins had to take it on faith. Now anything you mark with a subject points back to a concrete piece of work. If a wallet credit shows up, there’s a paper trail to the conversation that earned it.

2. Inline reward requests. When an advocate finishes helping a prospect inside a conversation, they don’t have to navigate away to a separate rewards page anymore. The conversation actions menu now shows Request Reward: [name] directly. For simple cases, it’s a confirmation dialog and done. For cases that need notes, it opens a pre-filled form. The work and the reward request happen in the same place, at the same time, while context is fresh.

3. Two new caps to protect your budget.

Per-subject cap. “How many times can this reward be claimed against the same conversation?” Default is 1. Prevents the same piece of work from being multi-rewarded across overlapping activity definitions.
Per-advocate rolling window. “Max claims per advocate in a [day / week / month / year].” Useful when you want a ceiling on how often a single advocate can claim against a definition — whether for budget control, to keep rewards distributed across the program, or to catch unusual patterns early.

Both default to no cap (so existing programs keep working exactly as they did) — set explicit limits when you’re ready. Configuration lives at Settings → Wallet Configurations → [your config] → Manage Activity Definitions → [definition] → Claim Limits.

4. Bonus polish. Admins can now Preview as Advocate from any wallet configuration to see exactly what advocates see — names, descriptions, badges, disabled tooltips, the whole rewards page. Canned response templates can now include {{ risk_waiver_signing_url }} (or whichever waiver you’ve configured) as a merge variable, so sending a waiver link is one click instead of one copy-paste. And we collapsed the approval-and-credit flow into a single atomic operation, fixing a quiet double-credit race that had been catching one or two real customers.

Why a DTC brand cares: A rewards program without guardrails quietly spends more than you’d expect. A program with attribution but no guardrails spends less, but you still can’t tell where the points went. A program with both — attribution and caps — is the only kind you can actually scale, because you can see what’s happening and put a ceiling on it before it runs away. This is the difference between rewards as a marketing experiment and rewards as operational infrastructure.

Available on all tiers. KB: Activities require a subject + inline reward request, Reward claim caps, Advocate rewards preview, Canned response waiver links.

Quick Hits

Prospect verification status and timezone, everywhere

Two related improvements, both in the same vein of “surface information admins already have, where they’re already looking.” Each prospect now shows a verification badge (Self-verified / Admin-verified / Unverified) on conversation cards, introduction cards, and detail pages — no more clicking through to find out. And each prospect’s local time (captured at sign-in) shows up next to their name in the inbox, so you know whether it’s 9am or 11pm where they are before you reply.

Inbox cards, redesigned

Conversation cards and introduction cards used to drift apart visually — different padding, different shortcut hints, different badge placements. They’re now built on a single shared shell with consistent hierarchy, the same keyboard shortcuts in the same positions, and clearer separation between prospect, message, and actions. Also added: message source (Web vs SMS) under each sent status, and color-coded role accents so advocates and prospects are visually distinct at a glance.

Photos that don’t get distorted

Profile photos got proper treatment: non-destructive in-app cropping (crop once, recrop later, the original is kept), GIF upload support (because some people have opinions about their portrait moving), and “Avatar” got renamed to Profile Photo everywhere because that’s what people actually call it.

Phone-first introduction UX

Starting a new introduction used to assume email-first. For a lot of you that’s backwards — phone is the primary channel. The introduction flow now leads with phone, with a clean search banner that pre-checks for existing prospects (and shows their verification status) before you draft a thing.

“No Tags” admin filter

Most admin index views support tag filters. They now include a No Tags option so you can quickly find the records that fell through tagging hygiene — useful for the “let me clean this up” mood.

Inline helper text on advocate profile fields

Advocates editing their profile sometimes ask “where does this show up?” Each profile edit field now carries a one-line hint underneath, explaining what it’s for and where it appears (public profile, admin-only, search). Less guessing, fewer surprises.

Empty states with icons across admin tables

The first time you visit Admin → Conversations on a brand-new community, you used to see a blank table with a “No conversations” line. It now gets a proper empty state with an icon and a short prompt. Same treatment on every admin index. Small thing; makes the product feel less unfinished when you’re getting set up.

Offline page auto-retries

If your network blips and the app drops to its offline page (PWA users), it now auto-retries with exponential backoff instead of waiting for you to mash refresh. You’ll usually be back on the page before you notice it left.

LinkedIn URLs now accept both individual and company profiles (used to be only individual, which was annoying for brand accounts). Threads.com URLs are also now recognized as Threads — previously they fell through. Both small, both requested.

“Year” response type for application + custom fields

When you’re asking “what year is your bike?” or “what year did you join?”, a Year response type beats a generic text field. Available wherever you configure questions — application forms and custom fields both.

Under the Hood

Six weeks is enough time for the infrastructure list to get long. We resolved 28 findings from a four-pass security audit spanning authentication, authorization, and data scoping. Twilio’s A2P 10DLC enforcement (the dreaded error 30896) prompted us to unbundle SMS consent from your Terms of Service and Privacy Policy agreement — required by carriers for compliant SMS, no admin action needed for existing users. We fixed two production reliability issues: a health check connection pool exhaustion that could cause cascading slowness under load, and an approval-flow race condition that occasionally double-credited wallets. We scoped our database performance dashboards to only watch our own database (so noisy-neighbor metrics stop polluting the signal). And we rebuilt the Knowledge Base on a faster platform — pages render quicker, search is sharper, and PageSpeed scores went from “fine” to “kinda smug.”

The throughline: catch the leaks before they reach customers, and when they do, fix them once with a system change instead of a patch.

Looking Back, Looking Forward

Six months of Dispatches. Here’s the arc, since I started tracking it:

In November, we gave you a dashboard that tells you something. In December, one inbox to rule them all. In January, we made your community site actually findable. In February, the power tools. In March, rewards, waivers, and canned responses that turned advocacy into a real program. And this month — handbooks that read like documents, filtering that feels like discovery, and a rewards system with actual guardrails.

The through-line hasn’t changed: we’re building Stoked into the operating system for brand advocacy. Every Dispatch, the distance between “I have some passionate customers” and “I have a systematic program that drives revenue without leaking budget” gets shorter.

What’s next? A few things landing in June:

Offers — branded post-conversation and post-meetup offers you can hand to prospective buyers once an advocate has spent time with them. Coupon-code delivery, click tracking, the whole “you talked to Sarah, here’s your discount” loop.
Wallet redemption requests for advocates, with an admin issue/deny flow so points turn into actual rewards without leaving the platform.
Featured advocates on the community map for the cases where you want a specific advocate (or two) to surface first.
A round of UX refinement on the canned-response and reward-request flows we touched in this release — the bones are right, now we sand them.
Tighter admin signal when SMS deliveries fail, and a refresh on community-controlled close reasons and advocate-deactivation reasons.

June should also put us back on a more predictable cadence.

As always — feedback, feature requests, or genuine human commiseration about shipping cadence? stoked-help@stokedhq.com.

More from The Stoked Dispatch:

More from the Stoked blog: