Love Superhuman Docs too! Happy to nerd out about it. Here’s one I’m proud of (client details stripped out):
The setup
The client places supervising doctors with companies that employ nurses across many states, and every state sets its own rules for that supervision. Besides the doctors, the client’s main product was compliance with all the states for all doctor-nurse relationships. Strip away the healthcare part, and it’s a common pattern: one operator, many client companies, and two kinds of people paired together under rules that change by region.
Where they started: three docs
When they came to us, they already had a version of three docs, built around their first client:
- a client doc, which also held all the doctor and licence data
- a doctor doc, for doctors to see and manage the nurses they had
- a nurse doc, for nurses to see and interact with their doctors
Then more clients signed, and the ask was simple: “Duplicate the client doc and the nurse doc for each new client.”
Why duplicating would have hurt
- The same people would live in many copies. A doctor works for several clients, so every doctor, licence and pairing would be copied into every client’s doc. Renew one licence and someone has to update it in every copy, or the copies drift apart.
- Limits become invisible. Each copy sees only its own nurses. A doctor who’s full would look half-empty to two clients at once, and both could assign more. The rule can only be enforced when everything is counted in one place.
- The doctor doc would need rewiring for every new client, since it would have to pull from a growing pile of client docs.
- Every fix and every new feature has to be built N times. So does every rule change.
- No one sees the whole business. “How much room do we have?” means adding up numbers across every copy, by hand.
What we suggested instead
Build a fourth doc as the single source of truth, then refactor the other three to pull from it. The hub owns the data; every other doc becomes a window onto its own slice.
| Doc |
How many |
Who uses it |
Job to be done |
| Operations hub (new) |
1 |
The operator’s team |
“Keep one true record of every person, pairing and rule across every client, and know we’re compliant everywhere.” |
| Client workspace |
1 per client |
Each client company |
“See and manage only the people we hired, request new pairings, and know they’re compliant, without seeing anyone else’s data.” |
| Doctor portal |
1, shared |
All doctors |
“Show me everyone I’m responsible for, across every client, and what I owe this month.” |
| Nurse portal |
1 per client |
That client’s nurses |
“Show me my supervisor and my requirements, and let me log what we did together.” |
How that made duplication easy
Once the client workspace and the nurse portal held no data of their own, they became templates. Each pulls its client’s slice from the hub by cross-doc sync, filtered to that client. So onboarding a new client means:
- duplicate the two templates
- point them at the new client
- let the sync fill them
The two docs they originally wanted to duplicate are now duplicated for every new client, safely, because the copies share one source of truth instead of each being one.
The doctor portal stays a single doc, because a doctor belongs to the whole network, not to one client. The doc structure mirrors who belongs to whom.
Results (rough numbers from my side of the build): matching a doctor to a new nurse went from about an hour to about 4 minutes, with the full check every time.
That’s just one of so many examples 
) docs/systems you’ve put together with it. I’d love to hear about it!