1000x an idea

To: Marcus Webb and Executive Team From: Staff PM Subject: Make tip-out a worker-led distribution network—not an everything app

Recommendation

Give the two squads next quarter to test a bigger thesis: Tally can become the portable earnings account that workers bring from restaurant to restaurant, making workers a distribution channel for our employer business.

The dimension to push is reach across workplaces, not breadth of restaurant software. Kenji’s calculator may be the entry point to that network. The evidence does not yet establish a literal 1,000× opportunity; it establishes a mechanism worth testing before we commit to a broader platform.

1. The mechanism: one worker can recruit the next workplace

The calculator solves a nightly manager problem, but its more consequential effect may be on workers:

• Worker-app weekly activity rose from 34% to 81% at beta restaurants.
• 41% of beta workers also work at another restaurant.
• 29% of surveyed workers say they have asked another manager to adopt Tally.
• We recorded 57 worker-requested restaurant signups last quarter. Those deals closed in nine days versus our usual 41, with roughly one-third the sales spending per deal.

The potential loop is:

Accurate nightly tips → workers return at close → workers request Tally at another job → another restaurant adopts → more workers encounter Tally.

This could change acquisition economics, not just improve a feature. It also creates a reason to choose Tally that Crewbook’s free scheduling does not directly answer.

But this is not yet a demonstrated network effect. The beta was self-selected, the survey measures stated behavior, and we have not established how many of the 57 signups were incremental or originated in the beta.

2. The ambitious destination—and a defensible size

The most ambitious version is a worker-consented earnings network spanning restaurants:

• One identity connects a worker’s jobs, shifts, and earned tips.
• Workers see verified nightly earnings and can optionally receive already-earned tips immediately.
• A worker can ask a second employer to join through a lightweight invitation and onboarding path.
• Restaurants join first to deliver trusted tip accounting and settlement; scheduling and payroll expansion follow.

Eventually, the network could extend beyond restaurants already using Tally’s full suite. That requires proving we can verify earnings and onboard an employer without compromising compliance. It is a destination, not next quarter’s scope.

We can size a beachhead from our current footprint, not a national TAM:

Subscription sizing uses today’s average of approximately $4,844 ARR per restaurant. The acquisition scenarios are sensitivity cases, not forecasts: we must validate the referral denominator, incremental lift, saturation, retention, and pricing. They are not automatically additive to our existing 380 quarterly signups.

Payout adoption likewise discounts—or at its upper end accepts—the survey’s 44% stated willingness to pay; transaction frequency is an assumption. Not every worker will have eligible tips.

These are separate revenue measures, not a combined ARR claim. They show a potentially material business on our existing footprint. The larger, cross-platform opportunity remains unquantified.

3. Work backward: earn each expansion

Next quarter: establish the worker connection and test causality

Squad 1: Portable identity. Build consent-based linking of existing restaurant accounts into one worker account, with clear employer boundaries, revocation, and no leakage of one employer’s information to another. This is the stated one-squad-quarter investment; do not bury unrelated work in it.

Squad 2: Prove the distribution loop. Harden tip correctness and dispute handling, instrument worker invitations through restaurant activation, and run a controlled expansion beyond the volunteer beta. Randomize rollout or invitations at an employer/network-cluster level where practical, accounting for workers who connect clusters. Distinguish an invitation, a signed contract, and a restaurant actually running payroll.

Test referrals using existing accounts while identity work proceeds. Do not wait a quarter to start learning, and do not promise advances or build a broad financial product.

Gate to broader rollout: After at least two normal sales cycles, demonstrate incremental, retained restaurant acquisition versus a comparison group—not merely faster attribution of deals we would have won anyway. A provisional investment hurdle is 0.05 incremental activated restaurants per participating restaurant per quarter, roughly one-quarter of the provisional beta rate, with lower fully loaded acquisition cost than ordinary sales. Set retention and tip-accuracy guardrails before launching.

Next: monetize earned tips without weakening the loop

Once verified tip accounting and payout reconciliation pass Compliance review, Squad 2 can pilot the partner’s $0.99 optional same-night payout; Squad 1 extends proven identity and invitation flows. Preserve free tip visibility.

Gate to expansion: Observed repeat purchases—not survey intent—produce positive contribution after support and losses, with no material increase in disputes or deterioration in worker engagement. Failure here means dropping paid payouts, not automatically abandoning referrals.

Then: open the network beyond full-suite customers

Only after acquisition and retention replicate outside the beta should we test a lightweight tip-and-earnings entry product for employers not ready to switch payroll.

Gate: Verified earnings, enforceable pool rules, economical onboarding, and incremental customer value without unacceptable full-suite cannibalization.

Stop result: If an adequately powered test over at least two sales cycles shows no meaningful incremental retained restaurant acquisition—or economics below our agreed hurdle—we stop funding the network expansion. Keep the useful calculator. Pause immediately for material tip-allocation or privacy failures.

4. What to do with Marcus’s idea

Keep Marcus’s ambition; reject the proposed scope for this planning cycle.

Inventory, menu pricing, marketing, and reservations each require new data, workflows, and distribution advantages that this pack does not establish. Calling them an AI operating system does not connect them to our strongest evidence.

Reframe the vision as “Tally becomes the earnings network workers bring to every restaurant.” AI can support that strategy where it demonstrably improves outcomes; it is not the strategy itself. Defer advances and their licensing burden. Return to broader platform bets only after we prove the mechanism that earns us the right to expand.

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.