Firms rarely struggle with Litify because the software is missing something. They struggle because nobody ever wrote down what a stage means, who owns a matter between sign-up and first filing, or which date starts the clock. We run that decision process and hand you the answers as documents your team can argue with. The deliverable is a decided operating model, not a configured org.
Trusted by 500+ organizations — including law firms and legal technology companies building their case, billing and reporting operations on Salesforce with Twopir Consulting.
Advisory Capability
Every one of these is a decision problem wearing a software costume. Building before they are settled just encodes the confusion into an object model, where it is much more expensive to fix.
And both are right about their own practice. Until someone reconciles that into a single stage model — or decides explicitly that the two practices get different ones — any configuration will satisfy neither of them.
Is it at sign-up, at first substantive work, at first filing? Three answers means three different cycle-time numbers, and a leadership team that stops trusting all of them. This is a definition problem, not a reporting problem.
The delay is almost never the task itself. It is the gap after a paralegal finishes and before an attorney picks it up, because nobody defined who owns the matter in between or what triggers the handoff.
Someone added a type for a single unusual matter, then another, and now there are forty with no hierarchy. Reporting by practice area becomes impossible and every new matter plan is a copy of the last one.
A senior paralegal knows the real rule for every jurisdiction. That knowledge is not written down, is not in the system, and leaves when they do. Encoding it starts with extracting it, and that is an interview problem.
Without an agreed unit of work and an agreed definition of active, workload conversations run on anecdote. Staffing decisions get made on who complains loudest rather than on what the matters actually require.
Case management consulting is the work of deciding how your firm should run a matter before anyone configures software to do it. We map how cases actually move today, surface the disagreements that are usually invisible, run the decisions to a conclusion with the people who have to live with them, and write the result down in a form a build team can act on.
It is deliberately vendor-neutral in its reasoning even though it is Litify-aware in its output. The taxonomy and lifecycle we design would be valid if you changed platform tomorrow; what makes it Litify-specific is that we express it in the platform's own structures — Case Type, Matter Plan, stages, tasks and Roles — so nothing is lost in translation when the build starts.
This engagement does not configure anything. That is the point. Firms that have been burned before usually have a system built on decisions nobody remembers making, and the fastest way out is to make the decisions properly and separately, with the reasoning written down.
Shadowing real work rather than interviewing about it. What people do and what they say they do usually differ.
Where two teams run the same process differently, and whether that difference is worth preserving.
A case type tree with a hierarchy, a rationale, and a rule for what earns a new type.
What each stage means, what moves a matter into it, and who is accountable while it sits there.
The gaps between roles, made explicit — with a trigger and an owner for each one.
Getting the rules out of senior heads and into a form that can be automated.
What each number means, which date drives it, and who will be asked about it.
An honest read on whether the firm will actually adopt what it just designed.
The engagement is the same shape in all three cases; what changes is how much of the answer already exists and how much disagreement has to be surfaced first.
You want to know what your operating model should be before you commit to a platform, so the evaluation is about fit rather than feature lists.
Deliverable Documents you own outright. If you choose a different platform, or a different partner, the thinking still holds.
The most common and the most valuable moment. Three to five weeks here routinely takes weeks out of the implementation and takes the biggest risks off the table entirely.
Deliverable A specification the build team works from — ours or anyone else's. It is written to be handed over, not to lock you in.
When the system is technically fine but operationally wrong. Usually the design was never decided, so configuration encoded whatever the loudest person wanted that week.
Deliverable Often runs alongside an audit. If the problem turns out to be technical rather than a design question, we will say so and point you there instead.
Everything here is a document your firm keeps. None of it depends on us doing the build — that independence is deliberate, and it is what makes the advice worth taking.
How a case actually moves today, including the spreadsheets, the shared inbox and the paralegal who remembers everything. The workarounds are the most useful data in the engagement.
A tree rather than a list: practice area, matter type, sub-type, with a stated rule for what earns a new entry and what should be a field instead.
What each stage means in plain language, what moves a matter into and out of it, and who is accountable while it sits there. One model per practice area where they genuinely differ.
The gaps between people made explicit. Most lost time in a law firm lives in a handoff nobody owns, and naming it is most of the fix.
Structured interviews that get jurisdiction and case-type rules out of senior heads and into a form that can be automated and checked.
Every number leadership wants, defined before anyone builds it: the wording, the source field, the date that drives it and the person who will be asked about it.
This is where the work actually happens. Each session has a named decision to reach and the right people in the room — a workshop that ends without a decision is a status meeting.
We sit with the people doing the work. What a firm describes in a requirements meeting and what happens on a Tuesday afternoon are reliably different, and the difference is where the design problems live.
Produces An honest current-state map, including the shadow systems nobody mentions in interviews.Where two teams do the same thing differently, we put both versions on the wall. Half of these differences are historical accident and collapse immediately; the other half are real and need separate models.
Decides Which process differences are preserved as designed variants and which are standardised away.The single highest-leverage hour of the engagement. Case Type drives the questionnaire, the matter plan and every integration that creates an intake, so it gets a dedicated session with the people who will report on it.
Decides The case type tree, the rule for adding to it, and what belongs in a field instead.Stage definitions and the gaps between them, worked through practice area by practice area. We push hard on entry and exit criteria, because a stage without them becomes a status field people set from memory.
Decides The stage model, accountable roles, handoff triggers and escalation thresholds.Structured sessions with the people who actually know the rules. This is the part firms most often skip and most often regret, because the knowledge is concentrated in very few heads.
Produces A documented rule set per practice and jurisdiction, with calculation bases and override authority.The last two sessions: agreeing what each number means before it exists, and an honest conversation about whether the firm will adopt what it has just designed.
Produces The metric dictionary, the prioritised build backlog, and a change readiness view leadership can act on.Short, intensive and heavy on your people's time in weeks one and two. We would rather compress the disruption than spread it across a quarter.
Shadowing sessions across every role that touches a matter. We watch real work on real files rather than running requirements interviews, because the gap between the two is the finding.
Variance workshops that put competing versions of the same process side by side. Most of the disagreement in a firm is invisible until someone draws both versions on a wall.
Facilitated sessions with a named decision to reach in each. Taxonomy, stage model, roles and handoffs, deadline rules — each one closed before we move on.
The taxonomy document, the lifecycle map and the metric dictionary, written to be handed to a build team. Plain language, with the reasoning kept so future decisions have context.
A prioritised build backlog and an honest change-readiness view. If we are also doing the build, this is where implementation discovery starts from — several weeks ahead.
What this engagement does not do It does not configure anything, migrate anything or produce a working system. If what you need is a build, go straight to implementation and we will fold a compressed version of this into its discovery phase. This standalone engagement is for firms where the disagreement is real enough that deciding it deserves its own space — and for firms who have been burned by a build that started before anyone agreed what it was for.
Different reasons, same underlying problem: a decision that needs making by someone with the authority and the time to make it properly.
Accountable for a system nobody agreed the requirements for, and needing a defensible basis for the decisions before committing budget to a build.
Whose team works differently from the rest of the firm for good reasons, and who wants those reasons understood rather than standardised away by default.
Who wants numbers they can trust and has worked out that the reporting problem is really a definitions problem that has to be settled first.
Inside the firm, holding a backlog of contradictory requests, who needs the underlying disagreements resolved rather than arbitrated one ticket at a time.
Two engagements from our legal practice. Both began with the operating model rather than the configuration — which is why the numbers below are about how the firm runs, not about software.
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 test of this engagement is whether the documents are still useful if you pick a different platform, a different partner, or a different sequence. We write them so they are.
The taxonomy, lifecycle map and metric dictionary are written to be handed to any build team. We would rather do your build, but the advice has to be worth taking even if you give it to someone else — otherwise it is a sales document.
Requirements meetings produce the process people believe they follow. Sitting with a paralegal for a morning produces the one they actually follow. The gap between them is where the design problem lives, and you only find it by watching.
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.
Some problems are staffing, some are incentives, some are one partner who will not use any system. We name those rather than designing around them, because a build cannot fix them and pretending otherwise wastes your money.
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.
Case management consulting decides what your firm's operating model should be; implementation builds it. This engagement produces documents — a case type taxonomy, a lifecycle and stage model, a metric dictionary — rather than a configured org. It exists because the decisions underneath a Litify build are firm decisions, not software ones: what a stage means, who owns a matter between handoffs, which date starts a clock. Configuring before those are settled just encodes the confusion into an object model, where it is far more expensive to fix.
Not always. If your firm has one practice area, broad agreement on how a case runs, and a decision-maker who can answer design questions quickly, the compressed version inside implementation discovery is enough. This standalone engagement earns its place when there is real disagreement to resolve — several practice areas that work differently, a case type list that grew by accident, or a previous build that failed for reasons nobody can quite articulate.
Three to five weeks, and it is front-loaded: weeks one and two need meaningful time from the people who actually do the work, including shadowing sessions. We would rather compress the disruption than spread a light touch across a quarter. Later weeks are facilitated decision sessions with a smaller group, typically two to three hours each with a named decision to reach in every one.
Three documents and a backlog. The case type taxonomy, with the hierarchy and the rule for what earns a new type. The lifecycle map, with stage definitions, entry and exit criteria, accountable roles, handoff triggers and the extracted deadline rules. The metric dictionary, defining every number leadership wants before anyone builds it. Plus a prioritised build backlog and an honest change-readiness assessment. All of it is written to be handed to any build team.
The reasoning is vendor-neutral; the expression is Litify-aware. The taxonomy and lifecycle we design would be valid if you changed platform tomorrow. What makes the output Litify-specific is that we write it in the platform's own structures — Case Type, Matter Plan, stages, tasks, Roles — so a build team can act on it without a translation step. Firms still choosing a platform often use this engagement to work out what they actually need first.
Possibly, and possibly an audit is. The distinction is whether your problem is a design question or a technical one. If two partners describe the same process differently, or nobody can agree what "open matter" means, that is this engagement. If automation is firing in the wrong order or a integration keeps failing silently, that is an audit. Often it is both, and we will tell you which one to start with rather than selling you the longer engagement.
We can, and most clients do continue with us — but the engagement is priced and scoped so that it stands alone. The documents are written for handover to any build team. That independence is what makes the advice worth taking: a recommendation you can only act on by hiring us for the next phase is a sales document, not advice.
A first conversation covers how your firm runs a case today, where the disagreements are, and whether this engagement or a straight implementation is the right next step. We will tell you if you do not need it.
Observation · variance mapping · facilitated decisions · documented handover
