Legal Document Processing Automation
The client was a real-estate-focused legal services firm processing roughly six thousand title and lien documents per month for a network of brokers and lenders. The existing workflow used a Google Forms intake that triggered a manual data-entry process where a paralegal opened each uploaded document, transcribed serial numbers, parties, and dates into a Google Sheet, then generated a standardized output document by hand. Turnaround for routine documents had grown to three business days, which delayed closings and lost business to competitors.
NLP & Knowledge Systems
LegalTech / Real Estate
9 weeks from kickoff to full cutover
4 specialists
The full story
The specific user problem was that paralegal capacity had become the firm’s bottleneck on growth. The work was high-volume, low-judgment, and high-stakes — a typo on a serial number invalidated a filing — so it could not be outsourced offshore without quality risk. Hiring more paralegals locally was slow and expensive, and the firm’s partners had decided to either automate or stop growing.
We built an end-to-end pipeline that triggered on Google Forms submission, ingested the uploaded document into an OCR-plus-LLM extraction step, validated the extracted fields against a structured schema, generated the standardized output document from a template, and routed the result back to the original requester via Google Drive — all in under five minutes. A correction interface let paralegals fix edge cases in a single click and those corrections flowed into a weekly model retrain.
What shipped was a hands-off pipeline for the eighty percent of documents the model could handle confidently, with a triage queue for the remaining twenty percent. Paralegal time shifted from transcription to validation of edge cases and quality review on outputs. Turnaround for routine documents dropped from three days to minutes, the firm onboarded two new lender clients within a quarter, and the paralegal team grew their billable rate on judgment-heavy work because they were no longer transcribing.
Paralegal capacity was the bottleneck on growth, but the work was too high-stakes to outsource offshore without quality risk.
Six thousand documents per month flowed through manual transcription with three-day turnaround as the standing average.
Serial-number typos invalidated filings, so the work could not be outsourced to lower-cost regions without quality controls.
Hiring paralegals locally took ninety days minimum, so capacity could not respond to demand spikes from new lender onboarding.
Generic OCR returned strings that still required field-mapping by hand, so the apparent automation did not move the bottleneck.
Paralegal time on transcription was billed at low rates, depressing the firm’s overall realization on a fixed headcount.
How we structured the engagement
Made the existing Google Forms intake the trigger so adoption did not require any workflow change from brokers or lenders.
- 01Phase 01Week 1
Discovery
Reviewed three months of submitted documents to taxonomize field variability, parsed the existing manual workflow into discrete steps, and worked with paralegals on which edge cases required human judgment. Output: an extraction schema, a triage threshold, and a target turnaround of under five minutes.
- 02Phase 02Weeks 2-3
Architecture
Designed a webhook-driven pipeline from Google Forms through OCR, LLM-based field extraction, schema validation, template-based output generation, and Drive delivery. Picked a tiered model approach — a smaller model for routine documents and a larger one routed to only when the smaller model lacked confidence.
- 03Phase 03Weeks 4-7
Build
Shipped the Forms trigger and the OCR layer first, then the LLM extraction, then template generation. Built the paralegal correction interface as a one-click flow rather than a full editor — corrections were either accept-with-fix or reject-to-queue, which kept the labeling cost low and the feedback loop fast.
- 04Phase 04Weeks 8-9
Launch
Ran a two-week parallel period where every submission went through both the new pipeline and the manual workflow, compared outputs, and refined the model until the eighty-percent automation threshold held. Cut over with a triage queue for edge cases monitored hourly during the first week.
What we built, component by component
- 01
Forms trigger
Webhook from Google Forms that captures the submission metadata and the uploaded document, kicking off the pipeline.
- 02
OCR layer
Runs initial text extraction with layout preservation, providing positional metadata for downstream field mapping.
- 03
Tiered extraction
Smaller model handles routine documents; a larger model is invoked only when the smaller model lacks field-level confidence.
- 04
Schema validator
Enforces required fields, format constraints, and cross-field consistency before output generation begins.
- 05
Template engine
Produces the standardized output document from a Docs template with extracted fields substituted in correct positions.
- 06
Correction interface
One-click accept-with-fix or reject-to-queue surface for paralegals, feeding the weekly retraining job with labeled data.
A Forms submission triggers the webhook which downloads the document into the pipeline. OCR runs first, the tiered extractor produces structured fields, the validator enforces schema, and the template engine generates the output. The result is delivered to Drive and a copy goes to the correction interface where paralegals validate or reject, feeding the retraining loop.
The trade-offs we made and why
Triggered from the existing Google Forms intake
Asking brokers and lenders to change submission tooling would have killed adoption. Keeping the existing Forms intake as the trigger meant the upstream experience was unchanged and adoption was instant — the new pipeline was invisible to submitters.
Tiered extraction with two model sizes
A single large model would have cost too much per document at six thousand monthly volume. A smaller model handled the routine eighty percent at a fraction of the cost, with the larger model reserved for confidence-gated routing on the remaining twenty percent.
Built corrections as one-click flows, not a full editor
A full editor would have made paralegals into transcribers again. One-click accept-with-fix or reject-to-queue kept correction time under twenty seconds per document and turned every paralegal interaction into labeled training data automatically.
Ran a two-week parallel period before cutover
Real-estate filings carry legal consequences for errors. Running the pipeline in parallel with the manual workflow let us catch divergence cases before they reached a filing, which kept the firm’s quality position intact through cutover.
What changed for the client
turnaround
End-to-end time from Forms submission to standardized output document delivered back to the requester via Drive.
auto-handled
Share of documents processed without paralegal intervention, with the remainder routed to the correction triage queue.
docs per month
Monthly throughput sustained on the pipeline at launch, with capacity headroom to absorb new lender onboarding.
lender clients added
New lender accounts onboarded within the first quarter after launch, made possible by the unblocked paralegal capacity.
The tools behind the system
Built with a deliberate stack chosen for production reliability and operational velocity.
Lessons learned from the build
Keeping the existing intake form was the unsung adoption win. We considered a custom intake portal early in design and dropped it within a week — the firm’s brokers had years of muscle memory with Forms and any change would have stalled rollout. Match the existing entry surface whenever possible.
Tiered models with confidence-gated routing were the cost story. A single-tier design with the larger model would have eaten the firm’s margin on this work. Tiered routing kept per-document cost low enough that the firm could pass through some of the savings to lender clients.
One-click corrections doubled as labeling infrastructure for free. We did not initially design the correction surface as a labeling tool, but it turned out to be exactly that. Every retraining job ran on real production corrections, which kept model quality drifting upward instead of stagnating.
Similar delivery work usually starts in these service areas
If you are exploring a similar product, workflow, or implementation challenge, these are the service tracks that usually fit best.
Where this project sits in the bigger market picture
AI systems for document review, compliance, clause extraction, and legal operations.
Build a result-driven AI product with a team that has shipped before
If you are exploring a similar product, workflow, or AI use case, we can help scope the right architecture, delivery model, and first milestone.
Related case studies worth reviewing next
Have an AI idea, messy workflow, or product vision? Let's make it buildable.
Bring the problem. We'll help shape the product, define the architecture, and show the fastest path to a serious first version.
A practical first roadmap in the discovery call
Architecture, timeline, and delivery options in plain English
Security, scalability, and reliability discussed upfront
Model registry
softus-rag-v4.2
187ms
Latency
128k
Context
$0.004
Cost / req
Evaluation suite
Deploy pipeline
prod / canary 25% — healthy