Fan Inbox Wallet and Plan Blocking
Conversation operations can degrade when billing prerequisites are not met. This article explains detection and recovery workflow.
On this page
Summary
Conversation operations can degrade when billing prerequisites are not met. This article explains detection and recovery workflow. 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
- Identify billing-related inbox blockers.
- Restore composer and monetization continuity.
- Coordinate with billing controls rapidly.
Before you start
- Review current wallet state.
- Check active plan status for bot.
- Identify whether the block is temporary or structural.
Step-by-step workflow
- Open Fan Inbox and check warning banners.
- If blocked, open /dashboard/billing in parallel.
- Top up wallet if below required thresholds.
- Verify bot subscription state.
- Return to inbox and test composer availability.
- Confirm thread operations return to normal.
Key states and error handling
- Wallet blocked banner indicates monetary gating for actions.
- Plan inactivity can reduce AI/revenue workflows.
- Billing fixes should propagate back to inbox quickly.
Best practices
- Keep wallet above safety margin before high-volume windows.
- Monitor billing before launching campaigns.
- Avoid waiting for full outage before topping up.
Troubleshooting
- If composer remains blocked after top-up, refresh both billing and inbox pages.
- If only one bot is blocked, verify per-bot subscription status.
- If warnings are unclear, capture screenshot and exact text for support triage.
- If issue persists after one clean retry, capture exact toast/banner text, selected bot, and timestamp before escalation.
Validate fixes in the real page flow before closing the issue.
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.
- Identify the exact scope (bot, period, module) before any change.
- Apply one targeted correction based on observed UI state and messages.
- Validate outcome in the live operational flow linked to this page.
- Document the final state so future incidents can be solved faster.
Do not close incidents on UI-only confirmation. Always validate the full user journey end to end.
Related articles
Use correct bot context and thread selection sequence to avoid cross-bot mistakes.
Resolve inbox access blockers caused by missing or invalid Telegram business connection.
Operate message composer and thread toolbar controls safely in live conversations.
Use a structured incident flow when inbox stops behaving as expected.