The anonymised 13-section scope a four-attorney firm sent us for Claude, Microsoft 365, MyCase and Lexis: what it got right, what it missed, plus a template.
[ KEY TAKEAWAYS ]
A good AI integration scope for a law firm names the security foundation first, limits writes to what a person can review and reverse, demands per-user authentication and an audit trail that names the user, defines acceptance tests before anyone builds, and makes the vendor validate every API entitlement before promising a capability. A four-attorney firm in Oklahoma sent us a thirteen-section scope that did all of that, derived from a feasibility report it had paid for. It still missed three things: the research API was never priced, nobody said where unattended jobs run on Claude Enterprise, and token efficiency and training were hopes rather than deliverables. The anonymised anatomy is below, with a template you can download and fill in.
sections, from objective to the proposal format they wanted back.
systems: Microsoft 365, MyCase, LexisNexis, Adobe Acrobat and Sign.
writes allowed in phase one: tasks and notes. Case creation excluded.
things it missed, each of which would have surfaced in week four of a build.
Most firms call us with a sentence. "We want Claude connected to our stuff." This one called with a document, and the document is the useful part, because it shows what a small firm that has thought hard about the problem actually asks for. Eight people, four attorneys, on Claude Enterprise with four pilot users, Microsoft 365 already connected by their own IT administrator, an old physical server they want to retire into Azure. The partner's first question on the call was not about features. It was whether facts from one matter could leak into another once four systems were talking.
The scope set the build order before it listed a single feature. That alone puts it ahead of most briefs we read.
First
Shared security foundation
Private hosting and authentication reused by every connector. Per-user sign-in. Audit attributed to the user. Documented scopes.
Alongside
Microsoft 365 workflows
The connector already worked; the scope asked for triage, drafts, retrieval and a scheduled morning summary on top of it.
Then
MyCase and LexisNexis
A custom connector with a Monday report, and research grounded in Lexis with citation checking, each "subject to API availability".
Adobe document processing and e-signature came last, and by the next day the firm had deprioritised them itself as "the least bang for our buck". A scope that can shed its last two sections without breaking is a scope with the dependencies in the right order.
| Section | What it asked for | What we would add |
|---|---|---|
| 1. Objective | Less manual gathering, matter visibility, sourced research, document processing; permissions, firm control and attorney review preserved; vendor must validate API access and licensing before committing | Nothing. This paragraph is the standard. |
| 2. Environment and users | Four pilot users with a rollout path; assess the existing Microsoft 365 connector; connectors deployed in firm-controlled Azure; the IT administrator keeps credentials and deployment approval | Name the Claude plan and the organization owner. Enterprise versus Team decides what a custom connector can do. |
| 3. Security foundation | Per-user authentication honouring each system's permissions, no shared identities, attributable audit, documented controls, human review of consequential actions, no claim that the implementation guarantees compliance | State where unattended jobs run and under which retention terms. On Enterprise, chat has a retention floor; scheduled work belongs on the API. |
| 4. Sequence | Foundation, then Microsoft 365, then MyCase and Lexis, then Adobe; phased schedule with dependencies and go-live criteria; "do not assume the prior vendor's delivery estimates" | An exit for the firm at each phase, in writing. |
| 5. Microsoft 365 | Search and read mail, calendars, Teams, files and transcripts; email triage with the firm's rules; draft replies for review; SharePoint retrieval and revision; validate create, update and delete; a scheduled morning summary | Token efficiency as a deliverable: prompt caching, bounded context, a usage view for the administrator. The partner's words on the call were "they sit there and spin and cost us tokens". |
| 6. MyCase | List and filter matters, contacts, documents, calendar, billing and trust subject to the API; writes limited to tasks and notes; Monday 9:00 a.m. report; administrator guide and onboarding | Which billing and trust fields the API actually returns for the firm's account, confirmed in week one. |
| 7. LexisNexis | Validate API access with the account team first; research grounded in Lexis with authorities; Shepard's signals; citation checking of drafts | Price the entitlement before the workflow. LexisNexis sells its APIs separately, and Shepard's through an API is undocumented. |
| 8 and 9. Adobe | OCR, structured extraction validated on firm documents, PDF assembly, template population; e-signature with entitlement confirmed and sandbox first | Nothing. The firm shelved both a day later, which the sequence allowed. |
| 10. Deliverables | Findings and confirmed scope; architecture and permission model; configured workflows; deployed connectors; documentation, source code, administrator guide, handoff; hands-on training | Training with acceptance criteria, not "hands-on training" as a line. |
| 11. Validation | Test plan agreed first; permissions, attribution, each workflow, permitted writes, documentation and handoff demonstrated on representative data before production acceptance | Nothing. Copy it. |
| 12. Maintenance | API and auth changes, dependency updates, patches, defects; coverage, response, escalation; boundary between the firm's Azure and the vendor's connectors; maintenance versus new functionality | Nothing. This is the section most vendors hope you forget. |
| 13. Proposal format | Architecture, native versus custom, feasibility, assumptions, exclusions, licensing; milestones, staffing, firm participation, acceptance criteria; commercial proposal by workstream; experience, ownership and handoff terms, support model | Ask for milestone acceptance tied to payment. A vendor who refuses that has told you something. |
The firm's wording is paraphrased; the structure and the write boundary are exact.
Permissions
Per-user auth, no shared identities
Every connector authenticates each user individually and honours the permissions that user already holds in each system. The audit log names the user. This is the sentence that makes a partner's "facts must not bleed between matters" enforceable instead of aspirational.
Writes
Tasks and notes only
The feasibility report had listed case creation. The scope noticed the contradiction and ruled it out of phase one in a clarification paragraph. That is the right boundary: writes a person can review and reverse, behind approval, until the audit trail has earned trust.
Acceptance
Tests agreed before the build
Section 11 asks for a test plan up front and demonstrations on representative firm data with pilot accounts. A vendor cannot drift on a scope like that, and the firm cannot move the goalposts either.
"Per-user authentication honouring each system's permissions, no shared identities, audit records attributing actions to users." Section 3 of the firm's own scope, written before any feature. That order is the whole lesson.
Research
The Lexis API is a separate licence
The scope asked the vendor to validate access, which is correct, but it planned four research workflows as if access were a formality. LexisNexis prices its APIs by product and volume through an API specialist, positions the Protégé API at firms of about a hundred lawyers, and does not document Shepard's as an API. Price the entitlement before the workflow.
Scheduling
Where unattended jobs run
A morning summary and a Monday report run without a person. On Claude Enterprise, chat has a retention floor and no zero-retention option, so those jobs belong on the API from the firm's own cloud, delivered into Outlook or Teams. The scope asked for the jobs and did not say where they live.
Adoption
Tokens and training as deliverables
The partner wanted the team to use it "successfully, so they don't junk it up or sit there and spin". That is a deliverable with acceptance criteria: a skills library in the firm's style, caching and bounded context, a usage view for the administrator, recorded training. The scope listed training in one line and tokens not at all.
Before any price The scope asked the vendor to validate platform support, API access and entitlements. That sentence is the one to copy. A fixed price on a connector to a system whose API licence nobody has confirmed is a guess, and the feasibility week exists so the firm never pays for one.
By workstream, because that is what section 13 asked for, and with a fixed price on each workstream instead of one number for the whole thing. The foundation first. Microsoft 365 workflows, the firm's skills library and the token guardrails second. The MyCase connector with the Monday report third, writes limited exactly as the scope said. LexisNexis priced as a feasibility week with three written outcomes rather than a connector build, because nobody had the entitlement in hand. Adobe held as options. Each workstream ends in a milestone the firm accepts in writing against the test plan, and a milestone it does not accept is not billed. Documentation and repositories in the firm's name from the first paid milestone, so another developer could take it over, including from us.
No numbers here, on purpose. The price belongs to that firm. The shape belongs to anyone with a similar scope, and the shape is the point: a scope this clear earns a proposal that can be checked line by line.
Have a scope, or a sentence?
Either way, thirty minutes with a co-founder turns it into the thirteen sections above, with the three questions this one missed answered for your firm.
The thirteen sections as a Word document with a guidance line under each heading and bracketed fields to fill. No firm names, no prices, no vendor lock. Use it for Claude, ChatGPT or Copilot, and for Clio, MyCase, Filevine, iManage or NetDocuments; only the system sections change.
Free download
AI Integration Scope of Work for a Law Firm (.docx)
Fourteen headings, the thirteen sections plus the three questions scopes like this usually miss. Fill it in a week, send it to three vendors, compare proposals section by section.
If you would rather compare against the market first, Thomson Reuters, Clio and MyCase all publish their own connector documentation now, and the questions in the template apply to each of them the same way. The template is written so a vendor cannot answer it with a brochure.
Thirteen things, in this order: the objective in the firm's words and the three constraints that never move (individual permissions, firm control of infrastructure, attorney review); the environment and pilot users; a shared security foundation with per-user authentication and attributable audit; the implementation sequence; one section per system (email and documents, practice management, research, document processing, e-signature) with reads, allowed writes and dependencies; deliverables; validation and acceptance criteria agreed before build; maintenance responsibilities; and what the proposal must contain so you can compare vendors. The free template on this page has all thirteen.
Only narrowly. The scope we reviewed allowed tasks with due dates and priorities, and notes, and explicitly excluded case creation and edits to case records. That is the right phase-one boundary: writes that are easy to review and reverse, behind a human approval, with case creation priced as a later option once the firm trusts the audit trail.
The firm. The scope we reviewed put every custom connector in the firm's own Azure tenant with the IT administrator holding credentials, infrastructure and deployment approval. That keeps repositories, data and the audit log in the firm's name, which is what the bar's cloud-vendor opinions ask for, and it means the firm can change vendors without moving anything.
Write it into the scope as a dependency the vendor must validate before committing, and expect the proposal to price a feasibility step rather than a build. The scope we reviewed did this for LexisNexis; the honest answer turned out to be a one-week check with the account team and three possible outcomes, not a fixed-price connector.
Demonstrations on representative firm data with pilot accounts, agreed before implementation: individual permissions respected and unauthorised data inaccessible; actions attributable to the initiating user; each workflow operating as specified; permitted writes working without any expansion of write access; documentation, training and administrator handoff complete before production acceptance. The scope we reviewed listed exactly these.
It helps if someone reads your actual systems and entitlements. The firm we worked with paid a vendor for a feasibility report and derived its scope from it, which produced a clear document. The gaps it still had (the research entitlement never priced, no decision on where unattended jobs run, token efficiency and training absent as deliverables) are the gaps a feasibility report written from product pages rather than from the firm's contracts tends to leave. The template on this page is cheaper than a report and asks those three questions.
NEWSLETTER
[ WRITTEN BY ]
Petar Jovanović
Co-Founder & Technical Lead
Co-Founder and Technical Lead at Oktopeak. Builds regulated software for legal and healthcare teams, and leads the rescues of codebases other vendors left half-finished.
[ LEGAL TECH ]
LEGAL TECH
Oct 6, 2026 · 12 min read
Three connectors, one firm. What Claude reads and writes in MyCase, Lexis+ and Microsoft 365, which plan each needs, and where a mid-size firm needs help.
Read ArticleLEGAL TECH
Oct 7, 2026 · 9 min read
Yes, licensed separately: Protégé API, content search, CourtLink, Lex Machina. What each returns, what Shepard's lacks, and the honest path for a small firm.
Read ArticleBUSINESS
May 7, 2026 · 12 min read
AI tooling collapsed the cost of writing fluent software development proposals. Here is how to filter candidates with seven questions that produce answers AI cannot fake, plus the paid scoping path serious buyers are using in 2026.
Read Article[ GET STARTED ]
30-minute call. No pitch deck. Just an honest conversation about your project.
