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.

MEMO To: Marcus Webb and the exec team From: Staff PM, Product Re: The 1000x version of the tip-out calculator, and what to build next quarter

---

1. The mechanism: our workers are a sales channel

Kenji's calculator was built to save managers 25 minutes a night. The beta shows that it also turned workers into a distribution channel.

• Weekly worker-app use at beta restaurants rose from 34% to 81%. Workers open the app at close to see that night's tips.
• 41% of those workers also work at another restaurant.
• 57 restaurants signed up in one quarter because a worker asked them to. That is 0.19 per beta restaurant per quarter. Those deals closed in 9 days instead of 41, at about a third of the sales cost.

Today we grow by selling to owners: 380 restaurants a quarter, about 6% of our base. In the beta, each restaurant generated referrals equal to 19% of itself per quarter, through workers who carry Tally into their other jobs. That changes the shape of our growth curve. A curve that compounds on its own is what gets us to a much bigger company. A longer feature list does not.

The one dimension I would push is the worker, not the owner. We should make Tally the worker's own account across every restaurant they work at. Today we treat workers as users of each restaurant's account.

The data shows workers already try to spread Tally. Across the ~9,000 beta workers, 29% said they asked a manager at another job to use it. That is roughly 2,600 asks, which produced 57 signups. Demand is not the bottleneck. Conversion of worker asks is. Nobody currently sees those asks, routes them, or follows up on them.

2. The most ambitious version

Tally is where every hourly restaurant worker sees and gets their pay, across every job. A worker has one linked account and sees tonight's tips from both jobs. They can cash those tips out the same night. With one tap, they can ask their other manager to join. Every restaurant that joins brings in more workers, and those workers bring in more restaurants.

Later, once we hold the licences, that account becomes the base for earned-wage access.

Sizing from our data (ARR per restaurant ≈ $31M ÷ 6,400 ≈ $4,840):

Caveats. The high case compounds a rate from 300 restaurants that asked to join the beta. It also assumes no churn (we have no churn data here) and no local saturation. The payout range rests on stated intent, and "would pay" usually overstates real use. So treat $70M–$185M as the range to test, not a forecast.

Even the low case is roughly double our current growth rate, reached at a third of the acquisition cost. That low case is not 1000x. The high case gets us to a $1B path within a few years of compounding.

Why this matters against Crewbook. We lost 11% of deals last year on price, mostly to Crewbook. Crewbook sells to owners, while this channel reaches workers. Referred deals cost a third as much, which gives us room to compete on price where we need to. The calculator also enforces state tip-pool law, so an owner can't easily switch away without losing that protection.

3. The sequence

Next quarter: two squads

Squad A: roll out the calculator and build the referral loop. - Roll the calculator out to about 1,500 restaurants that did not ask for it. This tests whether the beta rate survives outside self-selection. - Build an in-app "ask my other manager" flow with tracking of where each ask comes from. - Route every worker ask to sales within 24 hours. - In the second half of the quarter, if the first gate below is met, pilot instant payout of earned tips at beta restaurants. This needs no licence, costs $0.99 per payout, and Tally keeps $0.60.

Squad B: build the linked worker account. - Linking a worker's accounts with their consent is about one squad-quarter. - It is the foundation for everything after: one view of tips across jobs, payouts across jobs, and a worker identity that belongs to the worker rather than to one restaurant.

Gates before each next step

1. Before rolling out to all 6,400 restaurants: - The rollout cohort produces at least 0.08 referred signups per restaurant per quarter (roughly $2.5M+ new ARR per quarter at full base). - Referred deals still close in under 15 days. - Worker weekly use exceeds 60%. 2. Before scaling instant payout: - At least 10% of pilot workers pay for a payout in a month. - At least half of those pay again the following month. 3. Before committing to earned-wage-access licences (9–12 months in 3 of our 5 core states): - Linked accounts cover at least 30% of multi-job workers. - Payout usage meets gate 2. - Compliance can prepare the applications in parallel, since that uses no squad time. We only file once the gates are met. 4. After that: owner products built on network data. For example, labour benchmarks across restaurants. This is where Marcus's vision comes back in (see section 4).

The result that would make us stop

If the non-self-selected cohort produces under 0.03 referred signups per restaurant per quarter, and worker weekly use stays under 50%, the loop was a beta artifact. In that case we would: - stop the network push; - keep the calculator as a retention and compliance feature, since the 25 minutes a night is still real; - move both squads back to the core roadmap.

We will know within one quarter, and it costs us one quarter to find out.

4. What to do with Marcus's idea

My recommendation is not to fund the "AI operating system" next quarter, but to keep it as the destination. My reasons:

• Nothing in our data supports it yet. We have no evidence owners want Tally for inventory, pricing, marketing or reservations. Each of those is a mature category with established vendors.
• We don't have the capacity. Two squads cannot build four products well. Spreading across them would starve the one mechanism we have actually observed.
• It aims at the wrong side of the market. The beta shows our leverage is with workers. An owner-facing OS goes head-to-head with Crewbook and everyone else on features and price. The worker network is something they cannot copy quickly.

Marcus is right about the ambition and the $1B scale. The worker network is how we get there cheaply. It also makes the owner OS far easier to build later. At 20,000–40,000 restaurants, with worker and pay data linked across them, we would have distribution and data that no single-restaurant tool has. Owner products built at that point sell themselves through a base we already own.

Proposal: we treat step 4 as the explicit home for the owner OS. Marcus names the first owner decision he would want Tally to make smarter. We scope it for the quarter after gate 1 is met.

Decision needed: approve the two-squad plan and the gates above for next quarter's planning.