A plaintiff firm optimises for intake conversion and settlement velocity. A defense firm optimises for realization against carrier guidelines. An immigration practice optimises for document completeness and filing accuracy. These are not variations on one configuration — they are different systems sharing a data model. What changes is the architecture, not the licence.
Trusted by 500+ organizations — including law firms and legal technology companies building their case, billing and reporting operations on Salesforce with Twopir Consulting.
Practice Areas We Build For
Each of these is a real configuration decision where the right answer differs by practice. A build that does not make them deliberately makes them by accident.
For a plaintiff firm, intake is a sales funnel with marketing attribution and a conversion rate. For a defense firm, work arrives by carrier assignment and the equivalent question is conflict clearance. Same object, opposite emphasis.
Contingency work has no time entries to defend and lives or dies on case selection and settlement speed. Hourly carrier work lives or dies on whether an entry survives guideline review. One build cannot prioritise both.
Statutes of limitation for plaintiff work, court and discovery schedules for defense, filing windows and priority dates for immigration. Different rule sources, different warning intervals, different owners.
For immigration, document completeness is the work — a missing item stops a filing. For plaintiff, documents are evidence feeding damages. For defense, they are discovery. The folder structure should reflect that.
A personal injury client needs proactive status updates for two years. An immigration client needs a portal and a checklist. An insurance carrier needs scorecards and compliant bills. Not the same communication design.
Cost per signed case and settlement cycle time on one side; realization, write-down rates and carrier scorecards on the other. Building one dashboard set for a multi-practice firm satisfies neither.
Every Litify build shares the same spine. A prospective case arrives as an Intake on a client account, screened through a questionnaire. Once signed it becomes a Matter, whose Case Type selects the Matter Plan of stages and tasks, and whose parties are linked as Roles. Work on the matter produces requests, negotiations, resolutions and expenses on one side, and time entries and invoices on the other. Documents live against the matter. That is true for a personal injury firm in Texas and an in-house team in London.
What changes is every decision layered on top: which case types exist and how they are organised, what the stages mean, which tasks matter and when they are due, what is captured at intake, how billing is structured, what the client sees, and what leadership measures. Those decisions are the build — and they differ more between practice areas than most firms expect before they start.
It is also why moving between practice areas is not free. A firm adding insurance defense work to a plaintiff practice is not adding case types to an existing model; it is adding a second operating model that shares objects with the first. Designing for that up front is much cheaper than discovering it in year two.
The lead record and its questionnaire, screened and converted on sign-up.
The case: the hub every document, task, entry and party attaches to.
The spine — it selects the questionnaire, the plan, and every reporting dimension.
Templated stages and tasks per case type, assigned by role on opening.
Defendants, insurers, opposing counsel, providers and the matter team.
Entries checked at capture, pre-bills, mass billing, LEDES where required.
Folders and files on the matter, or a connected DMS such as iManage.
Incoming and outgoing cases moving between firms, with attribution intact.
The number of operating models a firm runs matters more to the build than its headcount. Be honest about which of these you are, including where you intend to be in three years.
The cleanest build. Every decision optimises for one set of economics, and nothing is compromised to accommodate a second practice that works differently.
Watch for Building so tightly to one practice that adding a second means starting over. We design the taxonomy with headroom even when you only need one today.
Where most mid-size firms are. The work is deciding what genuinely must differ between practices and what can be shared — and resisting the urge to standardise things that should not be.
Watch for Forced standardisation. Two practices made to share one stage model produces a model neither follows, and the pipeline data goes with it.
Adding defense work to a plaintiff firm, or an immigration arm to a general practice. The existing configuration was not designed for it, and pretending otherwise is the expensive path.
Watch for Bolting the new practice onto the old case type list. It works for a quarter and then reporting stops meaning anything for either practice.
| Configuration area | How it differs by practice | Emphasis |
|---|---|---|
| Intake | Plaintiff: a conversion funnel with marketing attribution and speed-to-contact. Defense: carrier assignment with conflict clearance first. Immigration: eligibility screening. In-house: a request portal for the business. | Diverges |
| Matter plans | Plaintiff: treatment monitoring, records requests, demand. Defense: pleadings, discovery, depositions, experts, mediation. Immigration: per visa type. In-house: by request category. | Diverges |
| Billing | Plaintiff: contingency, costs and settlement disbursement. Defense: hourly against carrier guidelines with LEDES eBilling. Immigration: flat fee with online payment. In-house: reviewing inbound invoices. | Diverges |
| Documents | Immigration needs completeness checklists that gate a filing. Plaintiff needs records and bills feeding damages. Defense needs discovery organisation. Different structures, same object. | Diverges |
| Roles and parties | The same structure everywhere — defendants, insurers, opposing counsel, providers, the matter team. What changes is which roles are mandatory and which drive automation. | Mostly shared |
| Core objects | Intake, Matter, Case Type, Matter Plan, Role, Time Entry, Invoice. Identical in every build, which is what makes a multi-practice org possible at all. | Shared |
Below is the configuration that genuinely differs. Where a practice is not listed, it usually sits closest to one of these four — and we will say which.
Economics: case selection and settlement velocity. The build optimises for converting the right intakes fast and moving them to resolution without dead time.
Economics: realization. Work arrives by assignment, so the build optimises for compliant billing and standardised matter handling across a carrier panel.
Economics: throughput at accuracy. The build optimises for document completeness and filing correctness, because a missing item stops everything.
Economics: spend control and responsiveness. The build optimises for triaging what the business asks for and controlling what outside counsel charges.
The hardest build, because two economic models share one org. The work is deciding what must differ and resisting the urge to standardise what should not.
Adding a practice to an org that was not designed for it. Done deliberately this is a project; done by accident it quietly degrades reporting for both practices.
These come up in every build. The point is not that one answer is right — it is that the right answer depends on economics your configuration should reflect deliberately.
Plaintiff: a conversion funnel where speed-to-contact predicts signing. Defense: an assignment inbox where conflict clearance comes first. Immigration: eligibility screening. In-house: a request portal for the business to use.
Changes The questionnaire, the routing rules, the SLA clocks and what "conversion rate" even means.Contingency work is decided at case selection and settlement speed. Hourly carrier work is decided at the point a time entry is written. Flat-fee work is decided by throughput. Three different levers entirely.
Changes Whether the build invests in intake scoring, in guideline enforcement, or in document automation.Statutes of limitation, court and discovery schedules, or filing windows and priority dates. Different sources, different calculation bases, different people who own the rule.
Changes The date logic, the warning intervals, the escalation path and who is authorised to override.Evidence feeding damages, discovery to be organised, or a checklist item that gates a filing. The same file plays a materially different role in each practice.
Changes Folder structure, classification, whether completeness is enforced, and what blocks progression.An individual who needs reassurance over two years, an applicant who needs a checklist and a portal, or a carrier who needs compliant bills and a scorecard. Not the same relationship at all.
Changes Communication cadence, portal design, status visibility and what the client can see of the matter.Cost per signed case and settlement cycle time; or realization, write-down rate and carrier performance; or filings completed per head. Each produces a different dashboard set.
Changes The metric definitions, the date basis behind them, and which numbers get a named owner.The sequence is the same for every firm. What changes is the architecture phase, where your practice's economics decide most of the design.
How your practice actually runs a case, and what makes a matter profitable in your economic model. The second question shapes more of the build than the first.
Case type taxonomy, stage models, billing structure and metric definitions — all of them decided against your practice's economics rather than a template. Signed off before any build.
Configuration first, code only where it cannot reach. Built in a sandbox and tested against real matters from your own history.
Data migration with a reconciliation pack you can audit, role-based training, and a parallel run so live matters and deadlines are never at risk.
Adoption measured rather than assumed, then the next tranche — a second practice area, an integration, or AI once the data supports it.
If you are planning a second practice area Say so during discovery even if it is three years away. Designing a case type taxonomy with headroom costs almost nothing at the start and a great deal later — a firm that adds insurance defense work to a plaintiff build is adding a second operating model, not a few case types, and a taxonomy built for one practice will not absorb it cleanly. This is the cheapest piece of foresight available in a Litify build.
We build for all four. The useful first question is which economic model your firm actually runs on, because that decides nearly everything else.
Where volume, case selection and settlement velocity decide profitability, and intake is a genuine acquisition channel with a cost per signed case.
Where work arrives by assignment and profitability is decided at the point a time entry is written, against guidelines somebody else set.
Where throughput at accuracy is the whole business, document completeness gates every filing, and the client needs visibility without a phone call.
Where the job is triaging what the business asks for and controlling what outside counsel charges, and the CFO is a stakeholder in the reporting.
Two engagements from our legal practice — a multi-state personal injury firm and a 150-person family law firm. Different economics, different builds, the same architecture discipline.
Twopir provided Salesforce customisation and integration services to help us build a robust, compliant, and scalable legal operations platform — connecting case management, document processing, and financial systems into one unified workflow. The result was transformative for how we run case-to-cash operations.
Streamlining case-to-cash operations with Salesforce, AWS and QuickBooks.
Twopir's specialized Salesforce customization enabled efficient integration of third-party systems and streamlined administration and billing, leading to seamless financial operations and enhanced productivity. Automated mass billing and matter management minimized errors across our entire legal workflow.
A 50% efficiency gain from Accounting Seed and Salesforce integration.
The question that shapes a Litify build is not what kind of law you practise. It is what makes a matter profitable in your model — and the answer differs more than most firms expect.
Before case types, before stages, before anything. Contingency, hourly-against-guidelines and flat-fee work have completely different levers, and the build should invest where your economics actually are.
Case Type drives the questionnaire, the matter plan and every integration that creates an intake. Getting it wrong is the single most expensive mistake in a Litify build, because every report and automation downstream inherits it.
Even when you only need one today. A taxonomy built for a single practice will not absorb a second one cleanly, and retrofitting it once matters are live is the expensive path.
It is a strong platform for matter-centric practices with real operational complexity. For a two-person firm with simple hourly billing there are lighter tools, and we would rather say that than sell an implementation.
We help growing and mid-market companies solve complex CRM, integration and business system challenges, and we serve enterprise organizations with the same architecture discipline. Firms at that stage need a system that survives the next three years of growth — not one built for the org chart they had last year.
This page covers one service. Each one below goes into the detail a specific team needs — pick the one closest to the question you arrived with.
Litify suits matter-centric practices with real operational complexity — plaintiff and personal injury, mass tort, insurance defense, immigration, and in-house legal departments are the four models it is explicitly built around, and it works well for multi-practice firms that need more than one of them in a single system. It is less obviously the right answer for a very small firm with straightforward hourly billing and few matters in flight, where lighter tools do the job with less configuration. We would rather tell you that in a first call than sell an implementation you will outgrow in the wrong direction.
Almost everywhere except the objects. Plaintiff work optimises for case selection and settlement velocity: intake is an acquisition funnel with marketing attribution and a cost per signed case, matter plans centre on treatment monitoring, records requests and demand preparation, and billing is contingency with costs and settlement disbursement. Defense work optimises for realization: work arrives by carrier assignment so conflict clearance comes first, plans are standardised across a carrier panel around pleadings, discovery, depositions and mediation, and billing is hourly against carrier guidelines with LEDES eBilling and write-down scorecards. Same data model, materially different system.
Yes, and most mid-size firms do. The work is deciding what genuinely must differ between practices and what can be shared — and resisting the urge to standardise things that should not be. Two practices forced to share one stage model produces a model neither team follows, and the pipeline data goes with it. A good multi-practice build has a case type taxonomy with a real hierarchy, separate stage models where the work genuinely differs, shared components where they fit, billing that supports more than one economic model, and dashboards per practice plus a firm-wide view.
The emphasis shifts to completeness and accuracy rather than conversion or realization. Matter plans are built per visa type — family, student, corporate, PERM — with document checklists that gate a filing rather than merely tracking it, form auto-fill from data captured at intake so the same information is not re-entered, and priority date and filing window tracking. A client portal carries much of the communication load, with document upload and status visibility, and billing is usually flat fee with online payment rather than time-based.
Harder than adding case types, which is the mistake to avoid. A new practice area is a second operating model: different economics, different stage definitions, often different billing. Bolting it onto the existing case type list works for a quarter and then reporting stops meaning anything for either practice. Done properly it means making the current model's assumptions explicit, identifying where the new practice genuinely conflicts, extending the taxonomy without breaking existing reporting, and assessing the migration impact on live matters. Tell us during discovery if a second practice is coming, even years out — designing headroom costs almost nothing up front.
Yes, though the build looks quite different. The job shifts from running cases for clients to triaging what the business asks for and controlling what outside counsel charges. That means a legal service request portal the business actually uses, triage and routing by request category, outside counsel collaboration on matters, invoice review against billing rules and budgets, multi-currency eBilling where the company operates internationally, and spend dashboards that finance will accept. The core objects are the same; the emphasis and the reporting audience are not.
A focused implementation — core matter management, intake automation, billing setup and baseline reporting for a single practice area — typically runs 6 to 10 weeks. Multi-practice builds add four to eight weeks, and the extra time is design rather than configuration: reconciling how two practices want the same object to behave. Litify AI configuration, external integrations and complex workflow logic each extend it further, as does migrating from a system whose data was never clean. We profile your source data during discovery and give you a realistic range then.
A first conversation covers your economic model, how your practice actually runs a case, and what that means for the build. If you run more than one practice, bring both perspectives — that is where the design decisions are.
Plaintiff · insurance defense · immigration · in-house · multi-practice
