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.

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.