# Phase 3: Support Provider Layer (businessite_support)

## Status (July 2026) — queues live + **MOADEfy claim economics shipped (19.0.1.3.18)**
- ✅ Language/service routing, multi-agent 3h shifts, AI task desc/translate (demo + UAT packs)
- ✅ **MOADEfy Tool–Team–Task access matrix:** job specs, tools, competency path Training (OJT/WIL) → Coaching (mentor roster) → Self-managed contract
- ✅ **Claim pool half-time economics:** complete by half ideal → **100%** commission; else broadcast same-profile team; completer **70%** / original claimer **30%**; team fail → **AI fallback** (trained / self-trained from past similar completions)
- ✅ **Mailing Support Queue (1.6.19 → 1.2.75)**: formalise + translate chat emails (outbound + inbound IMAP); AI prepare + human review + send formal; menus under Support Ops
  - Full **subject + body preview**; **attachments** on send
  - **Registered** recipients only in Human+AI queue; **external** addresses direct (optional advert)
  - Pick registered user by **name/phone/profile** (not only typed email)
- ✅ Platform **Mailcow** mailboxes linked to profiles; cron provision + IMAP fetch; **IPv4-only** outbound (Gmail deliverability)
- 🔄 Full dedicated `businessite_support` module polish; roster booking UX; client-backend task work when instance Running

## Objectives
- Build the complete `businessite_support` module.
- Enable roster booking, 3-hour shift activation, and access to the support queue only during active shifts.
- Fully implement and surface the cyclic (round-robin) assignment algorithm.
- Provide roster notifications, shift management, and task handling through the chat interface.
- Operate **Mailing Support Queue** (AI + humans) so senders never need the receiver’s mother tongue.

## Key Technical Deliverables
- New module `businessite_support` (or major extension of existing support_* models).
- Models: Enhanced `support_provider`, `support_shift`, `support_queue`, roster booking wizard. Added `ai_sponsor_id`, `allows_ai_sponsorship` on client for sharing AI subs.
- Shift activation logic that gates queue access. Multi-agent overlapping 3h shifts supported.
- Integration with `voice.message` and chat for receiving/responding during shifts. Language-based routing + AI-generated task descriptions, translations, and step-by-step instructions (per agent's lang).
- Roster calendar + booking UI (QWeb + chat commands: "book shift", "my roster").
- Notification system (chat messages, possibly email/SMS) for roster and shift starts.
- Cyclic assignment already partially in `support_queue.py` — harden and expose it.
- **AI Training & Qualification**: Odoo module-specific quizzes/assessments (sales, pos, accounting, inventory, crm, etc. from docs) in chat (web+mobile). Pass → is_qualified_support, support_services, active provider for queues. UAT cases.
- **AI Sponsorship**: Users sponsor others (e.g. support team) by sharing their preferred AI key/sub via chat ("sponsor +phone with my ai"). Backend resolves sponsor key if no personal.

## Homepage Impact
- Dedicated "Earn as a Support Provider" section with live roster booking demo and "Join the Support Roster" CTA.

## Recruitment & Adoption Value
- Directly recruits people who want to earn in structured shifts while helping businesses.
- Critical for delivering the human support promise of the platform.

## Dependencies
- Existing support models, queue logic, voice messaging.
- Phase 2 client user enhancements (for opt-in flow).

## Success Criteria
- Users can book shifts, activate during their slot, and receive/ process queue items.
- Cyclic assignment works reliably and is visible.
- Full support experience accessible primarily via chat.

## Further Reading
- [Support Queue & Cyclic Assignment Design](support_queue_algorithm.md)
- [Roster & Shift Chat Commands](support_chat_commands.md)
- [Support Provider Onboarding Flow](support_onboarding.md)

## Detailed Tasks by Layer and Role (for full implementation)

### Data Layer
- **Architect**: Define data models and relations for this phase (e.g. new tables for phase-specific entities).
- **Analyst**: Specify data validation rules, reports, and analytics for the phase.
- **Admin**: Seed initial data, configure access rights, and set up data migration scripts.
- **Developer**: Implement CRUD operations, constraints, and data sync logic.

### System Layer
- **Architect**: Design system architecture, services, and integration points for the phase.
- **Analyst**: Map system workflows, error handling, and performance requirements.
- **Admin**: Configure system parameters, cron jobs, and environment setups.
- **Developer**: Code the backend services, APIs, and background jobs for the phase.

### User Layer
- **Architect**: Design user interfaces and UX flows for the phase (web and mobile).
- **Analyst**: Define user stories, permissions, and role-based access for the phase.
- **Admin**: Set up user training, roles matrix, and onboarding for the phase.
- **Developer**: Build the UI components, controllers, and client-side logic for user interactions.

### Security Layer
- **Architect**: Design security model, authentication, and audit for phase features.
- **Analyst**: Identify security risks and compliance requirements for the phase.
- **Admin**: Configure groups, rules, and access controls; review logs.
- **Developer**: Implement security checks, encryption, and access decorators in code.

### App Layer
- **Architect**: Define app-specific features, integrations with mobile and external apps.
- **Analyst**: Specify app data models and sync requirements.
- **Admin**: Manage app configurations, publish settings, and user grants.
- **Developer**: Code the app-specific models, views, and integration points (e.g. chat commands, mobile features).