Legal Intake Automation for a Criminal-Defense Law Firm

Failure mode 01 Manual retyping of scanned documents

Every new case required a staff member to read scanned documents and transcribe the relevant information into the firm's case-management system. Attorneys and support staff spent meaningful time on data entry for each new client. The work was repetitive and offered little value beyond accurate transcription. But it could not be skipped: without the data in the case-management system, the case could not be properly tracked or worked.

Failure mode 02 Transcription errors

Hand-typed data entry introduced errors. Names could be misspelled, dates misread, docket numbers transposed. A single error in a case number or client name could create problems downstream — misfiled documents, missed court dates, or incorrect case records. The firm had no systematic way to catch these errors before they entered the case-management system. The review happened, if at all, when someone noticed something wrong later.

Failure mode 03 Slow case setup

Because intake required human reading and typing, new cases took time to become active in the case-management system. The delay meant that attorneys did not have immediate visibility into new client matters, and any follow-up work — scheduling, docketing, document preparation — had to wait until the data was entered. For a criminal-defense practice, where timelines can be short and responsive action matters, slow case setup created operational pressure.

Failure mode 04 Scanned documents resist simple automation

The incoming packets were scanned PDFs, not structured digital data. The information existed in the documents, but extracting it required reading page layouts, identifying which text belonged to which field, and understanding the context of each document type. The firm could not simply export data from one system to another because the source was paper that had been scanned. The automation had to handle unstructured document interpretation — a problem deterministic rules alone could not fully solve.

Decision 01 Keep a human review checkpoint

The system was designed to extract and structure data, then present it for review before anything was written into the case-management system. The reviewer's job shifted from typing data to verifying data — a faster, higher-value task. This decision responded directly to the transcription-error problem. Rather than hoping for accurate typing, the system built verification into the workflow.

“Confirm before you commit.”

Decision 02 Handle uncertainty explicitly

Scanned documents are rarely clean. Skewed pages, poor scan quality, handwritten notes, and ambiguous fields all create uncertainty. The system was designed to recognize when its extraction confidence was low and route those items to human review rather than guessing. This meant the AI did not need to be perfect. It could flag what it was unsure about, and the reviewer would resolve those cases. The system's reliability came from knowing its own limits, not from pretending it had none.

“When in doubt, send it to a human.”

Decision 03 Sync only after approval

The final step — writing data into the case-management system — only happened after human review. Octacer built an integration layer that synced approved, structured data into the firm's case-management system automatically. This separation between extraction, review, and sync meant the case-management system never received unverified data. The integration was also the piece that removed the manual typing work entirely: once a record was approved, it flowed into the system without anyone retyping it.

“The case-management system only receives verified data.”