AI for U.S. Law Firms: A Buyer’s Guide to Intake Systems

A U.S. law firm evaluating an AI intake system should judge the complete operating path, not the demonstration. The requirements should cover approved questions, prospective-client information, conflict-review gates, jurisdiction-specific rules, accountable human handoffs, failure behavior, records, supervision, and measurable acceptance criteria.

Many products can answer a call, summarize a conversation, or place an appointment on a calendar. Those capabilities matter, but they do not prove that the system is suitable for a law firm. The real purchase is a controlled path from first contact to the next qualified decision.

That path varies by practice area, state, office structure, referral model, and the information the firm permits a prospective client to share. A criminal-defense inquiry, an estate-planning request, an existing-client question, and a referral from another lawyer may all begin on the same phone number while requiring different language, urgency, records, and reviewers.

Buy the operating path the firm can supervise, not the voice or interface that performs best in a demonstration.

Define the decision before comparing products

The first question is not which vendor has the longest feature list. It is which customer moments the firm intends to improve. A narrow, explicit decision produces a better evaluation than a broad request to “add AI.”

Choose the first job the system must perform

• Acknowledge new inquiries after hours and explain the next administrative step.
• Separate new matters, existing-client requests, referrals, and general information.
• Collect the minimum approved facts needed for an initial human review.
• Identify a time-sensitive signal and create the firm’s approved escalation task.
• Schedule only the consultation types the firm has authorized for that route.
• Follow up on an incomplete administrative step without creating pressure or a professional promise.

A firm may eventually connect several of these jobs. The first purchase should still have a defined starting boundary. That makes the system easier to test, supervise, and improve.

Write the professional boundaries before the script

Prospective-client intake starts before the firm has accepted a matter. The ABA Model Rule 1.18 page on duties to prospective clients explains that duties may arise from information learned during a consultation about possible representation, even if no attorney-client relationship follows.

The rule is a model rule. State and local rules, court requirements, firm policy, privacy obligations, and the facts of the use case control the final design. The firm should decide what the system may collect, what it must avoid, where information may be stored, how long it is kept, who may see it, and when a qualified lawyer must take over.

Keep these decisions outside the automated boundary

• Whether the firm will represent the person.
• Whether a conflict exists or has been cleared.
• Whether a legal deadline applies and how it should be calculated.
• Whether the firm is competent, available, or permitted to handle the matter.
• What legal advice, strategy, outcome, value, or timeline should be communicated.

The confirmation should say what actually happened: the inquiry was received, a stated next step was created, and representation has not been accepted. The language should match the firm’s approved engagement process.

Create a requirements sheet for every channel

A phone demonstration can hide the rest of the system. The firm should compare how the same approved rules operate across phone, website, forms, text, email, scheduling, and the internal record. The channels do not need identical conversations, but they should agree about services, boundaries, next steps, and responsibility.

1. Entry point. Identify the number, page, form, message, or referral route that begins the interaction.
2. Approved questions. List the facts the system may request and the questions it should decline or escalate.
3. Customer confirmation. Write the exact acknowledgement and avoid language that implies advice, acceptance, or a response the firm has not committed to deliver.
4. Human handoff. Name the person or queue that accepts the record and the fallback when that reviewer is unavailable.
5. System record. Define the source, consent, answers, summary, route, timestamps, messages, reviewer, and final disposition that should remain visible.
6. Stop condition. State when follow-up ends because the person declined, opted out, hired another firm, entered professional review, or reached an exception.

Evaluate supervision, not just automation

A law firm remains responsible for the work it delegates and the systems it adopts. The ABA Model Rule 5.3 page on nonlawyer assistance addresses measures and supervision intended to keep nonlawyer assistance compatible with professional obligations.

A buyer should therefore ask who can change instructions, approve scripts, inspect conversations, correct records, review escalations, export information, remove access, and respond when the system behaves outside the agreed boundary. The answer should not depend on an unnamed technical team or an informal promise.

The ABA Formal Opinion 512 on generative AI tools discusses duties including competence, confidentiality, communication, supervision, candor, and reasonable fees. Firms should review that opinion alongside the rules and guidance that apply to their jurisdiction and intended use.

Inspect the information path

The evaluation should follow information from the first word a person shares to the final place the record is stored or deleted. A polished front end does not answer what happens to recordings, transcripts, summaries, uploaded files, model inputs, integrations, backups, exports, or support access.

Ask for concrete answers

• Which information is collected by default and which fields can the firm disable?
• Where recordings, transcripts, summaries, and contact records are stored.
• Who can access the information inside the firm and outside it.
• Whether information is used to train or improve any model and what controls apply.
• How retention, deletion, export, access removal, and incident response work.
• What happens when a connected calendar, phone route, message channel, or record system fails.

The correct answer depends on the firm’s obligations, policies, clients, and vendors. The goal is not a universal checklist approval. It is a reviewable information path that the firm understands before live use.

Test the failures the sales demonstration avoids

A scripted demonstration usually shows a cooperative caller and a successful booking. Real inquiries are incomplete, emotional, repetitive, multilingual, sensitive, urgent, and sometimes outside the firm’s scope. A responsible pilot should make failure visible before a real prospective client finds it.

Use realistic acceptance tests

• The caller gives an unclear description and cannot identify the practice area.
• The caller shares sensitive facts before the system asks for them.
• The caller reports a date or event that may be time-sensitive.
• The caller asks whether the firm can win, accept, or price the matter.
• The caller is an existing client but enters through a new-matter route.
• The name, email address, phone number, or spoken summary is captured incorrectly.
• The intended reviewer is unavailable and the primary integration fails.
• The person asks to stop messages or requests a human immediately.

A pass requires more than a natural voice. The system must stay inside the approved task, explain uncertainty honestly, preserve the original context, create the correct human fallback, and leave a record the firm can audit.

Turn expectations into written acceptance criteria

Acceptance criteria make the purchase testable. Each criterion should name the trigger, expected customer language, expected system action, responsible reviewer, response expectation, fallback, and evidence that proves the handoff occurred.

Examples of useful acceptance criteria

• A new inquiry outside office hours receives the approved acknowledgement and appears in the assigned review queue with its source attached.
• A reported time-sensitive event creates an alert for the approved reviewer without calculating a deadline or promising action.
• A request for legal advice produces the approved boundary statement and a human escalation instead of an improvised answer.
• A possible conflict remains at a human gate and cannot move automatically into a consultation labeled as accepted.
• A failed calendar or message connection creates a visible exception rather than silently losing the request.

This approach separates a useful operating system from a collection of impressive features. It also gives the firm and provider a shared definition of done.

Compare the operating model and commercial scope

The monthly price is only one part of the decision. The firm should distinguish software access, initial configuration, custom strategy, copy, conversation design, integrations, testing, launch, monitoring, changes, usage charges, and ongoing improvement. A low subscription can still require substantial internal work. A broader engagement should state exactly which work is included.

Ask who owns each task after launch. If the firm changes a practice area, office, phone route, consultation type, reviewer, disclaimer, or escalation rule, the agreement should make clear whether the firm can change it, the provider changes it, or a new scope is required.

The AI intake systems page explains how approved conversations, routing, booking, and handoffs can fit together. The law-firm AI intake system guide goes deeper into the operating design after the buyer requirements are clear.

Plan governance before launch

Instructions, integrations, staffing, services, and professional guidance change. A launch review cannot govern the system forever. The firm should assign responsibility for reviewing live conversations, exceptions, access, retention, customer promises, and changes to the approved boundary.

The NIST AI Risk Management Framework organizes voluntary AI risk management around govern, map, measure, and manage. A law firm can use those functions as an operational lens while relying on its own legal, ethical, security, and professional requirements for the final controls.

Before selecting a configuration, a firm can review the broader legal, financial, and advisory system or book a Systems Review to map the real inquiry types, handoffs, exceptions, and acceptance criteria.