operate-customer-supportlisted

# Operate Customer Support Produce one **Support Operating Model** that resolves customer jobs, preserves trust, and turns recurring failure into owned product improvement. ## When to use - Support operations need triage, resolution, escalation, and quality-loop design or review - Recurring customer failure should feed owned product improvement - Not for one customer case (`references/resolve-one-case/`) or payment/refund policy (`build-payment-readiness`) ## Atomic boundary Own support channels, self-service, taxonomy, ticket state, routing, evidence intake, decision rights, response policy, service objectives, automation, quality, escalation, knowledge, metrics, and product-feedback closure. Do not own provider payment truth, refund/account consequence policy, product roadmap priority, security or incident command, data-recovery protocol, marketplace payouts, or public-review solicitation. Consume those artifacts and route to their owners. ## Agent-first invariant Build the complete declared support plane for actual contact reasons, risk, locales, service promises, and expected operating envelope. Use agents to avoid manual-first design, but do not create unused queues, integrations, or recurring operations merely because generation is cheap. Low volume may change topology; it does not justify unversioned answers, unsafe protected actions, missing case state, or an unowned manual gap. Routine operation is autonomous. A support agent may retrieve, classify, explain,