Support Knowledge Loop Bridge Planner

The Prompt

You are a support operations architect. Build a safe, multilingual support bridge that ties customer-facing intake, knowledge capture, and escalation systems through governed read-first workflows and draft-only writebacks.

PREFERRED LLM / FAMILY:
{{preferred_llm}}

SUPPORT CONTEXT:
{{support_context}}

TICKET INPUTS:
{{ticket_inputs}}

LANGUAGE MATRIX:
{{language_matrix}}

HANDOFF RULES:
{{handoff_rules}}

QUALITY CRITERIA:
{{quality_criteria}}

APPROVAL REQUIREMENTS:
{{approval_requirements}}

Return exactly these sections:

1) Signal Intake Map
- Input channels, language detection, and routing design.
- Required evidence metadata captured on every issue packet.

2) Evidence and Translation Controls
- Canonical-language source-of-truth rules.
- Locale-variant review rules and contradiction checks.

3) Knowledge Loop Design
- FAQ / article delta workflow.
- Macro / response-template workflow.
- How source evidence and approved copy stay synchronized across languages.

4) Draft Action Matrix (PROPOSED_ONLY)
- Suggested updates for support knowledge pages, macros, escalation artifacts, and review queues.
- For each action: destination, write_mode, approver, and rollback note.

5) Execution Plan
- Read-first integration order.
- Which system is the source of truth for approved knowledge.
- Which agent or workflow surface is used for coordination vs publication.
- Drift checks and observability requirements.

6) Quality and Governance
- SLA and quality targets.
- Audit logging, policy checks, and reviewer ownership.
- Conditions that force the workflow to stay draft-only.

Rules:
- No direct external customer writes without explicit approval.
- Mark every proposed write as draft unless approval is already granted.
- Keep one canonical source-of-truth version for every published knowledge artifact.
- Keep translation quality, terminology, and legal constraints explicit.

When to Use

Use this when support and documentation systems are multilingual, distributed, and repeatedly recreate manual routing logic that should be standardized into a controlled AI-assisted process.

It fits especially well when the team wants one repeatable support-learning loop across shared work surfaces such as ChatGPT Workspace Agents, Slack AI, Notion AI, or a programmable orchestration runtime, without turning those surfaces into unsupervised publishing channels.

Variables

Variable	Description	Example
`preferred_llm`	LLM family for planning and drafting	`gpt`, `claude-sonnet`, `gemini-pro`
`support_context`	Support environment scope	”Tech support + onboarding support, EMEA + APAC.”
`ticket_inputs`	Main sources and channels	”Zendesk exports, Slack support threads, Notion article repository.”
`language_matrix`	Priority languages and quality requirements	”English, French, German; legal-safe tone checks.”
`handoff_rules`	Escalation and ownership rules	”Escalate P1 to operations lead within 10 minutes.”
`quality_criteria`	Accuracy and response standards	”90% factual accuracy threshold, unresolved rate < 3%.”
`approval_requirements`	What needs human signoff	”Draft article updates need content owner approval.”

Tips & Variations

Add region-aware routing if support SLAs differ by geography.
Ask for a “contradiction resolver” rule when KB versions diverge by locale.
Name the system of record explicitly if draft work happens in Slack or a shared agent surface but publication happens elsewhere.
Include sentiment and urgency heuristics for routing policy tuning.
Request a periodic stale-content cleanup cadence.

Example Output

Routing plan separates translation, triage, and draft-update tracks with clear ownership.
Knowledge loop output includes source-of-truth synchronization rules between ticketing, shared work surfaces, and the knowledge base.
Governance section lists where approvals pause automation and where the workflow must remain draft-only.

The Prompt

When to Use

Variables

Tips & Variations

Example Output

Related site references