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.

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. Tuned the speech model against a known repeat-looping failure mode on noisy audio.

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. Shipped a 7-widget live dashboard covering answer rate, call volume, and per-agent performance.

Separately, root-caused a recurring weekly production outage — an auth token expiring on a strict cycle — to a cloud console publishing-status setting, and shipped a permanent fix.

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.