Case studies
Anonymised project stories and illustrative scenarios for better workflows, useful AI and clearer management decisions. Explore the change, then see the stack.
Explore the areas of changeStart with the work. See the software in each story.
Project stories, working demonstrations and clearly labelled illustrative scenarios.
36 of 36 examples
Large tasks combined several pieces of work. The redesign split them into linked steps, with the resources and precedents needed along the way.
Matter roadmaps were revised into smaller linked tasks, with process schedules, resources and training.
Finding a confident paragraph is easy. This design makes the underlying source, its date and the limits of the answer part of the working view.
A proposed research workflow would place the answer, supporting passages and unanswered questions together for a lawyer to review.
An illustrative precedent workflow gives shared matter facts one owner, then uses them to prepare a document pack with a deliberate review step.
A reusable document pack prepared from reviewed matter details, with missing information and exceptions visible before approval.
A practice wanted to explore AI for legal work. Discovery led to a clear condition for the next step: a firm-wide policy before broader testing.
The client agreed in principle to a pilot group, with an AI policy required before it proceeded.
A marked-up contract can contain plenty of changes without explaining what matters. This scenario organises the review around the client's agreed positions and the exceptions requiring judgement.
The designed review would produce a clause-by-clause issues list for a lawyer to assess against an approved playbook.
A document-review design separates changed wording from the questions that need an instruction, an owner or a negotiated response.
Each material amendment has a recorded position, responsible reviewer and next action alongside the comparison copy.
The practice wanted practical changes to its existing system. A new intake form, a task-list review and training gave the work a concrete starting point.
A client intake form was built, the task list was reviewed, and training sessions were delivered. Staff were invited to comment before the task-list review.
Dates scattered across documents can look settled once they enter a table. This design keeps conflicting accounts and missing evidence visible as a chronology takes shape.
A proposed chronology would distinguish supported events, conflicting accounts and questions requiring further work.
This document-production scenario works back from the reader: a clear index, traceable source files and a separate check of references before release.
A reviewable bundle with a source inventory, agreed order and a final navigation check by someone other than its preparer.
Document automation needed more than a software decision. The work moved precedents through coding and back to the practice for testing.
A completed precedent list was returned for testing, alongside work on the practice’s existing system and workflow tools.
A long file summary can still leave the next lawyer wondering what to do. This scenario builds the handover around current decisions, commitments and the next pieces of work.
The intended handover would give the receiving lawyer a reviewed account of the matter's position and the actions needing attention.
An illustrative WIP view sorts work by the decision holding it back, so a billing discussion can end with an owner and a practical next step.
A WIP review organised around billing readiness, unresolved questions and authorised decisions rather than a balance alone.
Leadership needed reports it could use in management discussions. Building the views also exposed decisions about what fees, WIP and debtor figures should mean.
Partner and quarterly review dashboards were delivered for review. Calculation and display rules remained part of the review.
Several people can be working hard on a matter while a crucial handover waits. This design makes responsibility visible at the point where work moves between people.
The proposed roadmap would connect each handover to an owner, an expected output and a clear acceptance step.
This reporting design makes the definition, timing and source of each figure visible before the team debates which report is right.
A management view with explicit metric definitions, a visible reporting period and a repeatable reconciliation back to source records.
The software review centred on matter progress and staff workflow. Existing process maps became evidence to test, rather than an automatic specification for a rebuild.
The supplied workflow maps were technically reviewed. Platform fit and proposed AI use cases remained under assessment.
A matter can advance on a dashboard while essential documents or instructions are still missing. This scenario gives each stage a practical entry requirement.
The designed process would make the required documents, instructions and approval visible before a matter changes stage.
An illustrative workload view looks beyond open-matter counts to the next stage of work, its dependencies and the people available to do it.
A team review that separates active work, blocked work and upcoming commitments before allocating the next tasks.
A technology review became more concrete when the practice could enter demonstration environments and discuss how client and matter work would fit together.
Working demonstration environments and workshops informed a circulated technology review and subsequent implementation planning.
A quiet matter may be waiting for a good reason or may have lost its next step. This design gives the team a way to tell the difference.
A proposed review queue would bring stalled work, legitimate waiting periods and missing next actions into the same management conversation.
A connected-data scenario defines which system owns each client field and sends ambiguous matches for review before records are linked or changed.
A field-ownership and matching process that keeps uncertain identities out of automatic updates and makes handover exceptions visible.
The platform move continued into the work of billing: reviewing WIP and disbursements, agreeing a write-off process and refining invoice templates.
The firm went live on Actionstep. Post-live work addressed billing processes, reporting differences and invoice templates.
New instructions can alter the work without changing the task list or billing assumptions. This scenario gives a scope change a clear route into the matter plan.
The proposed change process would connect new instructions to reviewed tasks, responsibilities and billing assumptions.
This proposed workflow turns a permitted recording or transcript into a reviewable note, with the responsible person checking its meaning and destination.
A draft call note with a source reference, a named reviewer and a checked matter association before filing.
Intake forms, appointment booking and matter configuration were built as parts of the same engagement, with templates, custom fields and training around them.
Clio Grow intake and Clio Manage matter configuration were delivered, with training and post-live support.
The client has explained the problem, but the next person asks for it again. This scenario designs the enquiry-to-matter handover around the information already supplied.
The intended handover would preserve reviewed enquiry information and make additional questions explicit when a matter is opened.
An illustrative handover gathers the accepted instructions, required checks and working documents into a reviewable package before opening the matter.
An approved enquiry-to-matter handover with required information, document references and responsibility for unresolved items.
The practice-management decision depended on how the firm would access its documents. The work paired a trial migration with a document-management rollout and training.
Clio and NetDocuments went live, followed by document-system training and support.
A call can be recorded without anyone owning the response. This scenario gives unanswered enquiries a responsible person, useful context and a visible next action.
The proposed response queue would connect an unanswered enquiry to an assigned follow-up and a recorded disposition.
A training design follows the work each person needs to perform, using fictional matters and a place to record questions that the guide does not answer.
Role-specific practice sessions, short task guides and an owned issue list for the first period of use.
A synthetic demonstration brought chronology, document categories and people into a working matter view, so the proposed experience could be examined.
A navigable matter-intelligence concept was built and checked using synthetic matter and caseload material.
A prospective client may be ready to upload their whole file before the firm has decided what to accept. This design stages the intake around access, review and the next appropriate request.
The proposed intake would separate initial screening information from later document collection and engagement steps.
This governance scenario gives approved AI use a defined task, permitted information and a review rule before a draft is used in professional work.
A practical AI-use guide linking each approved task to its information rules, required checks and responsible reviewer.
A demonstration connected a guided website, a scoped AI guide and structured intake. Staff-side examples made the intended review handover visible.
The website, intake form display and AI guide were tested as a working demonstration.
One general form often asks too much of some clients and too little of others. This scenario uses a short guided path to prepare a more useful first conversation.
The designed intake would adapt its follow-up questions to the person's request and prepare a structured brief for staff review.
An access-and-handover design treats departure as a review of live responsibilities, shared documents and system access rather than an account closure alone.
An approved departure checklist that reallocates active work, checks shared access and records the actions completed in each system.
Client names and identifying details are withheld. Illustrative scenarios combine common practice needs and suggested stacks. They do not describe a single client or claim measured results.
Bring the process that keeps causing work. We can help you decide what to change first.