Platform operations, monitoring, growth, and Azure activation

Purpose

Platform operations keeps the marketplace safe, measurable, and launch-ready. Admin surfaces provide triage metrics, content controls, support queues, integration readiness, notifications, feature flags, audit logs, and public-safe status language. Future Azure activation is documented as a checklist, not as evidence that production Azure resources are already provisioned.

Admin integration statuses

1. 1Open /admin/integrations to review public-safe readiness for Firebase/Expo, OAuth, payment, AI, storage, analytics, and other provider groups surfaced by settings.
2. 2Confirm every status card uses customer-safe language such as not configured, sandbox, ready, degraded, or disabled.
3. 3Never expose secret values in integration status responses, CMS pages, logs, support replies, or screenshots.
4. 4Use /admin/feature-flags to hide unavailable provider-dependent experiences until validation is complete.
5. 5Record sensitive operational changes in audit logs and review /admin/audit-logs after launch-affecting changes.

Monitoring and growth dashboards

• ✦ Admin dashboard: GMV, active users, platform revenue, pending moderation, open disputes, pending KYC, and payout holds are triage signals.
• ✦ Creator dashboard: revenue, orders, conversion rate, affiliate sales, top products, and product workspace status guide listing improvements.
• ✦ Influencer dashboard: clicks, conversions, earnings, payout-ready balance, active links, and commission ledger guide promotion quality.
• ✦ SEO/admin overview: recommendations, redirects, CMS metadata, category metadata, product metadata, and structured data support organic growth.
• ✦ Support CRM: category counts, urgent tickets, assignment, SLA policies, quick replies, and AI-safe drafts support operational quality.

Azure activation checklist

Azure deployment is a planned/future activation path unless the repository has an existing prepared Azure deployment plan and infrastructure files. Before activating Azure, define the target architecture, identity/RBAC model, secrets strategy, managed database/cache/search/storage services, container or app hosting model, observability, CDN/WAF/front-door approach, backup/DR expectations, domain/TLS plan, and cost guardrails. Do not document live resource names, subscription IDs, credentials, or private incident details in public Help content.

Operational runbooks

• ✦ Checkout incident: check provider status, webhook delivery, failed order states, support ticket volume, and feature flags before messaging users.
• ✦ Download incident: check storage disk health, signed URL expiry, product file scan status, entitlement checks, and affected order IDs.
• ✦ Moderation incident: check product status changes, category changes, audit logs, public storefront impact, and support-safe creator communication.
• ✦ Payout incident: check commission status, payout holds, dispute queues, KYC/payout status, and provider settlement state without sharing internal risk signals publicly.
• ✦ CMS/navigation incident: use fallback navigation, verify Help/Support/Trust links, restore or unpublish broken CMS content, and audit who changed it.
• ✦ Mobile incident: check API reachability, cached content, push provider status, deep links, app version, and role-gated tabs.

Support CRM operating model

Use /admin/support as the operational source of truth for customer-facing cases. Public replies should be concise and safe. Internal notes can capture operator context but should not contain secrets. AI-generated drafts must be reviewed before sending, especially for billing, trust, payout, moderation, or legal-adjacent issues.