IAH Automation
Work we've taken from idea to production
A sample of systems designed, built, and deployed end to end. Client and employer names are withheld for confidentiality — the architecture and results are real.
An AI agent for Business Office Manager tasks, built during one discovery call
A multi-community senior living operator needed their Yardi Voyager data entry automated across the full range of Business Office Manager tasks, pre-move-in, move-in, move-out, ancillary charges, billing changes, resident agreements, ACH, and more. Using move-in as the flagship example, we mapped a full AI-assisted, human-in-the-loop architecture, including security safeguards and a phased rollout plan, in a single free discovery call.
AI voice-to-ticket system for inbound support
The pain point: every inbound call needed a person to listen, transcribe notes, look up the right records, classify the issue, and manually create a ticket, around 10 minutes of work per call, with frequent misclassification, duplicate contacts, and missed SLAs.
The approach: real-world speech is messy, so the system needed to be more than a simple call-to-text bot. Live calls are captured through a voice AI agent, with Whisper transcription as an audio fallback, and classification runs through parallel LLM chains for category, priority, and queue, alongside fuzzy phonetic matching so mispronounced names still resolve to the right company and contact. Business-rule logic calculates SLA-compliant due dates automatically, and Redis-backed idempotency plus signed webhooks keep it safe to run concurrently in production.
Inbound calls were manually transcribed and turned into support tickets, taking staff several minutes per call. Built a pipeline combining voice AI, Whisper transcription, and LLM classification that extracts caller details, classifies the issue, fuzzy-matches it against existing records, calculates SLAs, and creates a structured ticket automatically.
Technical details
- Retell AI phone agent collects structured data (name, email, company, issue) through live tool calls during the call itself.
- Retell's webhook posts to a FastAPI endpoint with signature verification and Redis-based idempotency and locking to prevent duplicate processing.
- A background task normalizes and validates the data, then runs parallel LangChain chains against a lightweight LLM to determine ticket category, type, priority, issue type, sub-issue, work type, and queue.
- Company and contact matching uses fuzzy and phonetic logic to handle accents, partial names, and typos, achieving over 95% match accuracy in testing.
- Autotask picklists, companies, and contacts are fetched in parallel; business rules map category and type to priority and resolution-time SLAs.
- Due dates are calculated using a business-days/hours helper before the ticket is created via the Autotask REST API.
- An optional fallback endpoint accepts raw audio, transcribes it with Whisper, and runs it through the same pipeline.
- Concurrency is capped at 3 simultaneous Autotask API calls; full audit logging, health checks, and Prometheus monitoring run throughout.
Watch it in action:
Automated data ingestion and reporting platform
The pain point: incoming data arrived in inconsistent spreadsheet formats and had to be manually classified into dozens of categories, then written up into per-community reports and emailed out by hand, a slow process prone to duplicate entries and formatting drift.
The approach: built entirely inside the client's Microsoft Fabric environment so no separate infrastructure was needed. Classification runs on Azure AI Foundry's language model against 40+ record categories with fuzzy column mapping, and every stage is idempotent so re-running a pipeline never creates duplicates. Reports and bulk email delivery are fully parameterized and wired into Azure DevOps CI/CD, so the entire system can be replicated into a new client workspace in under 10 minutes.
Incoming data arrived in inconsistent formats and required manual classification and report writing. Architected a zero-touch ingestion pipeline that classifies records into 40+ categories, deduplicates them, and generates formatted reports with charts, delivered via secure, time-limited links and automated bulk email.
Deployed inside the client's Microsoft Fabric and Azure DevOps environment; source isn't publicly shareable due to client confidentiality.
Technical details
- Data files are uploaded via OneLake File Explorer into a Lakehouse; an ingestion pipeline auto-detects CSV or XLSX format and applies fuzzy column mapping.
- AI classification runs on Azure AI Foundry against 40+ record categories, then deduplicates against the existing warehouse before appending records with an auto-generated ID and upload timestamp.
- A report-generation pipeline (parameterized by date range) queries the warehouse and produces both a main report and per-community DOCX reports, including program totals, category breakdown tables, high-resolution pie charts, and a 5-month rolling trend analysis.
- An email automation stage zips the report folder, generates a time-bound (1-hour) secure download link, filters recipients by opt-in status, and sends via Azure Communication Services, logging every send/failure to a dedicated log table.
- The entire architecture, Lakehouse folders, warehouse tables, notebooks, pipelines, and environment, ships through Azure DevOps CI/CD and can be provisioned into a brand-new client workspace in under 10 minutes.
- Fabric compute capacity auto-pauses and resumes, so idle time costs nothing.
Watch it in action:
Production RAG chatbot for website support
The pain point: the website relied on static FAQs, so visitors with real questions had no way to get an accurate answer, and promising leads that needed a human often went nowhere because there was no automated way to capture and route them.
The approach: built two retrieval paths on the same document store, an agent mode for dynamic tool use and a classic RAG chain for straightforward Q&A, so answers stay grounded in the client's actual documents rather than the model's general knowledge. Layered in an intent-detection step that recognizes when a visitor wants a human, collects their details conversationally, and emails a summary automatically.
Website visitors had no way to get instant, accurate answers grounded in company documentation. Built a dual agent/chain RAG chatbot with session memory, intent detection, and automated contact handling for leads that need a human.
Technical details
- An async PGVector store (PostgreSQL with the pgvector extension) holds document chunks as OpenAI embeddings for fast similarity search.
- A FastAPI ingestion endpoint accepts multiple file types (PDF, DOCX, TXT), loads them asynchronously, and splits them with a recursive character splitter before adding them to the vector store, with an option to clear and re-ingest.
- Two retrieval modes run on the same store: an agent mode with dynamic tool calling for context retrieval and contact-email handling, and a classic RAG chain with a history-aware retriever for straightforward conversational memory.
- Chat sessions are tracked per UUID with in-memory history, and a system prompt enforces a Clear, Concise, Complete, Correct, and Courteous response style.
- Built-in contact automation detects when a visitor wants to be contacted, collects name, email, phone, and reason conversationally, generates a chat summary, and emails it asynchronously, or declines gracefully if the visitor isn't interested.
- Endpoints are protected with API-key authentication; retrieval defaults to the top 5 matches, and session storage can be swapped from in-memory to Redis with a one-line change for scale.
AI-powered CV screening API for HR teams
The pain point: reviewing CVs against a job description was slow, inconsistent between reviewers, and simply didn't scale once more than a handful of applications came in at once.
The approach: built as a batch API rather than a single-CV tool, so an entire applicant pool can be screened in one run. Structured, schema-enforced outputs keep every report in the same format regardless of how messy the source CV is, and per-CV error isolation means one malformed file can't stall the rest of the batch.
Reviewing candidate CVs against job descriptions was slow and inconsistent across reviewers. Built a batch-processing API that reads PDF and DOCX CVs, checks them against a job description, and generates structured screening reports with recommendations.
View code on GitHub → (a partial backend endpoint, remaining code withheld for confidentiality)
Technical details
- A FastAPI endpoint accepts batches of PDF and DOCX CVs alongside a job description, using LangChain with a lightweight model to extract skills, tools, and candidate contact details, and to check for the presence of specific requirements.
- Outputs are enforced through Pydantic structured schemas so every report follows the same format regardless of how the source CV is written.
- Retry logic handles rate limits, timeouts, and API errors automatically, and each CV is processed in isolation so one malformed file can't stop the batch.
- Background file cleanup keeps the server tidy after each run.
- The pipeline flows from job-description analysis, to per-CV extraction, to a combined Excel matrix plus detailed individual reports, keeping the whole system easy to extend for larger HR teams.
Uptime and downtime reporting automation
The pain point: producing an uptime report from monitoring data was a manual, multi-hour task every cycle, and outages were often noticed late because someone had to actively check a dashboard rather than being told.
The approach: paired an automated report generator with a proactive Microsoft Teams bot, so the same monitoring data both produces the periodic report and pushes real-time outage alerts, removing the need for anyone to watch a dashboard at all.
Generating uptime reports from monitoring data was a multi-hour manual task each cycle. Built a reporting tool that pulls monitoring data and produces the report automatically, plus a companion bot that posts real-time outage alerts to Microsoft Teams.
Deployed inside the client's Microsoft Fabric and Azure DevOps environment; source isn't publicly shareable due to client confidentiality.
Technical details
- A Streamlit frontend paired with a FastAPI backend pulls uptime and downtime data directly from Pingdom's monitoring API.
- The report generator formats the pulled data into the same structure a person previously built by hand, cutting a 3–4 hour task down to a few seconds.
- A companion bot watches the same monitoring feed and posts real-time outage alerts to Microsoft Teams so the team doesn't need to check a dashboard to know something is wrong.
Pingdom-to-Teams outage notification bot
The pain point: teams relied on manually checking a monitoring dashboard, so outages lasting longer than an hour often went unnoticed until a customer complained, causing prolonged downtime and slower incident response.
The approach: rather than another dashboard nobody would check consistently, the fix was to push alerts to where the team already works. A proactive Microsoft Teams bot was designed against Pingdom's monitoring API, with a full feasibility and architecture report produced during planning before any code was written, then built and deployed inside the client's existing Microsoft Fabric environment.
Without this system, teams had no way to know about a site outage except by manually checking a dashboard, and outages lasting over an hour often went unnoticed for a long stretch, disrupting the business and slowing down incident response.
Deployed inside the client's Microsoft Fabric and Azure DevOps environment; source isn't publicly shareable due to client confidentiality.
Technical details
- Built on the Microsoft Teams Bot Framework using proactive messaging, so the bot can push a message into a channel without waiting for someone to ask it a question first.
- Polls the Pingdom API for check status and triggers a notification once an outage crosses the one-hour threshold.
- Deployed on Microsoft Fabric (Notebooks and Pipelines) with credentials managed through Azure Key Vault.
- Planning included a dedicated feasibility and architecture report, validating Teams proactive messaging and Pingdom API access before development began.
Legal document Q&A assistant
The pain point: finding a specific clause or answer inside long legal PDFs meant manually searching page by page, with no guarantee the right passage would even be found.
The approach: used recursive text splitting with overlapping chunks so context isn't lost at chunk boundaries, then paired retrieval with a chain-of-thought prompt template so the model reasons through the retrieved passage instead of guessing, cutting down on hallucinated answers.
Finding specific answers inside long legal PDFs required manual searching. Built a retrieval-augmented system with semantic chunking and a chain-of-thought prompt template so answers stay grounded in the actual source text.
View code on GitHub → (a partial slice of the project, remaining code withheld for confidentiality)
Technical details
- Legal PDFs are split using recursive text splitting with 200-character overlaps, so context isn't lost at the boundary between chunks.
- Chunks are embedded and stored in a FAISS vector index for fast similarity search.
- A compact open-source LLM answers questions using a custom chain-of-thought prompt template, reasoning through the retrieved passage rather than answering from general knowledge.
- This combination improved relevant passage recall by roughly 40% over a naive retrieval baseline, while keeping every answer traceable to the source text.
Have a similar problem?
Book a free discovery call and I'll tell you honestly what it would take to solve it.
Book a free discovery call