Designing the systems that transformed how ops specialists serve thousands of law firms.
Proof's operations team coordinates thousands of serves daily across a distributed network of process servers. I designed a task management system that brought structure, ownership, and visibility to their most complex workflows.
Everyone deserves to know when they're being sued.
Proof is a legal tech platform that handles service of process: the constitutional requirement that someone must be formally notified when they're sued. Proof's platform connects thousands of law firms with a nationwide network of vetted process servers.
Legal tech is complex.
Behind every successful serve is an ops team navigating layers of complexity: federal law, state law, county rules, court jurisdiction, judge preferences, client preferences. Can you serve on Sunday in Florida? Does this county require a notary? Is this a garnishment or a summons? Does that change the timeline?
Before this project, that knowledge lived in spreadsheets, Slack threads, and people's heads.
There was no task system. At all.
Specialists worked from a dashboard that showed jobs needing attention, but there was no structure for what needed attention or who should handle it. The most common workflow was “babysitting”: a specialist would open 15–20 browser tabs, one per job, and watch them move through the serve lifecycle. When something needed action, they'd jump in. Then go back to watching.
Work got distributed through Slack and tribal knowledge. A supervisor would say “hey, can someone look at the Smith case?” and whoever was available would grab it. A client could have five serves open with the same recurring issue and no one would notice — because people were thinking about individual jobs, not client relationships or task types.
This created compounding problems:
No ownership
Enterprise clients paying premium rates got the same anonymous service as self-serve accounts. No one knew their history.
No visibility
We couldn't measure performance because there was nothing to measure. Everyone did everything.
No specialization
Some work requires deep expertise (affidavit prep, compliance review). Some requires speed (dispatch, basic QA). Treating all work as interchangeable meant neither got optimized.
No scalability
Every acquisition, every new service line, every enterprise deal required ad-hoc workarounds. There was no model for how to organize work.
Mapping what “work” actually meant.
Before I could design a task system, I had to define what a task even was.
I mapped the complete job lifecycle, from the moment a job enters the platform to final completion, and identified every point where ops might need to act. This revealed 10+ distinct task types, each with different triggers, different required information, and different actions.
The “babysitting” workflow existed because the system had no concept of these distinctions. A job needing dispatch looked the same as a job needing affidavit review. The only way to know was to open it and look.
I designed a three-layer model: Teams, Roles, and Routing Logic.
Teams create client ownership
Every client maps to a team. Enterprise clients get dedicated teams. Platform clients map regionally. Dispatch handles exceptions across all teams.
Roles create specialization
10 distinct roles, mapped from the lifecycle work. Each has clear responsibilities, required skills, and measurable outputs.
Routing logic creates predictability
Tasks find the right person through rules, not luck. The system prioritizes continuity (same person on a client's work) while ensuring coverage.
Documentation as a design artifact.
The complexity here — 10 roles, multiple team types, routing logic with fallbacks — couldn't live in wireframes. I wrote a comprehensive spec covering every task type: what triggers it, what information surfaces, what actions are available, SLA expectations, escalation paths.
This document became the single source of truth for the build and survives today as institutional knowledge.
From tabs to tasks.
Structured queues
Specialists went from babysitting 15–20 browser tabs to working a structured queue.
Dedicated enterprise support
When a paralegal calls, they reach someone who knows their account.
Measurable performance
For the first time, we can see who's excelling and where training is needed.
Foundation for growth
Acquisitions now have an integration playbook.
“Project Phoenix” launched November 4, 2024.