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. I led this cross-functional initiative partnering with VP of Operations, Product, and Engineering to design and ship the foundation for scalable ops.
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.
Ops specialists weren't managing work. They were babysitting jobs. Every job required active monitoring — manually checking on process servers, hunting for status updates, piecing together what had happened from emails and Slack. Work got dropped when someone was out. Errors got caught after the fact, when a client called. The issue wasn't effort. People were working hard. The system just gave them nothing to work with.
This created compounding problems:
No ownership
Enterprise clients paying premium rates got the same anonymous service as self-serve accounts.
No visibility
We couldn't measure performance because there was nothing to measure. Everyone did everything.
No specialization
Some work requires deep expertise. Some requires speed. 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 interviewed ops specialists, shadowed their workflows, and mapped every touchpoint from job creation to affidavit filing. 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 strategic alignment.
The complexity here — 10 roles, multiple team types, routing logic with fallbacks — required alignment across ops leadership, product, and engineering. I wrote a comprehensive spec that became the single source of truth for the build and survives today as institutional knowledge for onboarding and operations planning.
Navigating competing priorities.
This project required navigating competing priorities across operations, product, and engineering. I led weekly alignment sessions with the VP of Operations to validate the role model, worked directly with engineers to define routing logic and edge cases, and partnered with the product team to sequence the rollout and plan for adoption.
I also created the comprehensive documentation that became the shared reference for implementation — bridging the gap between my design thinking and what engineering needed to build.
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
We can now see where training is needed.
Foundation for growth
Acquisitions now have an integration playbook.
“Project Phoenix” launched November 4, 2024.