Appointment Wallet Pass
One-line description. Auto-generated Google Wallet pass per FUB appointment so reminders land on the lock screen.
Why
Lock-screen reminders are the strongest "don't forget" mechanic that exists.
Calendar invites get buried. A wallet pass doesn't.
It's also a frame-control move. Most agents send a calendar invite. A pass shows up on the buyer's phone the morning of the meeting and updates on its own if anything reschedules.
That's the kind of touch other agents won't replicate.
Current state
Captured but not active.
This is an idea. The spec is written. No code.
I parked it because May 1 doesn't need it. Sales motion ships first on the basics. This is post-validation polish.
What pulls it forward: a real no-show pattern that calendar invites alone don't fix, or wanting a visible differentiator after the motion stabilizes.
- Status: planning
- Last update: 2026-04-26
- Blocked on: nothing. Held by priority.
Next 3 actions
(none — surface when relevant)
Decisions log
- Portfolio organization — vault README is the front door, every project gets a hub from the template
Locked at MVP (captured in idea-inbox doc, not yet promoted to a decision file):
- Google Wallet only. Apple is post-validation.
- New
pos-walletCloud Run service. Don't fold it into pos-fub. - Pattern A (one pass per appointment). Pattern B (persistent seller-journey pass) waits on
dim_lead. - Delivery via FUB email template. No new SMS dependency at MVP.
Open issues
- Decide: Google-only ($0/yr, 1-2 days build) vs Google + Apple ($99/yr, 3-4 days build)
- Confirm FUB Owner role still has the appointment-created webhook scope
- Scope the first pass type. In-home consult B is the obvious one. Closing day, inspection, walk-through, photoshoot, pre-list strategy follow.
References
- Idea-Inbox doc:
~/CCPJ/projects/Idea-Inbox/idea/2026-04-26-appointment-wallet-pass.md - Related: Custom Dialer, External API Platforms
- Code home (when built):
~/CCPJ/projects/pos-wallet/(new service)