1000x an idea

MEMO To: Marcus Webb and the exec team From: Staff PM Re: The 1000x version of the tip-out calculator

---

1. The mechanism and the dimension to push

The mechanism: the worker is our distribution channel. The calculator gave workers a reason to open Tally every night, because they can see their tips. Weekly active use rose from 34% to 81%. Because 41% of those workers hold a second job, a worker who opens Tally nightly is a salesperson in a second restaurant. In one quarter, 57 restaurants signed up because a worker asked. Those deals closed in 9 days against our 41-day average, at about a third of the sales cost.

That is the mechanism. The 25 minutes a night that managers save is why they adopt the calculator, but it isn't what grows the business.

The dimension I would push: cross-restaurant worker identity. Today a worker at two Tally restaurants has two unconnected accounts. We can't see the overlap, can't make the second job's invitation easy, and can't give the worker one place that holds their pay across jobs. Linking accounts, with consent, turns 190,000 isolated app users into a network. Crewbook can bundle free scheduling, but it can't copy a worker base that is already pulling restaurants in.

2. The most ambitious version

Tally is where restaurant workers see and receive their pay, and the worker network is how restaurants find us. It has three parts: - One worker account across every job. - A same-night tip payout. It pays out tips already earned, so it needs no licence, and Tally keeps $0.60 of the $0.99 fee. - A one-tap "bring Tally to my other job" flow.

Sizing. Today we make about $4,800 ARR per restaurant and have about 30 workers per restaurant.

Payout revenue on today's base (190,000 workers). Survey intent was 44%, which overstates real behavior, so I used 22% to 44% adoption at 2 to 3 payouts a week at $0.60. That gives $2.6M to $7.8M a year. This is real money, but on its own it is not 1000x.

Referral growth. The beta produced 0.19 referred restaurants per calculator restaurant per quarter. Beta restaurants chose to join, so I discounted that to 0.05 as a floor. I compounded both rates over eight quarters on the 6,400 base, excluding our current 380 signups a quarter and assuming no churn:

Planning range: $50M to $155M ARR in two years, against $31M today. I would plan on the low end. The high end needs the beta rate to hold at about 4x the scale with no saturation.

This is a 2x to 5x outcome, and the data does not support 1000x. What can be much larger is the shape of the business: customer acquisition that costs a third as much, sales cycles of 9 days instead of 41, and a revenue line that scales with workers rather than with restaurants. A $1B company needs the high end sustained for longer than two years.

Caveats: - The beta restaurants chose to join. - We don't know how many of the 57 referred restaurants were already in our pipeline. - Survey answers are stated intent, not behavior. - The 190,000 figure counts accounts, so unique workers are fewer. Linking accounts will give us the real number.

3. The sequence

Two squads next quarter. Before they start, spend two weeks of analyst time on the 57 referred deals. We need to know how many were already in the pipeline and what the true multi-job share is across the whole base. This costs no squad time.

Step 1 (next quarter) - Squad A (Worker Identity): builds the linked worker account with consent, plus the "bring Tally to my other job" invite in the app. This is the one-squad, one-quarter estimate. - Squad B (Money and Rollout): takes the calculator from 300 restaurants to about 1,500, including state-rule coverage in our five main states. It also pilots same-night payout in the beta restaurants. The pilot uses earned tips only, so no licence is needed.

Before Step 2, all of these must be true: - Outside the self-selected beta, referral runs at 0.10 or more new restaurants per calculator restaurant per quarter, and referred deals close in under 15 days. - At least 50% of multi-job workers who are prompted link their accounts. - At pilot restaurants, at least 20% of workers use payout within 30 days, and half of them use it again. - Referred restaurants show no worse early churn than the rest of the base.

Step 2 (quarters 2 and 3) - Squad A: builds the referral loop, with a fast onboarding path for a restaurant invited by one of its own workers. - Squad B: makes payout available across the whole calculator base. - Compliance starts the early-wage licence work in the background at low cost. It is an option, not a dependency.

Before Step 3: - Payout revenue per active worker is tracking toward the $14 to $41 a year range. - The referral rate holds at scale. - Win rate against Crewbook is better in markets where Tally already has worker density.

Step 3 (quarter 4 onward). Decide whether to pursue early wage access, which needs licences in 3 of our 5 main states and 9 to 12 months. Decide this with real payout data in hand, not before. Explore labor-adjacent products on the worker network, such as availability across jobs.

The result that would make us stop. After two quarters at about 1,500 calculator restaurants, referrals run below 0.03 per restaurant per quarter (about 190 new restaurants a quarter at full base, fewer than half of what we sign today), and payout adoption is under 10% of workers. That would tell us the beta was a self-selected group and the calculator is a good retention feature for managers, not a growth engine. We would keep the calculator, stop investing in the worker network, and put the squads elsewhere.

4. What we should do with Marcus's idea

Don't build it now, and don't drop the ambition behind it. The "AI operating system" is four separate products: inventory, menu pricing, marketing, and reservations. Each has a different buyer, different data, and different incumbents. Nothing in our data shows owners want any of them from us. What our data does show is that workers pull restaurants into Tally, and that is our right to win.

The two ideas fit together in sequence. If the worker network works, we will have something no inventory or marketing tool has: the people in the restaurant, using Tally every night, across several employers. A broader platform is much more credible once owners are already adopting Tally because their staff asked for it. A labor-first path, where Tally uses availability and pay across jobs to make scheduling and staffing decisions smarter, can grow into the larger vision.

My recommendation: adopt the worker network as the plan for next quarter, and revisit the operating-system vision at the Step 2 gate, with data from the referral loop and payout in hand. If the gates pass, the case for the larger vision will be much stronger than it is today.

Kenji deserves credit here. His calculator turned a free worker app into a nightly habit. The habit created the mechanism, and the plan above is how we turn it into a business.

MEMORANDUM

TO: Marcus Webb (CEO) & Executive Team FROM: Staff Product Manager, Tally DATE: October 24, 2023 SUBJECT: From Tip Calculator to Network Effect: The $1B Path for Tally

---

1. The Mechanism and the Dimension

Kenji’s beta proved that the tip-out calculator saves managers 25 minutes a night and drives worker app engagement from 34% to 81%. But the real mechanism that makes this 1000x bigger isn't automation—it is multihoming labor coupled with a viral consumer loop.

Right now, 41% of workers at beta restaurants work at another restaurant. Because the tip calculator demands they check the Tally app at close to verify earnings, they are carrying our brand into competitor venues. When they ask their other managers to switch, those inbound deals close in 9 days (vs. our 41-day average) at one-third of the acquisition cost.

The single dimension we must push is Cross-Restaurant Worker Identity. Right now, a worker with two jobs has two siloed accounts. By unifying them into a single identity, we transform Tally from isolated B2B restaurant software into a consumer-grade network where workers organically pull non-Tally restaurants onto our platform.

---

2. The Most Ambitious Version & Opportunity Sizing

The 1000x version is Tally Financial Network: a closed-loop financial operating system for hourly hospitality labor.

We stop selling software top-down to stressed operators alone and start growing bottom-up through the financial urgency of 190,000+ hourly workers. Tally becomes the infrastructure where workers instantly access, manage, and move their daily earnings across the fragmented restaurant landscape.

#### Opportunity Sizing (Range) * Conservative Case ($35M–$50M ARR added in 24 months): Driven purely by viral acquisition velocity. If we reduce sales cycles from 41 days to 9 days across a larger cohort of worker-referred restaurants, our organic acquisition rate triples, lowering CAC and accelerating ARR past $80M without expanding headcount. * Aggressive Case ($120M–$180M ARR added in 24 months): Driven by Same-Night Tip Payouts. Our payments partner allows us to pay out tips already earned the same night for $0.99, netting Tally $0.60 per payout. With 190,000 workers (plus viral additions), assuming an average of 3 shifts a week and a 44% adoption rate (validated by our survey), this creates a massive, high-margin transactional revenue stream that dwarfs our current SaaS subscription model.

---

3. The Execution Sequence

We have two engineering squads allocated for next quarter. Here is the strict sequence, prerequisites, and hard stop-conditions.

#### Squad 1: Unified Worker Identity & Viral Loops (Q1) * What they build: The underlying database architecture to link a worker’s identity across multiple restaurant profiles (with explicit worker consent), alongside the frictionless "Invite Your Other Job" referral and onboarding flow inside the worker app. * Prerequisite: Legal review confirming that linking accounts via worker consent does not violate data-sharing agreements with restaurant operators. * Stop Condition: If fewer than 15% of multi-job workers consent to linking accounts, or if viral referral conversion drops below 10%, we abort and keep accounts siloed.

#### Squad 2: Same-Night Tip Payouts (Q1) * What they build: Integration with our payments partner to enable same-night, post-close tip payouts for $0.99, ensuring strict compliance with state tip-pool rules (keeping managers/owners out of the pool) and avoiding early-wage-access licensing traps. * Prerequisite: Final sign-off from Compliance confirming that paying out already-earned tips post-close requires zero new state licenses (avoiding the 9-to-12-month licensing delay). * Stop Condition: If payment partner error rates on same-night liquidity exceed 0.1%, or if take-rate margins are squeezed below $0.40 per payout, we halt.

---

4. What We Should Do with Marcus’s Idea

Marcus’s vision—“Tally becomes the AI operating system for restaurants: inventory, menu pricing, marketing, reservations, all of it... That's how we become a $1B company”—is the right long-term destination, but the wrong sequence for next quarter.

If we try to build inventory, menu pricing, and reservations right now, we dilute our engineering focus and walk straight into a bloody feature-parity war with entrenched incumbents, while simultaneously losing deals to Crewbook on price (11% loss rate last year).

Recommendation: Politely shelve the "AI Operating System" breadth for 12 months. Instead, weaponize Kenji’s tip calculator.

By unifying worker identity and launching same-night tip payouts, we leverage our unfair advantage: the workers. We use consumer-grade financial utility to bypass the restaurant owner's sales resistance entirely. Once we own the liquidity of the hourly workforce across 50,000+ restaurants, then operators will have no choice but to adopt our broader operational suite—because their staff demands it. That is how Tally becomes a $1B company, starting with a 99-cent tip payout.