1000x an idea

MEMO

TO: Marcus Webb, CEO; Executive Team FROM: Staff Product Manager DATE: October 24, 2023 SUBJECT: Strategy, Sizing, and Execution: The Labor Network & Tip-Out Engine

---

Executive Summary

Kenji’s beta did not just build a utility that saves managers 25 minutes; it accidentally uncovered our most powerful growth loop.

In 90 days, 300 beta restaurants generated 57 closed-won new restaurant deals driven entirely by workers asking their other employers to adopt Tally. That represents 15% of our total quarterly adds, closed in 9 days (vs. our 41-day baseline) at one-third of our typical CAC.

We should not dilute our resources building a horizontal AI operating system. Instead, we should pursue the Worker-Led Distribution Loop. By unifying worker identities and monetizing daily earned tip liquidity, we transform Tally from back-office SaaS into the dominant two-sided labor and financial network for the restaurant industry.

---

1. The Mechanism and the One Dimension

The Mechanism: Cross-Employer Worker Virality. 41% of restaurant staff work at more than one restaurant, and 29% have already pitched Tally to their other manager. Restaurant labor is not stationary; it is an interconnected, multi-tenant network. When Tally provides workers with transparency and immediate utility, workers pull Tally into non-Tally restaurants.

The One Dimension to Push: Worker Liquidity & Engagement Velocity. Workers do not advocate for scheduling software; they advocate for their money. Beta WAU jumped from 34% to 81% because workers opened the app at close to see their tips. If we pair same-night earnings visibility with instant earned payouts, Tally shifts from a passive schedule viewer into an indispensable daily financial lifeline. This creates an intense worker preference that Crewbook’s commodity payroll bundle cannot match.

---

2. The Ambitious Version & Sizing the Opportunity

#### The Vision: The Portable Hospitality Passport & Financial Network Instead of restaurant-siloed accounts, Tally issues a portable Tally Profile & Wallet. * For Workers: A single app to manage shifts across multiple employers, access earned tips instantly at clock-out, and carry validated work history across jobs. * For Operators: Automated, compliant tip pooling, faster shift-filling from a verified labor pool, and automated close-of-day payouts without cash handling. * For Tally: Zero-CAC customer acquisition driven by workers, monetized via both high-margin fintech transaction fees and resilient core SaaS ARR.

#### Sizing the Opportunity (Range)

We model the incremental annual revenue opportunity over the next 12–24 months across two engines:

At network maturity (30,000+ restaurants connected via worker mobility), this labor-fintech network alone represents a $50M–$80M ARR business, creating a structural moat no standard payroll provider can cross.

---

3. The Sequence: Two Squads, Stage Gates, and Kill Criteria

We have 2 squads for next quarter. Rather than pursuing wage advances that require 9–12 month regulatory licenses, we immediately monetize earned tips same-night ($0.99 fee / $0.60 Tally net) via our current payments partner with zero licensing hurdles.

``` QUARTER 1 QUARTER 2 +-----------------------+ +--------------------------+ | Squad 1: | | Squad 1: | | Unified Worker ID | | "Bring Tally" Virality | | (Tally Passport) | | In-app manager pitch kit | +-----------+-----------+ +-------------+------------+ | | | ===> [GATE 1: Identity & Volume] ===> | ===> [GATE 2: CAC & Conversion] | | +-----------+-----------+ +-------------+------------+ | Squad 2: | | Squad 2: | | Earned Instant Tip | | Multi-Employer Shift & | | Payouts ($0.60 net) | | Consolidated Payout Hub | +-----------------------+ +--------------------------+ ```

#### Quarter 1: Foundation & Monetization * Squad 1 (Worker Identity): Build the account-linking architecture to allow workers to merge multiple restaurant profiles into one consent-based Tally ID (estimated at 1 squad-quarter). * Squad 2 (Instant Tip Payouts): Build the payment rails with our current partner for instant end-of-shift earned tip transfers ($0.99 fee; $0.60 net to Tally).

Gate 1 (To proceed to Q2 expansion): 1. $\ge 20\%$ adoption of linked accounts among multi-job workers within 45 days of availability. 2. $\ge 25\%$ opt-in for instant tip payout at close among eligible beta workers.

#### Quarter 2: Network Growth Loops * Squad 1 (Virality & Referral Rails): Build native worker-to-manager referral tooling (“Add my other restaurant to see my unified schedule and pay me instantly”), complete with an automated lead routing hook to sales. * Squad 2 (Multi-Employer Experience): Deliver a unified calendar and consolidated multi-job earnings hub for workers.

Gate 2 (To scale go-to-market): 1. Worker-sourced leads convert at $\ge 25\%$ with a sales cycle under 15 days. 2. Blended CAC for worker-sourced leads remains $\le 40\%$ of standard outbound CAC.

#### Kill Criteria (When to Stop) We halt the standalone network strategy and fold tip-pooling back into a baseline retention feature if: * Adoption fails: Fewer than 12% of workers use instant tip payouts after 60 days of GA, indicating that tip liquidity is not a strong enough engagement trigger. * Network loop collapses: Fewer than 2% of multi-job workers trigger an invite to their second restaurant, indicating the 57 beta conversions were an unrepeatable anomaly rather than a scalable loop.

---

4. What to Do with Marcus’s Idea

Marcus’s Proposal: Build an "AI Operating System for Restaurants" spanning inventory, menu pricing, reservations, and marketing.

Recommendation: Shelve this immediately.

1. It attacks entrenched, well-capitalized specialists: Entering reservations (OpenTable/Resy), inventory (Toast/MarginEdge), and marketing turns every partner in the ecosystem into an enemy. We do not have the balance sheet or vertical domain expertise to out-execute all of them at once.
2. It fails to solve our primary commercial vulnerability: Crewbook is taking 11% of our deals on price by commoditizing payroll and scheduling. Building predictive menu pricing does not insulate our core payroll business from pricing pressure.
3. It ignores our proprietary advantage: Our unique asset is the 190,000 workers already using our app daily. Toast and Crewbook own the restaurant contract; we have the opportunity to own the workforce.

The Pivot to Marcus: We share Marcus's ambition to reach a $1B valuation, but the right wedge is not horizontal ops software—it is labor network liquidity. If we own scheduling, tip distribution, and the worker’s financial wallet across employers, we control the restaurant industry’s single largest operating cost (labor). Once we establish this two-sided network moat, we can deploy labor-focused AI (e.g., dynamic shift-pricing and automated staffing forecasts) from an unassailable market position.

To: Marcus Webb and the executive team From: Staff Product Subject: The 1000x bet is a worker-led network, not a broader restaurant suite

Recommendation

Make Tally the portable home for restaurant workers’ shifts, tips, and earned-tip payouts—and use workers’ movement between jobs to distribute Tally to restaurants.

The mechanism in our data is cross-employer distribution: a useful nightly tip experience gives workers a reason to return, and workers carry that experience to another employer. I would push one dimension: the number of workplaces reached by each active worker, not the number of owner workflows we cover.

The calculator saves managers 25 minutes a night. That is a good feature. The potentially much larger business is underneath it:

• Worker-app weekly activity rose from 34% to 81%.
• 41% of beta workers also work at another restaurant.
• 57 restaurants signed after a worker asked them to adopt Tally.
• Those deals closed in nine days versus our usual 41, with roughly one-third the sales spend.

This is evidence of a distribution advantage, not yet proof of a compounding network. The beta restaurants volunteered, and we have no control group.

The most ambitious version

A worker has one consent-linked Tally identity across jobs. At close, they see a trustworthy breakdown of tips they have earned and can receive those tips that night. When another workplace is missing, they can ask its manager to join. The manager gets a compliant tip-pool workflow and a fast path into Tally scheduling and payroll.

Over time, Tally becomes the worker-demanded infrastructure for restaurant pay. Each restaurant adds workers; some workers connect another restaurant; those restaurants add more workers. We win distribution and engagement without needing to subsidize a sprawling suite.

This also gives us a differentiated response to Crewbook’s free scheduling. We should test whether worker demand and trusted tip handling change buying decisions—not assume they eliminate price sensitivity.

We should not include advances in this vision’s first stages. Earned-tip payouts are available through our partner without a licence. Advances introduce a nine-to-twelve-month regulatory dependency in key states without evidence that they strengthen this mechanism.

Opportunity range

Two sensitivities establish the scale; neither is a forecast.

Restaurant acquisition. The beta produced 57 worker-requested signups per 300 participating restaurants in one quarter. At today’s 6,400-restaurant footprint, reproducing 25%–100% of that observed rate would generate approximately 304–1,216 signups per quarter. At our current average ARR of roughly $4,844 per restaurant, that represents $6M–$24M of annual new ARR bookings.

The 25% case is a planning haircut, not an observed result. These signups may overlap with normal acquisition; saturation, duplicate requests, churn, and restaurant eligibility could materially reduce the outcome. For context, we currently sign 380 restaurants per quarter.

Payout revenue. Across today’s 190,000 workers, a sensitivity of 10%–44% adoption and one to five payouts weekly yields approximately $0.6M–$13M in annual Tally payout revenue, at $0.60 per payout, before our operating costs. Ten percent is an illustrative adoption assumption; 44% is stated willingness in a selected beta survey, not demonstrated paid demand. Eligible tipped workers, funding readiness, and actual frequency remain unknown.

Do not add these figures into a single ARR claim: one is new subscription bookings; the other is annual transaction revenue. The pack supports a potentially substantial expansion engine. It does not establish a $1B outcome or a literal 1000x multiplier.

Work backward: prove the loop before scaling it

The thresholds below are proposed decision rules, not facts from the beta.

1. Next quarter: build identity and measure distribution

Squad one: Build consent-based account linking into a single worker identity, including account recovery and clear employer-data boundaries. A restaurant must not gain access to another employer’s records.

Squad two: Productize and instrument the existing tip experience, then build a lightweight worker-request-to-manager-onboarding flow. Run a randomized invitation test within eligible restaurants, tracking requests through signed, activated restaurants. Instrument finalized earned tips and partner readiness in parallel.

Start experimentation with existing accounts; do not wait for identity linking to finish. Use linked identities to improve deduplication and measure the cross-workplace path.

Gate to the next stage: Linked records are accurate; workers understand consent; the nightly tip experience remains reliable; and the invitation test shows incremental activated restaurants, not merely clicks or attributed leads. Target at least a 25% lift over control, with acquisition cost below our normal channel.

2. Then: test paid earned-tip payouts

With identity shipped, one squad builds the partner payout integration; the other improves worker-led restaurant onboarding and expands the controlled acquisition test.

Offer payouts only against finalized, earned, fundable tips. Make the $0.99 fee explicit and the ordinary payment route clear. Compliance must approve the flow, including tip-pool rules and fee treatment.

Gate to broader rollout: Actual paid use—not survey intent—supports positive contribution economics. Set an initial target of at least 10% monthly adoption among eligible workers, with repeat use across two months. Require reconciled payouts, acceptable support burden, and no deterioration in trust or employer adoption.

Payout failure should stop that monetization path, not automatically kill a working distribution loop.

3. Finally: expand the network

Roll out restaurant-by-restaurant and state-by-state only after controlled evidence survives beyond volunteer beta customers. Invest in worker-led onboarding before adding unrelated owner software.

Stop condition: If two adequately powered invitation tests show no incremental restaurant activation, or incremental acquisition costs are no better than normal sales, stop the network expansion thesis. Keep the calculator as a useful retention feature; do not fund a platform story around it. Wrong-person linking, unlawful pooling, or unreliable payouts triggers an immediate pause in the affected flow.

What to do with Marcus’s idea

Keep the ambition; decline the roadmap.

“AI operating system for restaurants” names a destination but does not explain why we win. Inventory, reservations, marketing, and menu pricing would spend both squads across new markets while leaving our strongest observed mechanism undeveloped.

Ask Marcus to sponsor the worker-network bet and its explicit gates. AI can later improve a proven workflow where it demonstrably adds value. It should not substitute for proving our distribution advantage.