Case Study: How [Agent] Cut Closing Times by Automating Document Workflows

The Problem: A Manual Process Built on Hope and Email

Apex Title ran on a predictable, broken system. A real estate closing package would arrive as a storm of poorly scanned PDFs attached to an email. A processor would then manually open each document, find key data points like names, addresses, and loan amounts, and copy-paste them into a separate system of record. This process was repeated dozens of times per file.

The failure points were everywhere. A typo in a property address could delay funding. A missed signature block on the HUD-1 statement would send the entire package back to square one. This is known as a NIGO, or “Not In Good Order” document, a term that generously describes a workflow actively sabotaging itself. The team spent more time fixing errors and chasing down missing information than they did actually processing valid files.

Their tech stack was a patchwork of disconnected tools. Email for intake, a shared network drive for storage, and a legacy closing platform that looked like it was designed in 1998. Version control was a filename convention: `Final_Closing_Package_v3_USE_THIS_ONE.pdf`. It was a slow, expensive, and fragile operation waiting to break under any real volume.

The core issue was the sheer amount of unstructured data and the human labor required to impose structure on it. They were paying skilled people to perform robotic, low-value tasks. This is a classic symptom of a workflow that has organically grown into a monster.

Designing a System to Gut the Manual Work

Our goal was not to simply speed up the existing process. The objective was to replace the core manual labor with a deterministic, machine-driven workflow. We broke the problem down into four distinct stages: ingestion, extraction, orchestration, and generation. We had to build a digital assembly line to replace the chaos of the shared inbox.

Stage 1: A Controlled Entry Point for Document Ingestion

The first step was to shut down the firehose of inbound emails. We established two new, controlled entry points. A secure web portal for direct uploads from lenders and a dedicated, monitored inbox that was explicitly for machine processing. Anything sent to a processor’s personal email was now considered out of bounds and immediately rejected.

Once a document package hit one of these entry points, it triggered an AWS Lambda function. This function’s only job was to take the raw files, PDFs, JPEGs, and TIFFs, and shove them into an S3 bucket. This immediately created a single source of truth for the raw, unaltered documents. From there, another event would trigger the next stage: Optical Character Recognition.

We piped everything through AWS Textract. For standard, typed forms, the accuracy was high. But for handwritten notes in the margins or low-quality scans, the output was a mess. This is the first lie of automation: OCR is not magic. To handle the inevitable failures, any document that returned a confidence score below 95% was automatically flagged and routed to a human verification queue. The machine did the first 90% of the work, and a human handled the exceptions.

Stage 2: Extraction and Hard Logic Checks

Getting raw text from a PDF is one thing. Understanding that “123 Main St” is a property address and “$450,000.00” is a loan amount is another. We built a rules engine that used a combination of regular expressions for highly structured documents and a lightweight named-entity recognition model for more variable text blocks.

For example, a W-9 form is always the same. We could use regex to reliably rip the Taxpayer Identification Number. A lender’s instruction letter, however, could have the loan amount buried in the third paragraph. That required the model.

The most critical piece was the validation layer. Once data was extracted, it was immediately checked against the primary transaction data stored in Apex’s legacy system via a rickety API. We hammered that API with requests to logic-check the extracted data. Does the borrower’s name match? Does the loan number exist? Is the property address identical, character for character?

A simple check might look like this in pseudo-code:


extracted_data = ocr_service.get_data("doc_id_123")
source_of_truth = legacy_api.get_record("transaction_id_456")

if extracted_data.borrower_name != source_of_truth.borrower_name:
validation_engine.create_flag(
field="borrower_name",
expected=source_of_truth.borrower_name,
found=extracted_data.borrower_name,
severity="CRITICAL"
)
state_machine.transition_to("Human_Review_Required")


Any single mismatch would halt the automated workflow for that file and place it in a specialist’s queue with the exact discrepancy flagged. No more hunting for the error. The system presented the problem and the two conflicting data points to the user for a decision.

Stage 3: Orchestration with a State Machine

The entire workflow was managed by AWS Step Functions. Using a state machine was non-negotiable. It prevents the process from becoming a tangled mess of dependent scripts. It provides a crystal-clear, visual representation of a file’s journey from intake to completion. At any point, we could see exactly where a file was: `OCR_IN_PROGRESS`, `VALIDATION_FAILED`, or `PENDING_SIGNATURE`.

This approach provided resiliency. If the OCR service failed, the state machine would automatically retry three times before moving the file to an error state. If the legacy API timed out, the workflow would pause and wait before retrying. This logic, which is a nightmare to code and maintain manually, is native to a well-designed state machine. It turned a brittle process into a fault-tolerant one.

Connecting all the disparate services felt like plumbing with mismatched pipe fittings. The legacy system spoke SOAP, the OCR service returned JSON, and the e-signature platform required XML payloads. We had to build small, dedicated Lambda functions to act as translators, sitting between each step in the state machine to reformat data and bridge the protocols.

Stage 4: Automated Document Assembly and Signature

The final stage was generating the outgoing closing package. We used a templating engine that took our validated, structured JSON data and injected it into master document templates. This eliminated copy-paste errors permanently. The system would generate a single, pristine PDF package, correctly ordered and ready for signatures.

We then integrated with the DocuSign API. The system would automatically create a new signature “envelope,” upload the generated document, place signature and date tags in the correct coordinates, and email it to the buyer, seller, and agents. We configured webhooks so that as each person signed, DocuSign would call back to our API Gateway, triggering an event that updated the state machine. The final state, `CLOSING_COMPLETE`, was only reached after our system received a webhook confirming all signatures were collected.

The Results: More Than Just Speed

The impact was immediate and measurable. This was not a minor, incremental improvement. It was a fundamental change in how the business operated.

Hard Metrics Speak Loudest

The numbers from the first six months of operation laid the story bare. We tracked everything from processing time to error rates, and the results were stark.

• Document Processing Time: The average time from receiving a document package to having it fully verified and ready for signature dropped from over 8 hours of manual work to just 25 minutes of automated processing and exception handling.
• NIGO Rate: The rate of documents rejected due to missing or incorrect information fell by 92%. The validation engine caught the errors before they ever left the system.
• Closing Cycle Time: The total time to close a standard transaction was reduced by an average of 3 days. This was a direct result of eliminating the back-and-forth communication caused by manual errors.
• Operational Overhead: Apex Title was able to reassign four full-time employees from manual data entry to higher-value roles like customer relations and exception management. They handled a 30% increase in volume with the same headcount.

The Hidden Benefit: Sanity and Scalability

Processors were no longer data-entry clerks. They became pilots, managing a fleet of automated workflows and only intervening when the system flagged a genuine anomaly. This radically changed the nature of their work and reduced burnout.

The system also provided a perfect audit trail. Every action, every data validation, and every state change was logged immutably. When an auditor came asking questions, we could provide a complete, timestamped history of a file’s life without digging through email chains.

Lessons from the Trenches

This project was not a simple victory. The initial investment in the AWS infrastructure and development was significant. Training the OCR models on Apex’s specific document types was a slow, painful process that we underestimated.

The legacy API was a constant source of frustration. It was slow, poorly documented, and would occasionally fail without warning. We had to build extensive error handling and retry logic just to make it usable. This is the reality of enterprise automation: you often have to build armor around the old systems you cannot replace.

The final architecture works. It is faster, more accurate, and more scalable than the manual process it replaced. It proves that you can automate even the most paper-logged, human-centric workflows, but it requires a willingness to get your hands dirty, grapple with imperfect tools, and force old systems to cooperate.