# Owner "Regulars" — concept prototype **Built by Corey Brown · August 2026** **For:** Owner.com, Principal Product Manager, Guest Retention application **Live prototype:** https://coreywbrown.com/lab/owner-regulars/ **Status:** Unlisted concept. Not affiliated with or endorsed by Owner.com. Guests, orders, campaign results, and figures are simulated. Where this describes Owner's current product, it describes what their public pages show; the internal product may go further. --- ## Why this exists The role owns Owner's lifecycle marketing and loyalty platforms, with one stated job: increase guest retention and order frequency by turning one-time guests into regulars. I had already built one Owner concept (Margin Manager, for the RestX application), so this one had to earn its place by aiming at this seat's actual thesis rather than repeating the last one. Show, don't tell, again. ## The problem Owner's marketing suite is genuinely strong, and it is organized around the calendar. The campaigns its public pages describe fire on occasions and session events: Mother's Day, the Super Bowl, an abandoned cart. Loyalty is a points ledger guests accrue against. What nothing fires on is the thing the role is named for: where a guest sits in their own journey from first order to regular. A restaurant can run every campaign in the library and still never send the one message that decides whether a first-timer ever comes back. And the operator can't see the problem either. Every published result is sales growth or list growth. No surface says "here is how many of your guests return, and here is the number this product moves." ## The insight Three, stacked: - **The unit of retention marketing is the guest stage, not the occasion.** First-timer, second visit, building, regular, slipping. Each stage has one campaign that makes sense for it, and two of the five (building, regulars) are best served by no campaign at all. Restraint is part of the product. - **The stages must be learned per restaurant.** A cafe's regular orders every 11 days; a special-occasion room's every 74. A platform-wide "3 orders in 90 days" misclassifies most of 20,000 restaurants and mistimes every campaign built on it. - **Points, not discounts, are the natural campaign currency.** A discount is margin off the top of a visit, paid whether or not it changed anything, and it teaches guests to wait for coupons. Bonus points cost nothing unless the guest actually returns, and redeeming them takes another visit. The reward is the next order. ## The solution **Regulars**, an operator surface with one working object: a stage selector driving one explicit campaign per stage. - **The stage strip** shows the whole base (542 active guests of 1,847 reachable members), each stage's count and movement, and which stages have a campaign awaiting review. - **The campaign panel** reads like a calendar invite: when it sends, who gets it (with the exclusions listed, from the open complaint flagged for a personal reply to the guest who opted out), which channels, and what the offer is, with a points-versus-discount toggle that shows the cost difference. The exact message renders alongside, one message per cohort with only merge fields varying, checked against a sample of real order histories rather than personalized into per-guest variants. - **A campaign agent** sits inside the panel as its edit mode: suggestion chips actually adjust the campaign (move the send, narrow the audience, change the reward), question chips answer ("why points and not a discount?"), and free text shows where conversational adjustment would live in the full product. - **Results is a campaign history with verdicts**: every campaign measured against a random holdout, cost per regular created, a rerun button on winners, and a retired 10%-off blast kept visible because showing what didn't work is what makes the numbers trustworthy. ## Why it maps to the role The JD's bullets are this surface's sections. "Automated campaigns and loyalty mechanics that turn one-time guests into regulars" is the stage model and the per-stage mechanics. "Personalize at scale while each restaurant's brand shines" is one campaign per cohort in the restaurant's own voice, not 20,000 restaurants sharing a template. "Rigorous incrementality testing and attribution, ensuring customers can see and trust the value" is the holdout in every projection and the results table's honest verdicts. ## How it was built - A single self-contained HTML/CSS/JS file, no framework, no backend, styled to read as the same operator app as my earlier Margin Manager concept. - Grounded in Owner's public product: I worked through their loyalty-rewards and automatic-marketing pages to map what campaigns exist today, what triggers them, and what the loyalty program does, and aimed the concept at the space between them. - Iterated through three review rounds against one consistent bar: it should read as a tool an operator uses, not a strategy deck. The ladder became a selector, per-guest message variants became one campaign checked against a sample, and the strategy prose became product states like "No campaign scheduled," with the reason. ## What I would do next with real data - Learn each restaurant's actual stage thresholds from its order history, and validate the second-visit window that the flagship campaign depends on. - Wire projections to measured baselines (how many first-timers return with no campaign) instead of representative numbers, and let the holdouts accumulate into per-restaurant lift curves. - Test points against discounts head-to-head on cost per incremental regular, the number this product should be judged on. - Make the campaign agent real: campaign adjustments as a conversation, with every change still landing in the same reviewable invite before anything sends.