How should a law firm choose a system for case and office workflows?

Start with the daily matter journey

A law-firm management system should reflect how work moves between intake, lawyers, assistants, billing, and management. Describe the journey from the first enquiry through client onboarding, matter creation, documents, appointments, tasks, billing, closure, and archiving. This exposes the data and decisions the team actually needs.

Do not make a generic feature list the basis for buying. Ask where each item is recorded, who reviews it, what changes its status, and which report a partner or office manager needs. Some needs may fit configuration; others may need custom work or an integration. The supplier should state that boundary in the proposal.

• One clear record for each client, matter, and file.
• Known states and ownership for each step.
• Search and reports that support daily management.

Clients, matters, and linked records

Define the relationship between a client, matter, opposing party, and responsible lawyer. A client may have several matters, and a matter may contain several parties or document types. Ask for searchable fields such as internal ID, matter type, branch, owner, status, and creation date, with a clear owner for editing each field.

Use internal IDs in training and testing. The following example is entirely fictional and does not represent a real case or legal date.

Fictional example: from enquiry to a trackable matter

Run this demo using only the fictional identifiers above. The review date is an internal test date, not a legal deadline. Each handoff follows the responsible person’s decision under the firm’s procedures.

Documents, versions, and activity history

Request folders linked to clients and matters, with a filename, tags, version, and owner. The team should distinguish a draft from a client upload and an approved office copy. Ask about preview, download, search, activity history, and who can share or delete a file. Storage alone does not describe a document workflow.

Define the retention and backup policy the firm wants with appropriate professional advice, including who restores data. A system by itself does not promise legal or regulatory compliance.

• Trackable versions, filenames, and tags.
• Role-based download, sharing, and deletion permissions.
• An activity history for changes and file actions, subject to the proposed plan.

Appointments, tasks, and important dates

Bring meetings, internal work sessions, follow-ups, and dates entered from approved sources into one operating view. Separate an operational reminder from a legal date or formal deadline that requires human verification and a reliable source. Do not rely on a system to interpret law or calculate the effect of a date.

Ask for an owner, status, review date, activity history, and configurable notifications for each task. Test what each role sees when a task is late or reassigned, and what happens if email or another notification fails. A reminder does not prove that a deadline will never be missed.

• Personal and team calendars with permission controls.
• Tasks linked to a client, matter, and document.
• Notifications plus human review and a recorded date source.

Billing and expenses

Define what the system should manage: fee estimates, time records, expenses, invoices, payments, or internal profitability reporting. Request separate permissions for time entry, invoice review, and reporting. If the system connects to an accountant or payment provider, document the data exchanged and who owns reconciliation and support.

Ask for examples covering cancellations, edits, and partial payments, plus data export if the firm changes systems. Test calculations with sample data. A screen or feature description does not prove that the system fits the firm’s approved accounting practices.

Access, privacy, and account administration

Separate access by role and practical need: intake, lawyer, assistant, accountant, partner, and administrator. Ask about multi-factor authentication, login and activity logs, user suspension, account recovery, encryption in transit and at rest, and hosting location. Request a precise description of what the proposed plan actually includes rather than a general security promise.

Define who owns accounts, backups, and recovery, how temporary supplier access is granted, and how it is removed when a staff member leaves. Review the privacy terms and contract with suitable professional advice; this article is not legal advice and does not establish compliance.

• A role and permission matrix that can be reviewed.
• Joiner, leaver, and permission-change procedures.
• Written backup, incident, and access-recovery responsibilities.

Migrating data from current files

Inventory the sources: spreadsheets, email, folders, a legacy system, and paper files that require entry. Assign an owner to each source and decide what moves, what is archived, and what is excluded. Request a mapping that shows how columns, records, and files will appear in the new system, including duplicate and missing-field handling.

Run a pilot with a sample, then review it with users. Agree on a pre-import backup, an error report, and a post-import check. Do not delete the old source until the result is accepted and the agreed export and recovery path has been demonstrated.

Training, handover, and operations

Request role-based training built around firm scenarios, with test accounts and short reference material. Have a representative of each role complete their permitted step in a shared journey: create a client, open a matter, upload a document, create a task, record a payment, and run a report. Capture questions and decisions so they become internal procedures.

Define handover access to accounts, data, backups, configuration, and administration guidance, together with post-launch support scope. Ask for the support channel and response expectations for defects and questions, plus the process for adding users or changing permissions.

A supplier request checklist

Send the same document to every supplier and request answers against a defined scope. The following are requirements to verify with a supplier, not a list of current Mawaqe3 features:

• Ask which version or plan the quotation prices.
• Request a demo or reference flow with fictional data; do not send real client data for a demo.
• Record decisions, assumptions, and each owner in the procurement file.

Frequently asked questions

Do we need a custom system? Not necessarily. Compare the firm’s workflow, fields, permissions, and reports with the ready-made option, then price the gaps before deciding.

Can we start with clients and tasks only? Yes, if the first phase, deferred work, stable IDs, and later data path are explicit.

Can a system guarantee that no date will be missed? No. It can organise tasks and notifications according to its design, but people still review dates, ownership, and sources.

How should we start? Write one matter journey with fictional data, ask the supplier to demonstrate it, and request a scope, cost, and acceptance criteria. Mawaqe3 can help turn your office procedures into comparable requirements.