B2B SaaS
Self-serve
0-to-1
Collaborator invitations
Self-serve onboarding assumed one person had every answer. They didn't.
Designed and launched a secure invite and collaborator management system for Checkmate's self-serve onboarding, letting restaurant owners delegate POS, delivery, and banking setup to teammates instead of sharing a login or calling support.
Role
Product Designer, sole designer on the feature
Team
1 product manager, 1 engineer
Timeline
4 weeks in 2022
Company
Checkmate (formerly ItsaCheckmate)
Platform
Onboarding flows, web
Two named roles, and every access change available inline. Nothing here needed a support ticket.
At a glance
The problem
Self-serve onboarding assumed the person signing up held every credential. Owners who hit an information gap shared their login or called support, and both cost time.
What I did
Designed invitation, role assignment, and access management from nothing, since the account model had never supported more than one user, and put the management view inside onboarding rather than in a separate admin area.
My role
Sole designer, with 1 PM and 1 engineer, in 4 weeks.
Result
Checkmate moved from a single-credential account model to role-based delegated access. Onboarding completion and support load both improved after launch.
The context
Checkmate (known as ItsaCheckmate until a 2024 rebrand) is a B2B SaaS platform that helps restaurant chains, including Wendy's, Arby's, and Buffalo Wild Wings, unify their online ordering, delivery, and POS systems. By 2022, the platform was processing $9B in order value across 23,000+ live locations, had raised a Series B, and had grown past 300 people. We were moving fast.
Growth at that pace meant a steady stream of new restaurant owners signing up, and self-serve onboarding was the only way to bring them on without scaling support headcount at the same rate. But self-serve only works if the person going through it actually has everything the system needs, and for a lot of owners, that assumption didn't hold.
The problem
"I don't have my banking details, that's with my business partner. I wish I could just invite her to help set this up."
Restaurant owner, onboarding to Checkmate
There was no invite mechanism, so owners had two bad options: share account credentials with a teammate, or stop and contact support to add a user manually. Both cost time. Credential sharing also created a security exposure Checkmate had no visibility into. Once a login is shared, there is no way to tell who did what, and no way to revoke one person's access without changing everyone's.
Constraints going in:
No existing way to add a second user to an account or assign them a role
No status visibility once an invite went out, so owners had no way to know if it was seen, ignored, or lost
Every basic user management action (add, resend, remove) required a support ticket
This wasn't a UI patch. Checkmate's account model had never supported more than one user per account, so the feature meant designing invitation, role assignment, and access management patterns with nothing existing to build on.
Research
Discovery: the constraint came first
We had no budget or bandwidth to run discovery interviews with restaurant owners directly. That's a real limitation and it shaped what I could learn, so it's worth stating plainly rather than describing around.
What we did instead: the design team interviewed Checkmate's internal onboarding team and customer support team, the people who spoke to stuck owners every day, and I pulled pain points and edge cases directly from support ticket data, which was the only place this problem had been documented until then.
Why the proxy was defensible here
The onboarding and support teams weren't a substitute for owners in general. But for this specific question they were unusually well positioned: the failure mode we were investigating ended in a support ticket by definition. An owner who got stuck at the banking step and couldn't proceed had exactly one path forward, and it went through the people we were interviewing. The population we couldn't reach directly was, in this case, the population that had already been funnelled into the people we could.
What the proxy could not tell me
Support hears from people who complained. Owners who abandoned onboarding silently never generated a ticket, and they're plausibly the larger group.
Internal teams describe the problem in the product's vocabulary, not the owner's. They'd say "they can't complete the banking step"; an owner might say "I'm not putting my partner's bank details into a website I just found."
Proxies report what happened, not what people would have preferred. They could tell me owners asked to add a teammate. They couldn't tell me what an owner would consider a safe amount of access to grant.
That last gap turned out to matter. It's the thing iteration 1 got wrong.
Evaluation: 4 moderated sessions with existing self-serve clients
Discovery had to run on proxies, but evaluation didn't. I ran 4 moderated sessions with existing self-serve clients on the prototype: real restaurant operators, working through a real invite.
That split is the part I'd defend hardest. Interviewing owners at discovery would have meant recruiting people who had already abandoned onboarding, which is slow and expensive. Testing a prototype with clients we already had a relationship with was neither. Same population, a fraction of the cost, at the stage where their input changed the most.
Four sessions is a small n, and it's enough to find a blocking usability problem. It is not enough to tell you whether one layout converts better than another. It surfaced the right kind of finding: iteration 1 didn't fail on a metric, it failed because people hesitated and said why.
Iteration 1: one dense form
A single form for email and permission level, tested first and rejected.
I started here on the assumption that fewer steps meant less effort. It didn't test that way. People got stuck. Granting access felt permanent and consequential, and density read as effort rather than simplicity.
This is where the proxy research fell short. Support could tell me owners wanted to invite someone. It couldn't tell me they'd hesitate over how much access that meant. Only putting a prototype in front of someone surfaced that.
Iterations 2 and 3: breaking it into steps
Would isolating one decision per screen lower perceived effort, even with more steps? Yes. I split the flow into a sequence: task, invitee details and role, optional message, review. Testing showed more confidence at each step, since owners evaluated one decision at a time instead of all of them at once.
Testing a tabbed invite and manage view against a full permissions list.
The role names changed here too. Iteration 3 called them SMB Admin and SMB Customer, which is how Checkmate described these people internally: as a market segment. But an owner inviting their bookkeeper does not think of her as an SMB Customer. They think of her as someone who needs access to one thing. Admin user and Regular user say what a person can do inside this account, which is the only question being asked at that moment.
Internal vocabulary leaks into interfaces easily, because it is the language the team speaks all day. It is worth checking every user-facing label against the question the user is actually answering.
Final design: invite and manage in one place
Was the next source of friction the invite flow, or what happened after? The latter. I moved the management view, not just the invite flow, directly into onboarding, so an owner never had to leave the flow they were already in to check on an invite or fix a mistake.
Trade-off: it duplicates functionality that arguably belongs in account settings, and creates a second place where user management lives. I accepted that because the alternative asks someone mid-onboarding to leave the flow they're trying to complete in order to check on the thing blocking them.
The version that shipped: invite and manage collaborators in one screen.
The solution
The final flow has two parts: sending an invite, and managing collaborators after the fact.
Inviting a collaborator
Before: no way to add a second person to an account at all. Owners shared credentials or called support.
After: a four-step flow.
Click "Manage collaborators" from the Onboarding Details card in the Onboarding Portal
Enter the person's email and assign them as an Admin user or a Regular user
Add an optional note
Review and confirm before sending
Two named roles, not a permissions matrix
Admin user or Regular user. A granular permissions matrix would have been more flexible and more familiar from enterprise software. But the person using this is a restaurant owner mid-signup who is already unsure about delegating access, and iteration 1 established that consequence-uncertainty, not capability, was what stopped them. Two named roles is a decision someone can make in five seconds.
Trade-off: coarse roles don't fit every case. An owner who wants to give a bookkeeper banking access only can't express that, and has to over-grant. That's a genuine limitation, and the right one to accept in a 4-week 0-to-1 where the goal was getting anyone to delegate at all.
Managing collaborators
Before: once an invite was sent, the owner had no visibility into it. Any fix (resend, role change, removal) meant a support ticket.
After: owners see a clear status for every invite, still invited and waiting, or active once accepted, and can resend the invite, change the assigned role, or remove access. All inline, without a support request.
Admins can resend invites, update roles, or remove users
Both parts live inside the existing onboarding surface, not a separate admin page, so managing collaborators is part of finishing onboarding rather than a detour from it.
The impact
Median onboarding time fell 65%. The gain came from removing the single hard stop in the flow: an owner missing a piece of information could bring in whoever had it, instead of stalling until support intervened.
Support tickets and manual admin interventions dropped after launch, since owners no longer needed support to add a user, resend an invite, or change a role. Credential sharing between owners and teammates was eliminated, because collaborators no longer needed the account owner's login to help. Those are the same fix seen from different angles.
The more durable change is structural. Checkmate went from a single-user account model to one supporting delegated, permissioned access. That is infrastructure that scales as the company adds products touching a restaurant's finance, delivery, and POS operations, and it is the claim that needs no number at all.
What I can speak to directly: the invite flow, the role model, the in-onboarding placement of collaborator management, and the status-visibility pattern are the ones I designed.
Note on metrics
The 65% was measured by Checkmate's onboarding team, who owned the self-serve funnel and its reporting. I have their figure rather than the underlying data, which is worth saying plainly: it is a measured number, just not one I instrumented myself.
There is a useful symmetry in that. The onboarding team was also one of my two proxy sources at discovery, so the people who told me where owners were getting stuck are the same people who measured whether the fix worked. That is the closest this project came to closing the loop.
What I learned
Self-serve products fail quietly when they assume one person holds every answer. Restaurant owners rarely hold every banking, POS, and delivery relationship themselves. A tool that doesn't account for that pushes people toward workarounds that are worse for everyone: slower for the user, less secure for the business. It's a pattern I now check for by default in any onboarding flow that touches sensitive setup.
Perceived consequence is a different constraint from effort. Iteration 1 optimized for fewer steps and lost, because the thing stopping people wasn't how long it took. It was not knowing what they were agreeing to. More steps, each one smaller, tested better. I'd have gotten that backwards without testing it.
A proxy tells you what happened, not what people wanted. Support and onboarding teams gave me an accurate map of where owners got stuck. They couldn't tell me how owners felt about delegating access, and that feeling was the actual design problem.
What I'd do differently
I'd have fought for discovery access, not just evaluative access. We got 4 sessions with clients at the prototype stage but nothing at discovery, and I treated the budget constraint as a given rather than making the case. The irony is that we clearly could reach self-serve clients when there was something to show them, so the barrier was less about access than about how the ask was framed. Even three conversations with owners who'd abandoned onboarding, the group support never hears from, would have changed what I knew going in.
I'd have instrumented the invite funnel, not just completion. Knowing that completion rose doesn't tell me where invites die: sent but never opened, opened but not accepted, accepted but still stuck. That breakdown is what a follow-on iteration would need, and I didn't leave it behind for whoever picked this up.
Want to talk through it?
Happy to walk through the decisions behind this project, or hear about what you're working on.
© 2026 Sean Yu