I find workflow friction
and ship AI tools that remove it.

The natural framing was “build an AI that answers customer questions.” My first useful move was noticing I’d bundled three different products into one — an internal tool (now), a partner-facing product (later), and a fully-automated agent (someday) — with completely different users, risks, and success criteria. I focused everything on the internal tool and treated the rest as extensions, not requirements. Then I flipped the approach from knowledge-first (dump every doc into the AI) to problem-first: build the knowledge base from the few dozen questions partners actually ask.

I ran the loop by hand once to learn its shape. About 80% is automatable — collect (Lark + WeChat), cluster, dedupe, diff against the current FAQ, flag, and route to the right SME. The remaining ~20% — the authoritative answer(e.g. “Does EBT work on this processor?”) — is a human knowledge gate the AI routes to but never invents.

I classified every question into four types and let the AI confidently answer only Type-A(safe, high-volume how-to); bugs route to an owner, account-specific questions get collected and routed, feedback becomes product signal. So I stopped optimizing for “accuracy” and started optimizing for deflection + wrong-answer rate. Underneath sits a three-layer model — raw material → a structured, human-maintained table → AI working knowledge that cites its source entry on every reply (I reasoned my way to RAG before I knew the term). When an answer is wrong, I ask which entry it cited, fix that row, reload.

Two deliberately small first steps. (1) A client-facing FAQ— I consolidated scattered internal Q&A into one clean, re-runnable FAQ and got it to partners; it deflects repetitive questions immediately, and its structured content becomes the first rows of the knowledge base. (2) A KB-template draftI’m actively using to collect raw support material into structured rows — the layer the architecture reads from. The wider system is piloting; the defensible output so far is the thinking made concrete, with no invented metrics.

Where should support actually live? Meeting partners in the chat groups they already use is the lowest-friction path — but it’s costly to operate, hard to scale, and the data is messy and ToS-risky to capture. Centralizing in our ops platform gives clean, owned, structured data, real assignment and accountability, and the knowledge base every later stage depends on — at the cost of some login friction. My team leans platform; leadership leans chat. I’m holding it open on purpose — because it should be settled by users, not by whoever argues hardest.