Fan Inbox Incident Triage Playbook

Summary

This playbook provides a deterministic sequence for diagnosing Fan Inbox incidents under time pressure. For operators, this page should be used as a decision surface, not only as a UI form. Always pair page actions with downstream validation in the relevant live workflow.

What this page is for

• Shorten MTTR for inbox incidents.
• Avoid random changes during outages.
• Provide clear escalation evidence.

Before you start

• Capture timestamp and affected bot.
• Record exact warning banners or errors.
• Identify if issue is global or bot-specific.

Step-by-step workflow

1. Classify incident: access, thread visibility, composer, or connection.
2. Validate bot selection and business connection state.
3. Check billing blocks and plan status.
4. Run one controlled test message path.
5. Apply targeted fix and retest.
6. Escalate with captured evidence if unresolved.

Key states and error handling

• Most severe failures map to connection or billing prerequisites.
• Thread-specific issues often differ from global inbox outages.
• Evidence quality directly affects escalation speed.

Best practices

• Keep one incident owner per bot.
• Avoid simultaneous multi-operator config changes during triage.
• Close incidents only after fresh successful thread test.

Troubleshooting

• No inbox access: verify business connection first.
• Composer blocked: verify wallet/plan gates.
• Partial thread failures: ask fan for fresh inbound message and retest.
• If issue persists after one clean retry, capture exact toast/banner text, selected bot, and timestamp before escalation.

UI reference (what each control does)

• Active bot context drives visible conversations and available thread actions.
• Conversation sidebar is the queue entrypoint and must be triaged continuously.
• Thread view is the context source for safe manual interventions.
• Composer can be disabled by wallet or gating states.
• Business connection required state blocks normal inbox operations.
• Invalid business connection banner indicates reconnection is mandatory.
• Top utility area is the place to verify bot context before replying.
• Toolbar controls should be used with explicit thread intent, not random experimentation.

Operator checklist (before shipping changes)

• Confirm active bot before sending any message.
• Read latest thread context before manual intervention.
• Check for banners (connection/wallet) before assuming AI issue.
• Prioritize high-intent conversations first during load.
• Escalate repeated failure patterns into config or script changes.
• Retest after each incident fix with a fresh inbound message.

Real-world scenario

Inbox becomes partially unavailable for one bot. The operator detects business connection warning, reconnects the bot in Telegram business settings, then validates recovery with a fresh fan message and thread response test.

1. Identify the exact scope (bot, period, module) before any change.
2. Apply one targeted correction based on observed UI state and messages.
3. Validate outcome in the live operational flow linked to this page.
4. Document the final state so future incidents can be solved faster.