HomeFan InboxFan Inbox Wallet and Plan Blocking

Fan Inbox Wallet and Plan Blocking

Conversation operations can degrade when billing prerequisites are not met. This article explains detection and recovery workflow.

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

  1. Open Fan Inbox and check warning banners.
  2. If blocked, open /dashboard/billing in parallel.
  3. Top up wallet if below required thresholds.
  4. Verify bot subscription state.
  5. Return to inbox and test composer availability.
  6. 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.
Operational note

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.

  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.
Execution standard

Do not close incidents on UI-only confirmation. Always validate the full user journey end to end.

Related articles