Case Study - Running an AI-augmented knowledge-ops program across two lines of business
Designing the SOP program, owning the stakeholder alignment, and building the AI orchestration that keeps it alive — across Finance Collections and Ecommerce LATAM operations.
- Client
- Tesla — Customer Support Business Operations
- Year
- Service
- Technical program management · stakeholder alignment · AI systems

The business problem
Both LOBs were absorbing the cost of the same pattern. On the Finance side, Collections and Payment Resolution specialists were escalating routine cases at a rate that crowded out the work only they could do — PIN releases, fee waivers, vendor coordination, the authority-dependent calls that genuinely need a specialist. On the Ecommerce side, cross-border LATAM fulfillment lacked clear team boundaries on returns, payments, and escalation routing, so the same case could land in three different queues depending on who saw it first.
Neither problem was "we need better articles." Both were operating-model problems wearing knowledge clothing — the SOPs were the visible artifact, but the underlying issue was that the program around them (authoring, validation, governance, feedback loops) didn't exist yet.
My role
I run this as a program, not a content desk. That means:
- Discovery with team leads and specialists — sitting in on calls, reading existing escalation patterns, and identifying which gaps are content gaps versus which are authority or system-access gaps the SOPs structurally can't fix.
- SOP and article system design — authoring the front-line content, but more importantly designing the structure (H1/H3/H5 hierarchy that maps cleanly to the internal knowledge platform) so the content scales without losing consistency.
- Stakeholder alignment across Finance and Ecommerce operations, team leads, and the Customer Support Business Operations team — translating between what specialists need on the floor and what the platform team can support.
- Analytics and reporting — building a delta reporting framework that tracks inquiry complexity pre- and post-SOP deployment so the program can prove its effect and surface coaching signals for team leads.
- Technical infrastructure — architecting the multi-agent orchestration system that makes the above sustainable as the business changes.
Finance LOB — Collections & Payment Resolution
I designed and deployed the structured SOP and article system for Collections and Payment Resolution. The intent was specific: shift the workload mix on the floor — fewer routine escalations, more capacity for authority-dependent cases — without changing headcount.
The delta reporting framework I built sits alongside the SOPs and tracks inquiry complexity before and after each deployment. It surfaces three things at once: which articles are moving metrics, where coaching signals are needed for individual specialists, and which escalation patterns can't be resolved by content alone (because they require system access the front-line doesn't have today). That last category became the input for a Phase 1.5 roadmap — the cases where the SOP is correct but the access model is the bottleneck.
Ecommerce LOB — LATAM fulfillment
For Ecommerce, the work was more boundary-setting than escalation-reduction. I authored the operational knowledge base content governing cross-border fulfillment workflows across LATAM markets, with the explicit goal of establishing clear team boundaries on returns, payments, and escalation routing — reducing the ambiguity that was sending the same case to three queues.
I also serve as live operational notetaker during process reviews — surfacing and tagging 13+ action items that span SOP gaps, system deficiencies, and immediate escalation needs, then routing each one to the right owner instead of letting them die in a meeting recap.
The orchestration system — infrastructure for the program
Running a knowledge program across two LOBs at this scale is not a one-person content job. To keep the SOPs aligned with live operational reality — and to keep myself out of the role of "human bottleneck between Power BI and the wiki" — I architected a local TypeScript multi-agent orchestration system:
- Eight specialist agents with enforced write-target routing, each scoped to a specific content domain
- Six runtime hooks wired through PreToolUse/PostToolUse — enforce-write-targets, validate-frontmatter-schema, classify-and-register, sync-trigger, index-refresh, session-audit
- GitHub Copilot SDK integrated via session factories for domain, GitHub MCP, and orchestrator roles
- Continuous intelligence loop — pulls from Power BI dashboards, Teams channel agent comments, and targeted API calls so content stays aligned with what's actually happening on the floor
- Content pipeline — markdown source enforcing the H1/H3/H5 hierarchy that matches internal tool page structure, converted to DOCX via Pandoc for upload to the internal knowledge platform
The system isn't the headline. It's what makes the program defensible — without it, the SOPs go stale the moment the business changes underneath them, and the whole effect on the metrics reverts within a quarter.
- Technical program management
- Stakeholder alignment
- SOP authoring & delta reporting
- Knowledge base architecture
- TypeScript / JavaScript
- Claude Code + MCP
- GitHub Copilot SDK
- Multi-agent orchestration
- Power BI integration
Outcomes
- Reduction in routine escalations post-SOP
- 60%+
- Compression in median resolution time
- ~25%
- Drop in non-repo specialist concerns
- ~30%
- Specialist agents in production orchestration system
- 8
What's next
The Phase 1.5 roadmap addresses the cases the SOP system structurally can't solve — authority-dependent scenarios (PIN releases, fee waivers, vendor coordination) that need system-access integration rather than better content. The delta reporting framework is the input: it identifies which scenarios are appearing often enough to justify the integration work, and which can stay on the content track. That prioritization conversation is the next program milestone, not the next article.