Wallet Intelligence & Holder Broadcast

Once people start saving your card to Apple Wallet and Google Wallet, you own something most digital business cards never give you: a list of phones that carry your card in their pocket. Wallet Intelligence is the dashboard at Wallet (/user/wallet) that turns those saves into real numbers — how many people hold your pass, how many removed it, how engagement moves week over week, and which platform they're on. It is the analytics half of the wallet feature; the next blocks cover it field by field.

Holder Broadcast is the action half, and it is the part competitors don't have. With one short message you push a lock-screen notification to every phone that saved your card — your weekend offer, a new location, an event reminder. On iPhone it appears as a lock-screen notice plus an "Updates" row on the back of the pass; on Android it attaches a message to the Google pass. It is the single most direct re-engagement channel ScaanMe gives you, because these people already chose to keep your card.

Who is this for? Any owner whose card is being saved — but it pays off most for businesses with a reason to come back: salons, clinics, restaurants, real-estate agents, retailers. Why it matters: a saved pass is a permanent, free channel that auto-syncs (edit the card and every pass updates itself), and Holder Broadcast is how you light that channel up. Analytics tell you who's listening; broadcast is how you speak to them. Note that Holder Broadcast is a premium feature gated by the `wallet_broadcast` plan flag — if you don't see the Broadcast button, it isn't on your plan yet.

What & why: the dashboard opens on the Pocket audience hero — the single most important number in the whole feature. It is the count of phones that *currently* hold your pass, computed as saves minus removals per platform, summed. Think of it as your owned, re-engageable audience: every broadcast and every pass update reaches exactly these people. Everything else on the page exists to explain how that number is moving and why.

Read the hero left-to-right. Under the big number is the platform split (Apple icon · Google icon) so you know whether your audience skews iPhone or Android, plus ":r% of taps become saves" — your save rate, how often a "Save" tap actually finishes. To the right, the green growth curve plots cumulative audience over the selected window with a from–to date axis; hover any point to read the exact value on that day. This curve climbing is the health signal you want.

Next to the curve sit three live metrics. Wallet opens = visits that arrived because someone tapped the QR/link on a saved pass in this period (with an up/down delta vs the previous period). Repeat openers = people who opened the pass more than once — proof your card is being *used*, not just stored. Identified holders = holders the CRM matched to a real contact; this is your warm list, the people you can name and follow up with. A high identified-holders number is gold: it means anonymous saves are becoming known relationships.

Two controls in the top-right reshape every number on the page. The window selector offers Last 7 / 14 / 30 / 90 days — every metric, delta and sparkline recomputes against the window you pick *and* its matching previous window (that's how the "↑ 23%" deltas are honest period-over-period comparisons). The platform filter (All · Apple · Google) lets you view the whole picture or isolate one wallet. Use 7 days to spot a broadcast's immediate effect, 90 days to judge a real trend; switch to Apple-only or Google-only when you want to see which audience is actually growing.

Below the hero is the KPI strip — four cards, each scoped to your chosen window with a colored area chart and a delta chip. Saved to Wallet (blue) = completed saves. Wallet scans (violet) = times someone scanned/tapped a saved pass to open your card. Save taps (green) = how many people tapped "Save" (compare to Saved to see drop-off). Removed (red) = passes deleted — a low number is normal; a spike right after a broadcast is the one warning sign to watch. Each card shows the current-window count, an all-time total, and in the All view a per-platform Apple·Google split at the bottom.

The Wallet Intelligence band under the KPIs gives four at-a-glance health tiles. Active passes shows how many of your cards are actually live in wallets (with a percentage ring). Top performer names your most-engaged card this window. Top traffic source shows where your card visits come from. Needs attention flags "passes gone quiet" — passes that were issued and once had engagement but have seen nothing for 7 days; tapping it filters the card list so you can revive them (a broadcast is often the fix). Finally, the hero shows next-best-action prompts in pill form — concrete nudges like "N holders aren't identified contacts yet" drawn from your real state.

What & why: a broadcast is a single short message delivered to everyone holding a specific card's pass. Each card broadcasts independently, so you reach exactly the audience that saved *that* card — not your whole customer base. The mechanism is honest and split by platform: on Google the message is attached to the live pass via the documented addMessage API and shows when the pass is opened; on Apple, because Apple allows no free-text pushes, your message is stamped onto the pass so it surfaces as a lock-screen notice plus an "Updates" row on the back of the pass at the device's next sync. Below is the exact flow.

Step 1 — open the composer. From the Wallet dashboard, find the card you want to message in the card list and tap its Broadcast button (the spark icon, shown only when your plan includes wallet_broadcast). This opens the "Broadcast to holders" screen for that one card. The page header repeats the card name and ":n holders right now" with the live Apple·Google split, so you know exactly how many devices this message will reach before you write a word.

Step 2 — write the message. The single field is "Your message", a textarea with placeholder *"Short, useful, worth a notification…"* and a live character counter. The message must be between 5 and 160 characters (the cap is body_max, default 160). Treat it like a notification, because that's what it becomes: lead with the value, be specific, give a reason to open. Good — *"Weekend offer — 20% off all services, Fri–Sat only."* Weak — *"Hello from us!"*. There is no separate subject line; on Google the card's title is used as the header automatically.

Step 3 — confirm and send. Tap "Send broadcast". A confirmation dialog asks "Send to all holders now?" — this is deliberate friction because a broadcast is irreversible; you cannot un-send a notification. On confirm, ScaanMe logs the broadcast, stamps the Apple pass and queues an APNs poke to every registered iPhone, and calls Google's addMessage on the live object. The screen also shows your usage right now — "Today :u/:d · This week :w/:m" — so you can see how many sends you have left before you ever hit a limit.

Step 4 — read the results. Under the composer, "Past broadcasts" lists your last 20 sends. Each row shows the message text, a status pill — `sent` (everything delivered), `partial` (one platform failed), or `failed` — and a line with the timestamp, the audience at send, and the per-platform tallies (e.g. *Apple 12 · Google 8*, with a ✗ count if any failed). This is your delivery ledger: it confirms reach, flags platform issues, and is where you'd notice if a send underperformed. If you've never sent one, the empty state reminds you why it matters: "Your first message lands on every phone that saved this card."

What & why: broadcasting is powerful, so ScaanMe enforces guardrails that stop you from burning the audience you worked to build. These aren't arbitrary — every extra notification raises the odds someone deletes the pass, and a deleted pass is gone for good. The composer shows your live usage and quietly blocks a send the moment you'd cross a line, replacing the form with the exact reason. The defaults below are the standard ceilings; higher tiers can raise them via plan settings.

The four hard limits are: 1 broadcast per card per day, 4 per card per week, a 60-minute cooldown between any two sends, and a 5–160 character message length. If you hit one, the send button is replaced by a plain message telling you which limit and when you can send again — *"Daily limit reached (1 per day)"*, *"Weekly limit reached (4 per week)"*, or *":m more minutes before the next broadcast"* with a live countdown. There is also a global kill-switch an admin can flip; if broadcasts are paused platform-wide you'll see *"Broadcasts are temporarily paused."*

The smartest guardrail is the removal-spike advisor. After any broadcast, ScaanMe watches removals for the next 24 hours; if more than ~2% of that broadcast's audience deleted their pass, the next time you open the composer an amber banner warns you — *"Heads up: your last broadcast was followed by N removal(s) within 24h. Consider a softer message or lower frequency."* This is your early-warning system that a message landed badly. If you see it, slow down and rethink the content before sending again.

Two edge cases worth knowing. First, the audience is counted at send time, not when you opened the page — Apple reach = currently registered iPhones, Google reach = net saves (saved minus removed). Someone who saves your pass a minute after you send simply won't get *that* message; they'll get the next one. Second, delivery isn't instant on iPhone: Apple pushes are a *background poke* that tells the device to re-pull the pass, so a holder's lock-screen notice appears on their next sync, not the same second. Google's message attaches immediately to the live pass. Both are normal and by design.

Send rarely, send well. The limits cap you at 1/day and 4/week, but the *right* cadence for most businesses is far lower — roughly 2–4 broadcasts a month. Every message you send trains holders to expect value; every filler message trains them to delete. Reserve broadcasts for things that are genuinely worth a notification: a real offer, a new location, an event, a seasonal reminder. If you wouldn't be glad to receive it, don't send it.

Front-load the value in the first few words. A lock-screen notice is glanceable — many holders read only the opening before deciding whether to open. Put the offer, the number, or the date first: *"20% off this weekend…"* beats *"We're excited to let you know that this weekend…"*. Stay well under 160 characters; tight messages read better as notifications and survive truncation on small screens.

Watch the Removed KPI for 24–48h after every send. A small, steady removal rate is normal. A *spike* right after a broadcast — and especially the amber removal-spike advisor banner — means the message or the frequency was off. Treat that banner as a real signal: lengthen the gap to your next send and make the next message softer and clearly useful.

Turn anonymous holders into named contacts. Watch the Identified holders number and the next-best-action prompt about unidentified holders. Holders the CRM has matched are your warm list — you can follow up personally, not just broadcast. The faster anonymous saves become identified contacts, the more your wallet audience becomes a real relationship channel rather than a one-way megaphone.

Remember the pass auto-syncs — sometimes you don't need a broadcast at all. If your phone number, hours, or address changed, just edit the card; every saved pass updates itself silently, no notification spent. Save broadcasts for things that *should* interrupt someone. And before a campaign, glance at the platform split: if you're 80% Android, your broadcast lands mostly as a Google pass message; if you skew iPhone, the lock-screen notice does the heavy lifting. Compose with your actual audience in mind.

Does a broadcast really show on the lock screen? On iPhone, yes — your message produces a lock-screen notice and adds an "Updates" row on the back of the pass, because that's the only mechanism Apple permits (there is no free-text push for passes). On Android, the message attaches to the Google pass and is visible when the holder opens it. We word the UI honestly about this difference so you always know what each platform's holders actually see.

Can I undo or recall a broadcast? No. A notification, once pushed, cannot be pulled back — which is exactly why the composer asks "Send to all holders now?" before it sends. Proofread the message and double-check the holder count in the header first. If you made a small mistake (say a wrong date), you can wait out the 60-minute cooldown and send a brief correction, but you'll have spent one of your daily/weekly sends.

Why is my audience number different from my total saves? Because Pocket audience is *net* — it's saves minus removals, counting only phones that *still* hold the pass. Your all-time "Saved to Wallet" KPI counts every save ever, including passes since deleted. The audience number is the one that matters for broadcasting, because it's exactly who a message will reach right now.

Do I broadcast to all my cards at once? No — broadcasts are per card. You open the Broadcast screen for one specific card and reach the people who saved *that* card. This is intentional: a salon's loyalty card and an event card have different audiences and different messages. If you run several cards, send to each one separately with content fit to its holders.

I don't see a Broadcast button — why? Holder Broadcast is a premium feature gated by the `wallet_broadcast` plan flag. If your plan doesn't include it, the Broadcast button simply won't appear on your card tiles, though you still get the full Wallet Intelligence dashboard. Upgrade your plan to unlock broadcasting; the per-day and per-week ceilings can also be raised on higher tiers.

Will broadcasting annoy people into deleting my pass? It can, if you overdo it — which is exactly why the guardrails (1/day, 4/week, 60-minute cooldown) and the removal-spike advisor exist. Used well — a few genuinely useful messages a month — broadcasts strengthen the relationship and keep your card top of mind. Used as spam, they cost you holders. Watch the Removed KPI, heed the amber advisor, and you'll keep your audience growing.

When you run several cards, the Wallet command center gives you a toolbar above the card list to zero in fast. The search box ("Search wallet cards…") filters live as you type, matching on each card's title and its public URL — no page reload. It's the quickest way to jump straight to one card in a long list.

Next to it, the status filter narrows the list to All status, Issued, or Not issued — handy for spotting cards that still need their first wallet pass generated. A small counter shows how many cards match out of your total, so you always know the filter is doing something.

The sort control reorders the list by what matters in the moment: Most active, Recently updated, Recently created, Most saved, Most scans, Most taps, or Name (A–Z). Combine the three — for example, search a brand name, filter to Issued, and sort by Most saved — to answer a question about your wallet program in seconds.

Each card tile carries its own quick-action row. Edit card opens the full card editor; Customize wallet opens the 3-room pass designer; Preview opens the live public card in a new tab; and Share copies the public link straight to your clipboard (with a "Copied!" confirmation). Analytics jumps to your CRM scoped to that exact card, so you can read its visitors and sources without losing your place.

Each tile also shows its issued state per platform with a coloured dot: an Active (green) pass means the pass has actually been generated, while Not issued (grey) means no one has saved it yet — generate it with the Add-to-Wallet button. When a Google pass is issued, hovering its badge reveals the issued-on date (the day the pass object was first created), a quiet record of when that card went live in the wallet.

A Delete pass button appears only once a pass is issued. Deleting removes the pass from everyone who saved it (the UI warns you before confirming), but you can always re-add it later — so treat it as "recall this pass", not a permanent erase.

The whole Wallet surface is plan-gated: it only appears when wallet is enabled and your plan carries the `google_wallet` flag. Beyond that, individual capabilities ride their own flags — `apple_wallet` for Apple passes, `wallet_luxury` for the premium luxury templates, and `wallet_broadcast` for Holder Broadcast. If a feature's flag isn't on your plan, its controls simply don't appear; this is honest gating, not a hidden setting you can flip yourself.

Even with the apple_wallet flag on, the Add to Apple Wallet button only shows once Apple Wallet is fully configured on the platform (the signing certificate is in place). Until then you may see an "Apple Wallet — soon" note — Google Wallet works today, and Apple lights up the moment its setup is complete, with no change needed on your side.

Right inside your dashboard there's a built-in Wallet setup guide — a dedicated page (at /user/wallet-guide) that walks you through how to issue, customize, share and track a wallet pass, with a live sample of a finished pass. It's the fastest on-ramp if you've never made a pass before, and it stays in sync with the actual buttons on your account.

On the command center itself, the small "?" (Explain this page) button launches an interactive tour that highlights each part in turn — the pass preview, the customize-wallet editor, the broadcast button and the pocket-audience metric — so you learn the layout by pointing rather than reading. Tap it any time you want a refresher on what a panel does.