Tip pooling and distribution

A configurable tip management system for full-service restaurants, contributing to $1M in SaaS revenue.

$1 million

SaaS revenue generated by TipCalc

$8 million

Full-service restaurant bookings powered

~80%

Market coverage (Aloha + Toast combined)

— Company

Branch

— Timeline

2024-2026

— Role

Sole designer

— Platform

Pay Admin (Web)

— The problem

The problem behind the paycheck

At the end of a Friday night shift, a server at Miller's Ale House went home not knowing how much they'd earned in tips or when it would arrive. Distribution was manual. Managers reconciled everything by hand, staying late doing math instead of running a restaurant.

Branch saw an opportunity to fix this at scale. Aloha and Toast cover roughly 80% of the full-service restaurant market. If TipCalc could integrate with both and automate tip distribution end-to-end, it would open a new SaaS revenue stream while meaningfully improving how hospitality workers get paid.

The challenge was configurability. No two restaurants tip the same way. Rules vary by location, shift, job code, and revenue center. A one-size-fits-all system wouldn't work. TipCalc had to be highly configurable without becoming unusable.

— Users

Two users, different needs

Restaurant workers Workers never interact with TipCalc directly, but every design decision either earns or breaks their trust downstream. They need confidence that tips were calculated correctly and will arrive on time.

Restaurant managers Managers configure tip rules across job codes, revenue centers, and shifts, then close out the business day — often late at night. Every friction point in that workflow is a real operational cost.

— My role

15 months, sole designer

I was the sole designer on TipCalc from early prototype through the Miller's Ale House pilot launch, working alongside Carly (PM), a full engineering team, and the professional services staff responsible for onboarding new restaurant locations.

Research was embedded in the work itself. Context came through direct feedback loops with Miller's Ale House via the PM, bug bashes with engineers, and observing where managers got stuck during testing. That proximity to real usage shaped every significant design decision.

— Considerations

Four decisions that shaped the product

1. The close-day workflow was the highest-risk moment‍ ‍

If a manager couldn't close out the day, workers didn't get paid and the customer would churn. I treated this as the core design problem from the start: designing a checklist pattern with clear status at a glance, inline error states for system failures, and a proactive alert system to surface issues before they became blockers.

The pattern worked well enough that product leadership later flagged it as a candidate for home screen onboarding, extending its utility beyond the original scope.

2. Highly configurable systems need a clear mental model Tip rules are built on top of job codes, revenue centers, and shifts. If any of those get deactivated, the rules that reference them silently break.

I worked with engineering to map that dependency chain before touching Figma, then designed the configuration experience so managers could see those relationships clearly. The goal was to make an invalid state feel impossible to stumble into, not just recoverable after the fact.

3. Professional services staff were a hidden third user PS staff onboard new restaurant locations, but the product was designed almost entirely for managers. I noticed early that PS staff had no way to orient themselves in an org's lifecycle without digging through documentation.

I wrote the org state copy directly (Testing, Live, Inactive) with PS orientation in mind and designed a persistent state banner so they could understand where an org stood at a glance. It reduced a coordination gap that nobody had formally scoped.

4. Knowing when not to design is part of the job

When a ticket came in to add a setting allowing managers to manually move flagged checks to held status, I paused before opening Figma. There were open questions about what the toggle actually controlled, what happened to flagged checks that reached day close without action, and whether turning it off would affect checks already in a held state. I surfaced those before designing so the team could align. Once we had answers, the design moved quickly — but the questions needed to be asked first, and they weren't in the ticket.

— Outcome

What shipped

Miller's Ale House launched as the pilot customer. TipCalc now contributes to $1M in SaaS revenue and powers $8M in full-service restaurant bookings. The 2026 roadmap focuses on expanding to Toast, with the configuration system built during this project as the foundation. Aloha and Toast together represent roughly 80% of the addressable market. Additional features extending the org lifecycle and configuration system are currently in progress.

Branch tracks two metrics for TipCalc: TipCalc Revenue and Close Out Completion Rate. Since launch, Miller's has closed out successfully 92% of business days. The close-day checklist and alert system, designed to surface issues before they become blockers, connect directly to that number.

View prototype

— Reflection

What I learned

Operational tools fail quietly. A manager who doesn't understand a setting won't file a bug report. They'll just make the wrong call, and workers will notice the consequences.

That raised the bar on every decision: not just whether something works, but whether it makes sense to someone who's exhausted, pressed for time, and doing five other things at once.

Admin tools have downstream consequences for workers who never see them. Getting the manager experience right is how workers get paid accurately and on time. That connection kept the work grounded throughout.