AI Receptionist Script Changes: An Approval Process for Small Law Firms

By Michael Brunman, Co-Founder and CEO of Clerx

The direct answer

Manage AI receptionist script changes through a short written request that identifies the current rule, replacement rule, affected channels, approver, effective date, test cases, and recovery plan. Confirm the change in the live workflow before treating it as complete. A message asking someone to "update the fee" leaves too much unspecified.

Small law firms change intake instructions frequently. An attorney's calendar changes. A consultation fee increases. A practice stops accepting a matter type. A bilingual greeting needs clearer wording. Each edit may be small, but its consequences can reach booking, payment, routing, and the downstream record.

The goal is a process one busy owner can maintain. A single approved request and a few meaningful checks often provide more control than a collection of emails, messages, and remembered conversations.

Make the change specific enough to implement

Start with the reason and the precise before-and-after behavior. "Estate consultations are now paid" is incomplete. Which consultation type? What fee? Which lawyer? Does it apply to existing appointments, new bookings, or both? Who can approve an exception?

A clearer request might say: "For new bookings of the initial estate-planning consultation beginning on the approved effective date, explain the stated fee before offering the payment step. Existing appointments keep their previously agreed terms. Route exception requests to the office manager."

Use the intake-question design guide to identify whether the change requires another question. Sometimes it does not. A new fee may change an explanation and payment instruction without requiring a longer screening conversation.

Include the exact wording that needs approval and the behavior expected if the caller asks a follow-up question. Do not leave the system to infer refund terms, legal service scope, or exceptions from one revised sentence.

Name one business approver

The person implementing the edit may not have authority to decide the firm's policy. Name the owner who approves the business rule and, where needed, the attorney who reviews language affecting representation, confidentiality, or legal boundaries.

An operations lead can coordinate routine scheduling instructions. A statement about accepting a client or providing legal guidance requires a different level of review. The process should make that distinction visible rather than sending every minor edit to everyone.

The ABA's guidance on AI use emphasizes lawyers' continuing responsibilities. An intake vendor's technical implementation does not replace the firm's judgment about its professional communications.

Keep a dated approval record. If a caller later receives inconsistent information, the team should be able to establish what was authorized at the time. This can be a simple maintained document rather than a specialized software system.

Identify every affected channel

A fee stated on the phone may also appear in website chat, SMS, social-message responses, appointment confirmations, a booking page, and staff instructions. Updating one surface can leave the rest contradictory.

Donna's inbound call workflow, website chat, and text messaging can share a broader intake process. That is a reason to test consistency, not to assume every edit propagates automatically or identically.

List each affected channel and the person responsible for checking it. Include languages, office locations, and consultation types when they change the outcome. A rule may apply only to one branch, so preserve unaffected branches explicitly in the test plan.

If the website itself needs an update, assign that task separately. A receptionist configuration change should not be assumed to modify the firm's public pricing, calendar descriptions, or marketing copy.

Trace dependencies beyond the script

A consultation-fee change may require the booking description, payment amount, confirmation message, and staff record to agree. A routing change may require a valid destination number, availability schedule, and fallback owner.

For a firm using the MyCase-connected Clerx Scheduler, test what the caller sees and what the team receives. The payment or appointment step may be configured separately from the spoken instruction.

The MyCase connection and Clio connection should be reviewed according to the firm's actual setup. Public integration pages describe capabilities, but do not establish that changing a script automatically changes every connected field, template, or calendar setting.

Create a short dependency note: "This edit changes the spoken explanation, booking description, and payment instruction; staff reporting remains unchanged." That sentence helps the implementer and approver check the same scope.

Choose an effective date and transition rule

Specify when the new behavior should begin and what happens to conversations already in progress. A prospect who received a quote yesterday may call back today. The system needs an approved response that respects the firm's transition policy.

For existing appointments, decide whether terms remain as agreed and how staff will handle rescheduling. Avoid allowing a technical update to silently redefine a prior commitment.

An illustrative immigration-practice change might involve reducing the appointment length for one consultation type. Test a new inquiry, a returning prospect, and an existing appointment holder. Those are different transition cases even though the calendar edit looks simple.

Do not invent a launch time if only a date has been approved. If timing is material, the implementation owner and firm should agree it precisely and document it before activating the change.

Test the changed branch and one adjacent branch

Use a fictional inquiry that reaches the changed behavior. Then use another that should remain unaffected. For a paid-consultation update, test the correct fee and a service that remains free. For a transfer edit, test both the new destination and an unanswered call.

The go-live testing process can be reused for changes, with a smaller scope. The purpose is to verify the actual consequence of the edit, not to reread the request and assume it has been implemented.

Include at least one clarification or exception request. "Can I pay after the meeting?" may expose a gap that a simple "yes, book me" test misses. If the answer requires staff approval, verify that the system routes the request without inventing a concession.

Where languages are affected, review the changed instruction in each working language. A short English edit can alter the meaning of the translated explanation or leave an older version active in another channel.

Define completion as observed behavior

A change is ready when the correct instruction appears in the intended place, the connected action behaves as agreed, and the record shows the expected result. A support message saying "updated" is a checkpoint, not the entire acceptance test.

Keep the approved wording, test scenario, result, reviewer, and activation date together. If the vendor provides native version history or rollback, verify how it works. If not, preserve the last approved instructions and agree a manual restoration route.

The intake quality-assurance guide supports ongoing sampling. For change control, focus the first review on conversations that used the edited branch. A random sample may miss it entirely if that branch is uncommon.

Assign an owner for any mismatch. Record whether the issue affects wording, routing, booking, payment, or record handoff so the correction goes to the right person.

Plan recovery before a rushed update

If an edit produces an incorrect fee or destination, the team needs a way to contain the problem. Agree who can pause the affected branch, restore prior instructions, or route inquiries to staff while a correction is verified.

These are operating procedures to arrange, not assumed built-in Clerx controls. Ask the implementer to identify the options available in your account and any steps requiring their assistance.

Use the ownership and escalation framework to distinguish ordinary edits from urgent corrections. A typo and an instruction sending callers to the wrong person require different responses. Do not convert an internal prioritization goal into a guaranteed resolution deadline.

After recovery, review the affected interactions and let the firm decide whether any person needs corrected information. Preserve the record of what happened rather than rewriting history to make the change look clean.

Keep the process proportionate

A solo owner does not need a formal committee for a greeting adjustment. A short request, owner approval, and one real test may suffice. A change affecting payment, client identity, or confidential information warrants broader review.

As a practical routine, keep one current instruction document and a dated change log. Review unresolved edits during the existing operations meeting. Remove obsolete drafts from the places staff use for reference so they do not reintroduce an old rule.

The payoff is consistency that can be checked. It should be measured through fewer contradictory instructions and less repair work, rather than claimed as a guaranteed increase in signed clients.

A one-page change request

A practical request can fit into one page. State the problem, current instruction, approved replacement, scope, dependencies, effective date, approver, and evidence needed for completion. Add the person authorized to request recovery if the observed result is wrong.

For example, an estate practice changing a transfer number should identify the old destination, new destination, applicable hours, unanswered-call route, and staff owner. Test from an outside number and inspect the resulting notification. Updating a contact card without testing the call path leaves the central requirement unverified.

Keep the request free of unrelated improvements. Combining a number change, new greeting, fee revision, and different qualification questions makes failures harder to trace. Where several edits are necessary, identify them individually and test their combined effect before approval.

This is an internal operating template, not a promise about vendor response times or a claim that the platform provides a particular approval interface.

Frequently asked questions

Can we just email the vendor a new script?

Email can carry the request, but include the precise replacement behavior, approver, affected channels, effective date, and tests. A complete request reduces ambiguity regardless of which communication tool the team uses.

Who should approve routine edits?

Name the business owner responsible for the relevant policy. Involve the attorney when an edit affects professional boundaries, confidentiality, or representation. The technical implementer should not have to guess what the firm intended.

Do all channels update together?

Do not assume so. Confirm the behavior in phone, chat, messaging, confirmations, and any relevant booking surface. Shared intake infrastructure does not establish identical configuration or simultaneous deployment across every surface.

Does a fee change require more than a script edit?

Often it does. Review appointment descriptions, payment settings, confirmations, existing quotes, and exceptions. The spoken amount and connected transaction must agree before the firm treats the change as complete.

Should old appointments keep their terms?

The firm must decide and approve the transition rule. The intake system should communicate that policy accurately. A software edit should not silently alter a previously agreed appointment or consultation arrangement.

Is rollback always available?

Native rollback must be verified with the provider. Keep the last approved instructions and agree a restoration or containment process even when automatic version recovery is unavailable in your configuration.

How much retesting is enough?

Test the changed branch, an adjacent unaffected branch, and a realistic exception. Expand the review for connected payments, languages, confidential information, or other consequential behavior. The test scope should follow the edit's actual effects.

What should we bring to a vendor demo?

Bring one ordinary policy change, such as a consultation fee or transfer destination. Ask the vendor to explain request, approval, implementation, test, and recovery. That shows how the service will operate after the initial sale.

Book a demo with Clerx today.