About this prototype

A working sketch of the operating system a Head of Operations & Customer Success would build first: one queue for client messages, a dashboard that ties satisfaction to root causes, a hiring pipeline for the scale-up, and a plan that puts systems before headcount.

Prepared by Ankit Mishra for the Head of Operations & Customer Success application at CanadaVisa / Cohen Immigration Law. It is not affiliated with or endorsed by either, uses none of their data, branding or content, and is not legal advice. Everything below says what is real and what is illustrative.

What is real, what is illustrative

Real: the code. The classifier, the SLA and routing rules, the draft templates, the dashboard calculations and the business-case model all run as shown, with tests. The source is public.
Illustrative: every message, client name, matter number, staff name, requisition, metric and review. They are generated by a seeded script (340 messages, 26 weeks, seed 20261019) and reproduce byte for byte.
From public sources: the five practice areas (Express Entry, Work permits, Family sponsorship, Citizenship, Criminal inadmissibility) follow the operating units named in the firm's public job postings, and the complaint themes (unreturned calls and missed consultations, silence after payment, files closed without explanation, details lost in handoffs) follow recurring themes in public reviews. No review text is reproduced and every message here is invented.
Assumptions: avoidable rates for each fix, handling time, costs, growth. They are labelled on the page that uses them and are meant to be replaced by the 30-day baseline.

How the synthetic data is made

Inbox: 340 messages over 30 days (email, client portal, phone notes and Google reviews), built from 31 message templates across eight intents and eight root causes, with practice-area wording, optional deadlines (13% of messages, 2 to 28 days out), fictional clients, file numbers, case managers, statuses and earlier messages in each thread. Each message keeps the generator's labels, used only to check the rules.
Reviews and silent files: 84 Google-style reviews over 26 weeks (worse as volume grows), tagged by the same root-cause rules, and 52 paid files with no client update in more than 10 days.
Weekly history: 26 weeks, five areas. Volume grows about five times; once it outruns staffing, the share of status-silence and missed-callback messages rises, CSAT and the Google rating drift down, and complaint and escalation rates climb. Family and citizenship files wait longer on government; business files change hands more.
Hiring: 15 roles across seven teams, a stage funnel per role from assumed pass rates, fictional candidates for the board, interviewer panels, 22 recent hires and an onboarding checklist.
Product chrome: the signed-in user, notifications and "last synced" line are simulated to show how the tool would feel day to day; there are no live connections to any system.
Generator: app/src/lib/generate.ts and app/src/lib/hiring.ts; run npm run generate.

Limits

Keyword rules are transparent but brittle: they miss paraphrase, sarcasm and messages in other languages. On synthetic data they agree with the generator 98% of the time on intent, which shows coherence, not accuracy. Real accuracy is measured on hand-labelled real messages.
The SLA clock uses elapsed hours; a real rollout would use business hours and statutory holidays.
Practice area comes from wording only. In practice it comes from the matter record first, with wording as the fallback for new enquiries.
Decisions in the triage drawer (owner changes, approved or rejected drafts) are stored in your browser only. Nothing is sent and nothing is stored on a server.
The optional language-model path in /api/classify is off on this demo. If turned on it labels area, intent and root cause only; priority stays rule-based because deadlines should be parsed, not guessed.

How it would connect in a real rollout

Practice management (for example Clio): read matter, practice area, responsible lawyer and stage; write a note when a reply is approved. Matter-stage changes trigger the proactive status updates.
Email: read from the shared client inboxes through the mail provider's API; approved replies go to the owner's drafts or outbound queue, and a person sends.
Client portal: read portal messages and upload events (failed uploads feed the portal-access root cause); post status updates to the client's timeline.
Surveys and reviews: CSAT survey results by matter; Google review volume and rating from the business profile, matched to practice areas where the reviewer is a known client.
Recruiting: the applicant tracking system for funnels and interviewer calendars; the HR system for the onboarding checklist.

Privacy, privilege and AI guardrails

The reply drafts follow the guardrails the firm states publicly for its AI work: client-facing copy comes only from lawyer-approved templates, there is no automated legal advice, and client data stays in approved systems. In the triage drawer each draft shows its template and version, is checked for advice and outcome-promise phrases (approval is blocked if one appears), and needs a lawyer's sign-off when there is a legal deadline, an escalation, a closed file or a criminal inadmissibility matter.
Client communications at a law firm are confidential and often privileged. No real client data was used to build or test this prototype, and the demo asks visitors not to paste any.
In a real rollout, client content stays inside systems the firm controls and has approved. Any language-model use would run under a contract with no training on firm data, with data residency agreed with the firm, logging of every request, and the same access controls as the matter itself.
Drafts are suggestions for a person to approve. They never state an outcome, a timeline or legal advice; bracketed placeholders force a check against the file before anything goes out.
Metrics are reported in aggregate. Individual staff performance is not the purpose of the dashboard; fixing the system is.

How it was built

Next.js 15, React 19 and TypeScript; static pages from committed JSON, plus one optional API route. Built with Claude Code over an evening, with the author deciding the scope, the rules, every threshold and every sentence. Tests cover the classifier, the SLA and routing rules, the draft templates, the business-case model and data invariants (npm test). Source: github.com/ankitmishra01/client-ops-command-center.