Support desk automation: knowledge sync, in-chat booking and customer context

Problem

A support team worked in one help desk but depended on information held elsewhere. Its AI customer-support agent answered from a knowledge base that had to mirror a large, frequently changing public documentation source, and stale or deleted articles led to wrong answers. When a customer needed a meeting, agents pasted a booking link and the customer left the chat. And to learn who they were talking to (services, overdue invoices, notes, open tickets), agents had to search a separate billing system for every conversation.

Goal

Keep the AI agent's knowledge current automatically without ever destroying content by mistake, let customers book a meeting without leaving the conversation, and show each customer's account context inside the help desk the moment a conversation opens, all read-only towards billing and at near-zero running cost.

My role

Designed and built the in-conversation booking app and the customer-context sidebar, including the sidebar's billing-platform client, two server-side extensions and the fixed-address network setup, and worked on the knowledge-sync pipeline with its help-desk API client, scheduled machine automation and deploy scripts.

Solution

A knowledge-base auto-sync: a weekly batch job on a virtual machine that a scheduler starts and that powers itself off, detecting new, changed and removed articles by content hash and creating, updating or safely archiving knowledge content through the help-desk API.

An in-conversation booking card: a stateless service implementing the help desk's app-card protocol that pulls real availability from a scheduling platform and books through it, with every step a signed webhook.

A customer-context sidebar: a read-only app that, on a signed webhook, runs parallel lookups in the billing platform and returns one structured card.

How it works

Knowledge sync.

A scheduler starts a stopped virtual machine once a week. Its startup script brings up a self-hosted content-extraction service in containers and waits for it with health checks, backoff and restarts.

Discovery walks the documentation's topic pages to list every article. Each article is fetched, cleaned to Markdown, converted to HTML with source attribution, and hashed over its cleaned content.

Unchanged articles are skipped, changed ones updated, and new ones created as both an internal knowledge article and a content page for the AI agent.

An article missing from discovery is only flagged on the first run. If it is still missing on the next run it is archived (its AI content page replaced with an archived notice and its record moved to an archive file), never deleted.

State is saved crash-safely (a temporary file, then a rename, with a backup), and a bootstrap mode builds the initial state from the existing knowledge base. The API client rate-limits itself, retries throttling and server errors while honouring the server's retry hint, and uses versioned endpoints.

An optional headless-browser step covers actions only the web interface offers and degrades to an alert. The run writes structured logs and a summary, posts a status line to chat and powers the machine off.

Booking card.

An agent inserts the app into a conversation. The help desk calls the initialise webhook, and the service returns a compact grid of upcoming times grouped by day, for one or several meeting types.

Each click is a separate submit webhook that moves a four-step flow forward (meeting type, slot, name and email, confirm). The service keeps no session store: the state the next step needs travels inside the card's own stored data.

On confirm it validates the contact details and books. If someone else took the slot in the meantime, it detects the conflict and offers fresh times instead of an error.

Meeting-type identifiers must match a strict pattern before they reach the third-party API.

Customer-context sidebar.

When an agent opens a conversation, the help desk calls a signed webhook, and the service verifies the signature over the raw request body with a length check and a constant-time comparison.

It finds the customer's email in whichever of several payload shapes the request uses, looks the customer up in the billing platform, then fetches services, notes, open tickets, and unpaid and overdue invoices in parallel.

It returns one card: an account summary, active services with a toggle for inactive ones, invoice totals with overdue amounts highlighted, notes, recent tickets and a refresh control.

Two small server-side extensions on the billing platform supply data its standard API returned incorrectly or did not expose, and the client detects when they are missing and falls back.

The container scales to zero. Outbound traffic leaves through a fixed address (a private network and NAT) so the billing platform can allow-list it, and credentials come from a secret manager at deploy time.

Technical challenges

Complete article discovery for documentation sync, and change detection that ignores formatting noise.

Never deleting content because of a transient fetch failure: two-run confirmation, and archive instead of delete.

Crash-safe state on a machine that only exists while the job runs, which is also what keeps its cost near zero.

A multi-step interactive flow on a protocol where every click is a separate webhook and the server is stateless and scales to zero.

Booking races between showing a slot and confirming it.

Working around a vendor API's defects without forking the vendor's software.

Making a scale-to-zero service reachable through an address allow-list.

Inconsistent webhook payload shapes, and verifying the sidebar's signatures over the raw bytes.

Capabilities

Article discovery and content-hash change detection
Idempotent create, update and archive with two-run removal confirmation
Crash-safe state with a bootstrap mode
A rate-limited, retrying help-desk API client
Browser automation with graceful degradation
Run summaries posted to chat
An inline availability grid and in-chat booking with conflict recovery
Instant customer lookup with services, invoices, notes and tickets in one panel
Overdue highlighting
Raw-body signature verification for the customer-context sidebar
A fixed outbound address for allow-listed APIs
Read-only billing access

Technology

Impact

The AI customer-support agent's knowledge stayed in step with a large, fast-moving documentation source automatically, with no content ever lost by mistake and compute cost close to zero. Customers booked meetings without leaving the chat, and agents answered with the customer's full account context without switching systems. No metrics are claimed.

Skills demonstrated

API resilience engineering
Third-party app platform integration
Design of stateless UI flows
Handling races and conflicts
Fetching from APIs in parallel
Vendor-defect workarounds
Network setup for address allow-lists
Webhook security