Your drafting pilot works, and another practice wants to use it. But if every change still needs the original builder, each new practice adds work to that person's queue. Before expanding, have the receiving team make, test, and reverse one small approved change while the builder observes. That shows which responsibilities the team can take over and where it still needs help.
In our work with a business law firm, the firm retired paid AI tools and removed ~$250K in recurring annual expense. Bringing approved negotiating positions into drafting also helped reduce median active partner review from 90 to 20 minutes per primary deal document. The comparison covered two one-week studies in the same group, with stable staffing and deal mix but more concurrent matters in the follow-up.
We trained the knowledge team and practice champions to run work studies and add approved positions, and their team later applied the method in a second practice without us.
Here's how to turn that capability goal into a practical handover test. You'll leave with an exercise, a record of who did the work, and a way to decide whether to expand, repair a gap, or retain support.
Define the change the receiving practice needs
A second practice may use the same drafting tool but need different document types, approved positions, or source permissions. Copying the first practice's setup carries its assumptions into the new work. The receiving partner therefore needs to confirm which rules apply before anyone treats a successful demonstration as permission to expand.
Choose one document type and one recurring issue for the exercise. Ask the receiving partner to approve the position, the circumstances where it applies, and the exceptions that need a lawyer's decision. If that judgment is still unsettled, the next step is a partner discussion because an administrator can't resolve competing legal positions by changing a prompt.
Keep the first change small enough to inspect. For example, add one approved position for the receiving practice while leaving the original practice's rules in place. Give the new position its own identifier, version, and practice scope so that the system can select it without silently changing what the first practice receives.
Our guide to approved drafting positions explains how to capture those rules and connect them to a drafting check. Here, the decision is whether the receiving team can maintain that check after the project ends. A correct answer from the system is one part of the test. Who approved, configured, checked, and released the change is the other.
Give each responsibility an owner with time to do it
The knowledge owner maintains the approved position and its source. The receiving partner decides whether it fits the practice and resolves exceptions. The technical owner manages access, releases, and recovery. The operating sponsor gives those owners time to do the work and decides whether the support arrangement is affordable.
One person can hold several roles, but a job title doesn't show that the work has been covered. Write down who will approve the next position change, who will investigate a failed check, and who can suspend the workflow if the output can't be trusted. Assign a backup for work that can't wait for the main owner to return.
Give the receiving team the current approved configuration, source references, test cases, release steps, and support contacts before the exercise. They should be able to use those instructions during the test. You're checking whether the documented operating arrangement works, so a test of unaided memory would answer the wrong question.
Ask the original builder to observe and record each time they need to intervene. If the builder chooses the right source or repairs the configuration, the output can still be correct, but the receiving team hasn't yet shown it can do that step. Record the help so that a successful demonstration doesn't hide the same dependency you're trying to remove.
If you’re a law firm managing partner and want to grow your firm without making partners carry more work, we’ll identify the biggest bottleneck standing in your way, build the plan to remove it, and implement it in eight weeks* or less - guaranteed or we continue to work for free and you don’t pay.
Find my bottleneck* Eight-week delivery, or twelve weeks when substantial data foundations are required, as agreed before work begins. If a covered stage fails its agreed benchmarks, we provide up to four additional weeks of remedy work at no charge, then waive or refund that stage’s fee if it still fails. Successfully delivered stages remain payable. Agreed client-caused delays pause the clock. Delivery guarantee terms.
Run one approved change through the full workflow
Here's what that looks like. Your receiving practice wants to add Position B for Document Type B. The original practice uses Position A for Document Type A. These are placeholders for the content your partners approve.
The receiving knowledge owner records Position B's wording, applicability, source, version, and approving partner. The technical owner connects it to the practice and document-type fields used by the drafting check. Those fields matter because a similar clause can appear in both practices while requiring different treatment.
The workflow takes the draft, confirmed matter context, and the current approved positions as inputs. Fixed rules select positions by scope and approval status. Access controls limit which source passages the user and workflow can retrieve. AI compares the relevant draft passages with the selected positions and returns the draft passage, position identifier and version, source reference, suggested change, and any missing information.
Code can check that a position exists, is current, and has a valid source reference. The reviewing lawyer still decides whether the comparison fits the matter. Keeping those jobs separate lets the team trace a bad suggestion to its cause: the wrong position was selected, the source was unavailable, the model misread the passage, or the matter needed an exception.
Ask the receiving team to run the change in a test environment with production-like permissions. Use a restricted test account and an approved test source to check denied access. A citation hidden from the screen isn't enough if the restricted text still reaches the model or its output. Check the retrieval and output records as well, using authorized reviewers for any sensitive logs.
Record the expected behavior before running the examples because a team that sees the output first can end up redefining a pass around what the system did. Having the partner agree the expected result first gives the receiving owner a stable basis for accepting or rejecting the change. The table below gives the team a concrete starting set.
| Test input | Expected behavior | What the receiving team must show |
|---|---|---|
| Document Type B with complete context and a departure from Position B. | Return the departure, approved position, source, and proposed change for review. | The knowledge owner can trace the suggestion to the correct approved version. |
| Document Type A from the original practice. | Continue using Position A. | The new release hasn't changed the original practice's selection rules. |
| Document Type B with a required matter fact missing. | Ask for that fact before choosing a position. | The reviewer can identify the missing input and route the question to its owner. |
| A user who can't access the relevant source. | Withhold restricted content and route the unresolved check to a permitted reviewer. | The technical owner can verify the access boundary without widening permissions. |
| A draft with a recorded, partner-approved exception. | Surface the exception for review without replacing the firm's default. | The lawyer can keep the matter decision separate from a change to the shared standard. |
| The new position is suspended. | Stop using that version and follow the approved fallback or manual review route. | The owner can restore an approved configuration and identify affected draft outputs. |
Include examples the team didn't use to write the position or tune the prompt. Otherwise, the team can improve the test answers without showing that the change works on other drafts. In our business-law engagement, partners tested suggestions against known closed deals, with retrieval restricted to earlier deals. For your historical tests, also check that the approved position itself doesn't contain a decision learned from the test matter.
Record the help, failures, and recovery
Suppose the first practice's draft receives Position B during the exercise. The receiving owner should inspect the selected position and scope fields, suspend the faulty release, and restore the approved configuration. The team should also identify which drafts used the faulty version so that the responsible lawyers can review those outputs.
If the builder has to find the scope error, mark that diagnosis as assisted even if the receiving owner clicks the release button. Add the missing diagnostic step to the instructions and repeat the exercise on a different example. That second run tests whether the repair transferred the skill, rather than whether the team remembers the first answer.
Use a short record for every responsibility:
| Record field | What to capture |
|---|---|
| Task and owner. | The action performed and the person responsible for doing it in daily work. |
| Configuration and evidence. | The position, prompt, model, access, and workflow versions tested, with links to outputs and review decisions. |
| Result. | Demonstrated, assisted, or not yet demonstrated, with the exact help or failure recorded. |
| Repair and retest. | The missing instruction, access, skill, or decision, its owner, and the next test. |
| Release decision. | The scope accepted, unresolved limits, approving owners, and support route. |
Agree the acceptance rules before running the exercise. A restricted source reaching an unauthorized user, an unapproved position entering a live draft, or an inability to suspend a faulty release should stop expansion until repaired. For interpretation errors, the practice partner should define the acceptable result by issue type and the review required. One overall pass rate can hide repeated failures on the issue that matters most.
A team can pass the change exercise and still lack time to maintain the workflow. Record the actual effort needed for approvals, updates, reviews, and support, including help from the original builder. Compare that work with the time the sponsor has assigned. If maintenance needs more time than the owners have, the release decision needs a staffing or support change as well as technical approval.
Expand only the scope your team can support
Use the test record to choose the next move. If the receiving team can approve, change, evaluate, release, and recover the bounded workflow, and has time to maintain it, start with that document type. A pass on one position doesn't establish that every document in the new practice is ready, which is why the first rollout should preserve the tested boundary.
Keep a sample of comparable work under review after launch. Track active drafting and checking time, partner correction time, exceptions, and support requests. Keep waiting time separate. A fall in partner corrections can conceal extra associate verification work, and so the effort comparison needs both roles before you decide the workflow has saved time.
Re-run the relevant tests when approved positions, access rules, prompts, or model behavior change. The owner should retain the version used for each draft so that a later error can be traced to the work it affected. If the platform doesn't let you restore a model version, define a fallback your team can actually use, such as suspending the AI check and returning to the approved manual review process.
Managed support can be the right choice when the firm wants the workflow but doesn't want to maintain every component. Keep partner approval and release acceptance with named firm owners, and agree which updates, incidents, and recovery tasks the provider handles. Include response expectations, ongoing cost, and how the firm can retrieve its approved content and operating records if the arrangement ends.
Before buying another platform or commissioning a build, test the current tool against the same exercise. A missing instruction calls for better documentation. A missing owner calls for time or support. A build is worth considering when the current system can't perform a required access, evaluation, or release step and that gap matters enough to fund.
Make the next change part of handover
Put one observed change exercise on the handover plan before the next practice goes live. The result gives you a specific acceptance decision and a repair list, so you can fund the support the workflow actually needs.
In our business-law case, approved positions reduced the correction work reaching partners, and the firm removed ~$250K in recurring annual AI-tool expense. Training the knowledge team and practice champions also gave the firm a method it used independently in a second practice. Testing the receiving team on an approved change lets you see what it can maintain and where to arrange support before the next practice depends on the workflow.
If you’re a law firm managing partner and want to grow your firm without making partners carry more work, we’ll identify the biggest bottleneck standing in your way, build the plan to remove it, and implement it in eight weeks* or less - guaranteed or we continue to work for free and you don’t pay.
Find my bottleneck* Eight-week delivery, or twelve weeks when substantial data foundations are required, as agreed before work begins. If a covered stage fails its agreed benchmarks, we provide up to four additional weeks of remedy work at no charge, then waive or refund that stage’s fee if it still fails. Successfully delivered stages remain payable. Agreed client-caused delays pause the clock. Delivery guarantee terms.