What a 14-Day Legal Intake Pilot Should Prove

A pilot is not a smaller contract and it is not fourteen days of hoping. It is a bounded test designed to answer one operational question with evidence the firm can inspect.

For after-hours intake, the question should concern the workflow itself: response timing, delivery, intake progress, or handoff reliability. Signed cases and revenue remain important business outcomes, but a short pilot may be too small to attribute them confidently.

1. Choose one operational question

Start with one source: eligible missed calls, website forms, or inbound texts. Adding all channels at once makes it harder to distinguish a product issue from a routing or data issue.

Define the hours, office, matter types, languages, and exclusions. Write down what the system does and what stays with the staff. If an AI component is used, specify its task and the human oversight path. NIST's AI RMF organizes risk work around governance, mapping, measurement, and management; a small pilot can use the same logic without turning the project into a compliance exercise.

2. Freeze the baseline before activation

Use a recent comparison period with the same definition of after-hours. Capture only metrics the firm can reproduce from its own records:

• eligible inquiry count by channel;
• time to first response attempt;
• delivery status when messaging is used;
• intake started and completed;
• time to human acknowledgement;
• unresolved, failed, duplicate, and opted-out events.

Do not combine “sent” and “delivered.” Messaging providers expose distinct status states because the difference is operationally important. Likewise, do not count a CRM write as proof that a person reviewed the handoff.

3. Define the evidence package

For every included inquiry, the pilot should preserve enough information to reconstruct the path without relying on memory.

SMS consent and opt-out handling belong in the launch evidence, not in a footnote. The FCC has codified that consumers may revoke consent through reasonable means and requires covered revocation requests to be honored within a reasonable time, not more than ten business days. Provider policies may impose additional identification and opt-out language requirements. The firm should have counsel review the specific use case.

4. Predefine stop and failure conditions

A credible pilot says what would cause the workflow to pause. Examples include:

• the wrong recipient receives inquiry information;
• the workflow continues after a tested opt-out;
• the AI crosses an approved boundary or fails to escalate an identified trigger;
• delivery failures are hidden or treated as completed conversations;
• the team cannot take over or disable new intake safely;
• the event record is incomplete enough that a reviewer cannot reconstruct what happened.

Define who can stop the workflow and how. Test that stop path before the first live inquiry.

5. Make a go, change, or stop decision

At the end of the window, compare the pilot with the frozen baseline and inspect exceptions individually. There are three honest outcomes:

1. Go: the workflow met the defined operational threshold and the team is prepared to continue.
2. Change: the core path worked, but one identified routing, script, delivery, or handoff issue needs another bounded test.
3. Stop: the workflow did not produce reliable evidence or created unacceptable risk.

A “change” outcome is not permission to keep the pilot open indefinitely. Set the next question and a new deadline. Avoid turning a free pilot into an unmeasured production dependency.