# Product ## Platform web ## Stack Next.js, React, TypeScript, Tailwind CSS, shadcn/ui, TanStack Query, TanStack Table, Recharts, Lucide Icons (specified explicitly in the project's own build spec, `agente.md`, "Frontend" section — not delegated). ## Users Two audiences, both authenticated staff (never a public visitor): - **Platform admins** (B2BCall's own operators): manage tenants, plans/subscriptions, quotas, global infrastructure (FreeSWITCH nodes, SIP profiles, health), AI provider catalog, billing rate decks/price books, system users/permissions/audit. - **Tenant staff** (a client company's own team): tenant admins configure trunks/extensions/queues/campaigns/agents/AI settings/billing for their own account; agents work the live call queue; supervisors monitor campaigns/queues/agents in real time and review AI call analysis, quality scorecards, and reports. ## Product Purpose B2BCall is a multi-tenant SaaS call-center platform: predictive dialer, inbound/outbound call center (FreeSWITCH-backed), AI-driven call transcription/analysis/QA scorecards, and usage-based billing, all under strict per-tenant data isolation. Success is a tenant running real campaigns and inbound queues, with agents connected and productive, in an interface that looks and feels like a modern SaaS product a client would trust with production traffic. ## Positioning External, multi-tenant SaaS product sold to other companies running their own call centers — not an internal single-operator tool. The interface must carry plan/quota framing (a tenant sees its own consumption and limits) and customer-facing polish throughout, per the build spec's explicit instruction (section 164) that it must read as a modern professional SaaS product, never as an internal admin panel. ## Operating Context Real-time operations are central: live call/agent/queue counters that move continuously, predictive-dialer campaigns paced against CPS/concurrency limits, agents moving through pause/wrap-up/available states, calls flowing through queues to agents. Supporting workflows: campaign creation (a defined 7-step wizard: General → Telephony → Dialing → Schedule → Recording & AI → Leads → Review), lead import/blocklist management, call recording playback with synced transcript, AI analysis review, quality scorecard evaluation, and monthly billing statement review (explicitly never called an invoice/nota fiscal — "Usage Statement" / "Billing Statement" / "Relatório de Consumo" only). ## Capabilities and Constraints - Full navigation IA already specified for both audiences (`agente.md` sections 168-169): Platform menu = Visão Geral / Clientes (Tenants, Planos, Assinaturas, Quotas) / Billing (Consumo, Tarifas, Fechamentos, Relatórios) / Infraestrutura (FreeSWITCH, SIP Profiles, Nodes, Saúde) / IA (Providers, Modelos, Uso, Custos) / Sistema (Usuários, Permissões, Auditoria, Configurações). Tenant menu = Dashboard / Discador / Call Center / Telefonia / Monitoramento / Gravações / IA / Relatórios / Administração. Menu items the current user lacks permission for do not render. - Layout is fixed by spec: collapsible sidebar + topbar + content (section 166). - Server-side pagination, search, filters, sort, column visibility, row actions, bulk actions, and export are required on every data table (section 173). - Status must never be color-only (accessibility, section 176); consistent badge colors are specified per campaign status (DRAFT gray, READY blue, RUNNING green, PAUSED yellow, DRAINING orange, STOPPED red, COMPLETED dark green, ERROR red). - Light/Dark/System theming is required unless it compromises higher priorities (section 174). - Desktop/notebook/tablet are the priority breakpoints; the agent's own screen must work well at smaller resolutions too (section 175). - A real backend is live today (NestJS/Fastify REST API on `localhost:3000`, 20+ endpoints across auth, extensions, trunks, queues, agents, campaigns, leads, calls, recordings, AI providers/pipeline, quality scorecards) — this is not a mockup exercise; real data is available to wire against once auth is in place. No frontend code exists yet beyond this branding asset. - Backend has no billing UI-facing endpoints yet for the newest schema (rate decks, price books, billing periods/statements) — those are mid-build; the Platform Dashboard itself (tenants, quotas, infra health, AI usage) is fully backed today. ## Brand Commitments - Name: **B2BCall**. Wordmark and mark exist at `apps/frontend/public/branding/b2blogo.png` — a rounded-square chat/analytics icon (bar-chart bars + phone handset + chat-bubble tail) paired with a two-tone "B2B" (dark navy) + "Call" (bright blue) wordmark. Palette read directly off the mark: deep navy (~#0B1B3A), a saturated blue (~#2554FF), and a teal accent (~#2EC9C0) used sparingly for one bar/dot. This is binding — build from these colors and this mark, not a freely chosen new palette. - Login screen must use this logo (section 167): "Brand B2BCall | Login Form" split layout on desktop, responsive down. - Explicit anti-brief (section 164): must **not** read as FreePBX, FusionPBX, a generic Linux admin panel, dated Bootstrap, or any legacy on-prem PBX tool. ## Evidence on Hand - Real logo/mark: `apps/frontend/public/branding/b2blogo.png`. - Full build spec with exact page-level requirements for dashboards, menus, wizards, tables, and status semantics: `agente.md` sections 161-176 (and the whole document for domain vocabulary). - Live backend and database schema this session already built and tested end-to-end (see `docs/*.md` at the repo root — `ARCHITECTURE.md`, `PREDICTIVE_DIALER.md`, `AI_PIPELINE.md`, `QUALITY_SCORECARDS.md`, etc.). - No testimonials, customer logos, pricing page copy, or marketing claims exist — none should be fabricated; this build is internal admin/ops surfaces, not a marketing site. ## Product Principles 1. Real-time state is the product — counters, badges, and queues must read as genuinely live, not as a static report someone might refresh. 2. Never let this look like the telecom/PBX tooling it's replacing (section 164) — every screen should read as a modern, venture-funded SaaS dashboard first, telecom tool second. 3. Multi-tenant discipline shows up in the UI too — a tenant's plan/quota context (consumption vs. limit) is always nearby, never buried. 4. Status is never color-only; every state has a label, not just a hue (section 176). 5. Build the platform-admin surface first as the reference implementation of the design system (tokens, layout shell, table pattern, badge system) that every later tenant-facing screen extends, rather than a one-off. ## Accessibility & Inclusion Explicit requirement (section 176): labels, full keyboard navigation, visible focus states, ARIA, sufficient contrast, and status conveyed by more than color alone.