Conner Zheng

Product-support knowledge was scattered across months of team chat and wiki pages. Staff needed expert-level answers instantly, without depending on whoever happened to remember a specific fix.

Built an ingestion pipeline that classifies chat history and wiki docs into structured "skills," plus a separate clustering stage that synthesizes recurring conversation threads into a curated, deduplicated knowledge base — checkpointed so re-runs only touch new material. At answer time, a relevance layer pulls the right knowledge, skills, and memory into the prompt: a hand-rolled retrieval system, no vector database.

Added voice input (Whisper transcription), scheduling intent parsing, and in-chat commands to correct the knowledge base directly from user feedback. Then built an evaluation harness that runs a fixed question set through the full pipeline and a no-context baseline side by side, scoring both — so retrieval improvements are provable, not assumed. Later split the single bot into a small multi-agent system, routing domain-specific questions out to dedicated specialist bots instead of growing one prompt indefinitely.

Result: a 950-entry curated knowledge base and an automated regression report on every change.

Support agents logged case notes as free-form chat, so nothing was queryable or reportable without manual re-entry. Separately, several product lines each needed their own update data pushed reliably to field technicians.

Built an LLM-based extraction step that reads raw chat, pulls structured case fields, runs a verification pass against the source text, and writes rows to the correct table by product line — plus a backfill mode and a daily automated summary.

The product-update pipelines are independently checkpointed and each one holds its checkpoint back rather than advancing it on a write failure, so a partial failure gets reprocessed instead of silently marked done.

Result: three independent update pipelines, 600+ lines each, with zero recorded silent data loss.

Staff needed fast, chat-native answers about stock, invoices, and orders instead of logging into a web console for every lookup — and needed to be told about problems (low stock, duplicate records, upcoming renewals) instead of finding them by accident.

Grew a small inventory Q&A bot into 35+ standalone CLI tools, each wrapping one API endpoint (invoices, orders, warehouse stock, serial numbers, credit notes), sharing one authenticated request layer so every tool runs independently — from the bot, a scheduled job, or a terminal.

Layered analytics on top of raw CRUD (replenishment analysis, profit-by-item, revenue summaries), then built scheduled jobs that push alerts directly to staff instead of waiting to be asked. Separately built a customer-record deduplication engine to clean up years of duplicate CRM contacts.

Result: ~7,000 lines across 35+ tools, several running unattended on a daily schedule.

Subscription renewals for one product line were tracked by hand. Needed automatic reminders and an escalation path when a customer didn't respond before expiry.

Designed and built a full custom stack: an OAuth2 client against the billing platform, a webhook receiver, a daily escalation cron, local state tracking, and automated notifications. Documented every step that needed real account access to complete.

Before standing up the always-on webhook infrastructure, recognized that a no-code automation layer already available on the account could cover the same triggers without a public endpoint or a hand-rolled state file — and wrote a migration plan that reused existing credentials rather than provisioning a new integration.

A high-volume record set needed to stay continuously synced and backed up, so a source-system hiccup could never mean lost or stale data.

Built as a long-running managed service rather than a periodic job, with a companion monitor process and an explicit resume file, so a restart picks back up instead of re-running from scratch or silently skipping a window.

Result: a live backup of 3,700+ records with zero manual intervention.

An existing pipeline archived call recordings and logged them to a database. It needed on-demand transcription, a reliable per-call identifier, better caller-name matching, and a way for a manager to see call-center health at a glance. Then a bigger ask: help technicians during the call, not only after it.

Live-call assistant. A small Windows agent on each technician's PC starts streaming the moment the softphone takes the microphone (call answered) and stops when it releases it (hung up). Silence never ends a stream, so a long pause can't cut a call in half. Caller and technician audio go as two separate channels over a WebSocket on a private mesh network, with no public endpoint. On the server, streaming Whisper turns them into a live transcript, and an LLM session per call reads it and suggests next steps. The transcript, suggestions and caller details update on one chat card, for up to 7 calls in parallel. Later rounds send only new lines and reuse the call's earlier lookups. Benchmarked models on real calls and picked the one that put 90% of lines on screen within 5.2 s. Removed two latency traps: an unbounded audio buffer during long monologues (20–30 s delays) and a blocking card update inside the transcription loop.

Transcribe once. Each live transcript is saved under the call's unique ID. The archive pipeline places it next to the stored recording, and on-demand transcription reuses it instead of running Whisper again. The call-ID backfill (below) is what joins the live and archived paths.

Shipped two independent transcription triggers on purpose, not redundantly: a one-click workflow button behind a public tunnel with background speech-to-text and speaker diarization; and, after diagnosing that tunnel as the system's primary source of instability, a tunnel-free chat-bot path with its own reconnect logic, so an in-flight transcription survives a reconnect instead of dying with it. Jobs that arrive while the transcriber is busy are queued, never dropped. Tuned the speech model against a known repeat-looping failure mode on noisy audio, and added a fallback for when speaker diarization fails.

Backfilled a stable unique call identifier across 4,192 historical records by reconciling three inconsistent reporting endpoints against the source pipeline via phone-number and time-proximity matching — iterating the match rate 90.5% → 100%, including catching a subtle bug where a filename timestamp reflected call-end rather than call-start time. Fixed calls being credited to the wrong agent on ring-all and queue calls. Shipped a 7-widget live dashboard covering answer rate, call volume, and per-agent performance.

Shipping safely with live calls. A CI pipeline runs push → tests → deploy → report. The live service only restarts when its own code changed and no call is in progress. A regression test replays 100 s of a real call through the running service and checks the transcript, delay and suggestions. A scheduled health check flags any background job that can't run.

Root-caused two production outages. One was a weekly outage: an auth token expired on a strict cycle because of a cloud console publishing-status setting, and I shipped a permanent fix. In the other, the phone provider changed its recording sender overnight and recordings silently stopped being picked up; it was found and fixed the same day.

Result: live help during technician calls, lines on screen in about 5 s, up to 7 calls at once, and every call transcribed only once.

Customers needed live shipping-cost quotes on the public website, without staff manually working out carrier rates for every enquiry.

Extracted the cost-calculation logic into a standalone module, then built two consumption paths on top of it — an internal bot for staff, and a public-facing calculator embedded directly into the company website — so the same pricing rules serve both audiences without being maintained twice.

A small live-events business needed a booking platform where overselling capacity is structurally impossible and payment is handled safely — built self-hosted rather than on a SaaS booking platform, to own the data and avoid per-booking fees.

Made the hosting and data-ownership decisions before writing app code: self-hosted infrastructure with a single relational database as the explicit source of truth — the payment processor confirms into it, every other system only reads from it, nothing else is ever authoritative on capacity. Paired that with a resilience checklist: uninterruptible power, nightly off-site backups, external uptime monitoring, and a documented one-hour failover runbook to a cloud host.

Implemented atomic seat purchase as a single row-locked database transaction with a hard capacity check, so overselling can't happen even under an application bug. Payment state is confirmed only via server-side webhooks, never trusted from the client. Built the booking flow, a day-of manifest with QR check-in, and a chat-based operations bot restricted to fixed, parameterized commands — deliberately no free-form queries over chat.