Bay queue · today

v1 needs none of this screen: the tech sees the customer's green screen and keys NEW5 (or BACK1) into the POS. This view is v1.5, for when you want the verified email in big type so the tech can enter it into the POS without reading it off a customer's phone.

Today · Store 1977

Counts update live as you run the customer flow. Seeded with a sample morning so the numbers aren't zero.

Funnel

Cars = POS tickets (from the nightly report). Everything else comes from the capture service.

Bad data stopped at the door

Each of these would have landed in the franchisor's CRM as a record that looks fine and bounces on first send.

Nightly reconcile · yesterday

The POS report is scraped nightly (same browser-bot pattern as the ad-platform pulls). Each POS email is matched against the verified capture for the same bay and time window.

14 tickets with an email, 11 clean, 2 tech typos, 1 placeholder. Fix list goes to the store manager each morning.

What a one-week pilot proves

• Capture rate: verified emails as a share of cars. Baseline today is unknown; the franchisor says half of what's captured is bad.
• Where bad data comes from: typos fixed vs fakes blocked vs undeliverable vs abandoned at the code step.
• Tech time: seconds per car spent on email. Target is zero.
• Entry path mix: QR vs NFC vs typed, so you know whether the NFC sticker earns its place.
• Discount cost: $5 per verified first-timer. At 20 cars a day that is about $100 a day if everyone takes it.

What six months proves: the franchisor's 3.5x lifetime revenue claim. Compare return rate of the verified cohort against the pre-pilot cohort, same store, same season.

How it fits together

Solid teal boxes are the franchisee's own. Dashed boxes are systems he doesn't control.

1. 1
   Bay card
   Printed QR + NFC sticker + short URL. Encodes store and bay. Cost: about $1 per card, laminated.
2. 2
   Customer's phone, plain web page
   No app. Customer types their own email. The tech never touches it. This alone removes the fat-finger and "didn't hear it" half of the bad data.
3. 3
   Capture service: 7 validation layers
   Syntax, typo repair, placeholder patterns, disposable domains, role inboxes, deliverability API, then proof of receipt. Details below.
4. 4
   Email provider sends the code
   Transactional send (Postmark, Resend, SES). Subject line carries the code so it shows in the notification without opening.
5. 5
   Customer enters the code (or taps the link)
   Proof they can open that inbox today. A deliverable address that isn't theirs fails here.
6. 6
   Green screen with a POS coupon code
   NEW5 for first-timers, BACK1 for returning. The customer shows it, the tech keys it. Existing POS, existing coupon report, no new tech-side software.
7. 7
   POS (Auto Data / PosiLube) records the coupon and the email
   Tech still types the email into the POS today. The nightly reconcile catches typos against the verified copy.
8. 8
   Nightly browser bot scrapes the POS reports
   Tickets, coupons, car counts, by store and day. Runs on the office Mac at midnight, same pattern as the ad-platform pulls.
9. 9
   Franchisee-owned database
   Capture events + POS scrape + launch media plans + external (traffic, weather, promo calendar). One place an agent can be pointed at. Survives the POS and CRM migrations.
10. 10
    Franchisor CRM (Driven)
    Downstream consumer. Receives verified emails only, through the POS as today. Nothing unverified ever reaches it.

Validation layers

Layer 6 is simulated in this prototype. Swap in a real API key for the pilot.

QR vs NFC vs typed

What gets stored, and where

Capture service (franchisee)

• Email (normalized), first name, optional mobile + SMS consent timestamp and the exact consent text shown
• Store, bay, entry path (qr / nfc / url), timestamps for started, code sent, verified, redeemed
• Validation log: which layers ran, what was fixed or blocked
• Returning flag (hash match against prior verified captures)

Not collected

• License plate, VIN, photos. Oregon is strict on plate capture and the pilot doesn't need it. The POS already has vehicle data.

To the franchisor

• Verified email only, entered into the POS as today. Open question whether the franchisee may keep his own copy under the franchise agreement. Minimum defensible record: a hash + consent + verification timestamps.

One-store pilot, one week

Day 0 setup

• Create two coupon codes in the POS: NEW5 ($5, first-timer) and BACK1 ($1, returning)
• Print and laminate 4 bay cards (2 bays, 1 spare each). Add NFC stickers to 2 of them to measure uptake
• Deploy the capture page on a short domain the franchisee owns. Sending domain with SPF/DKIM so codes land in the inbox, not spam
• Email verification API in sandbox, then live (free tiers cover a pilot week)
• Two-line script for techs: "Scan the card for $5 off, then show me the green screen"

Days 1 to 7

• Run every car. Nightly scrape of the POS coupon and ticket reports
• Morning fix list for the manager: tech typos and placeholders from the reconcile

Decide on

• Capture rate above 60% of cars, abandonment at the code step under 15%, tech time per car near zero, zero unverified records entered

Build estimate

One page app, a small database, two API integrations (email send, email verify). A few hours to a working v1, a couple of days to something a store can run unattended. Running cost in the low tens of dollars a month plus about a cent per verification. [moderate confidence on cost]

Open questions before the pilot

• Franchise agreement: does the franchisee keep a copy of the verified email, or only the verification record? A question for his franchise counsel, not a design decision.
• Brand use: the card and the page carry the store name. Whether they can carry the franchisor's logo needs a yes from them.
• Getting emails into the POS: the tech types it today. A keystroke bot could enter verified emails nightly, but automating entry into the franchisor's system needs their blessing.
• SMS: marketing texts need express written consent. Email-only for week one keeps the pilot simple.
• POS migration: corporate stores first, franchise stores after. The capture service sits outside the POS on purpose so the migration doesn't touch it.