How a law firm automation project runs

The project runs in six steps: process check, fixed-fee proposal, build, testing with real matters, handover and operations. Each step ends with something the firm can review before deciding on the next one.

The durations below are typical ranges for one contained system in a firm with 1 to 10 lawyers. Larger replacements of legacy systems are split into stages, so part of the value arrives early.

In two weeks we map how intake, deadlines, documents, billing and data transfer between systems actually run in your firm, measure where the hours go, and deliver a ranked list of candidates with effort and benefit.

The list includes the honest negatives: workflows that happen too rarely, that a setting in your existing software already solves, or that should be fixed as a process before anyone automates them. The fee is fixed and is credited against a later project, so the check does not cost extra if you go ahead. On our services page it appears as the process audit.

The proposal fixes in writing what will be built, how it will be accepted, what is excluded and the price, before any build work starts. If we underestimate the work, that is our cost, not an addition to your invoice.

It also records the points a firm's professional duties call for when an outside provider touches client information. ABA Formal Opinion 512, drawing on earlier outsourcing opinions, lists confidentiality agreements, the vendor's security policies and a forum for enforcing the agreement among the things to check. Rule 5.3 Comment 3 makes the extent of a lawyer's duty depend partly on the terms protecting client information.

We build inside the systems you already use, in your own tenant, and keep the new workflow separate from live matters until testing is complete. Your staff keep working as before while the build runs.

Where your practice management system offers an API, the new system uses it; otherwise we work with the exports or databases available. A short weekly check-in with your contact person replaces long status meetings, and questions that need a lawyer's judgment are collected and answered in one go. The principle stays fixed throughout: software prepares, a person decides.

The system is tested with cases taken from your real matters, including the awkward ones, and accepted only when the agreed test cases pass and a responsible attorney signs off.

Good test sets include a matter with a potential conflict, a deadline with an unclear service date and an inquiry that should be rejected. The expected behaviour is written down in advance: a possible conflict is shown to an attorney and never opens a matter automatically, and an unclear deadline is flagged rather than calculated.

Real matters mean real client information, so testing happens in your environment under the same confidentiality terms as the build. Rule 1.6 Comment 18 describes the reasonable-efforts standard that applies to safeguarding that information.

The firm provides one contact person, admin access to the relevant systems, a set of real test cases and a lawyer's time for decisions and final sign-off. You do not need technical knowledge or preparation beyond that.

If none of these can be made available in the coming weeks, the honest answer is not yet. A project without a contact person or test cases tends to produce a system that nobody trusts.

At handover you receive the source code, the infrastructure and the documentation, and the system runs in your environment. Because you own all three, another developer could maintain it without us.

After go-live you choose between a monthly operations arrangement, with monitoring, maintenance, extensions and agreed response times, and small fixed-fee follow-ups when something changes. Either way, the firm remains responsible for its professional obligations: in England and Wales, paragraph 2.3 of the SRA Code of Conduct for Firms keeps the firm accountable where work is carried out through others.