simone
03898f2a59
- Archive v2.0 phases (07-10) under .planning/milestones/ - v2.1 REQUIREMENTS/ROADMAP (Phases 11-17: Offer Studio + Proposal AI) - DESIGN-SYSTEM.md (database-view UI contract for Phases 11-14) - Phase 11 CONTEXT, DISCUSSION-LOG, PATTERNS Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
116 lines
6.3 KiB
Markdown
116 lines
6.3 KiB
Markdown
# Requirements — ClientHub v2.1 Offer Studio + Proposal AI
|
||
|
||
**Defined:** 2026-06-13
|
||
**Core Value:** Il cliente apre il link e vede esattamente a che punto è il suo progetto, cosa deve ancora succedere e cosa ha già approvato — senza dover scrivere email per chiedere aggiornamenti.
|
||
|
||
v2.0 (Phases 7–10) ha consegnato catalogo unificato, offerte con fasi, preventivo pubblico e CRM pipeline (vedi MILESTONES.md, REQUIREMENTS.md archiviato in `.planning/milestones/v2.0-REQUIREMENTS.md`). v2.1 rifà la UX di catalogo/offerte in stile database-view, ristruttura il workspace progetto, ricostruisce il CRM in stile Attio e chiude il loop commerciale con un builder preventivi AI.
|
||
|
||
## Offer Studio — Catalogo & Offerte (v1)
|
||
|
||
| ID | Requirement | Status |
|
||
|----|-------------|--------|
|
||
| OFFER-07 | L'utente vede ed edita il catalogo `services` come tabella con inline editing (click su cella → edit → invio salva) | Pending |
|
||
| OFFER-08 | L'utente assegna tag multi-select a servizi/offerte, creando nuovi tag al volo senza uscire dalla tabella | Pending |
|
||
| OFFER-09 | L'utente aggiunge un nuovo servizio/offerta tramite riga vuota in fondo alla tabella (nome + invio) | Pending |
|
||
| OFFER-10 | L'utente filtra/cerca servizi e offerte istantaneamente (ricerca client-side, nessun reload) | Pending |
|
||
| OFFER-11 | L'utente compone un'offerta trascinando servizi dal catalogo (`@dnd-kit`), con totale live aggiornato durante il drag | Pending |
|
||
| OFFER-12 | L'utente importa un CSV one-shot per popolare servizi/offerte esistenti (solo seed iniziale, non sync continuo) | Pending |
|
||
| OFFER-13 | I dati legacy di `service_catalog` e `offer_services` sono consolidati in `services` senza perdita (migration additiva) | Pending |
|
||
|
||
## Workspace Progetto — Servizi Attivi (v1)
|
||
|
||
| ID | Requirement | Status |
|
||
|----|-------------|--------|
|
||
| PROJ-06 | La tab "Preventivo" è rimossa dal workspace progetto (solo UI — `quote_items` resta intatta, `accepted_total` resta editabile via tab Pagamenti) | Pending |
|
||
| PROJ-07 | La tab "Offerte" diventa "Servizi attivi": mostra tutte le offerte assegnate al progetto (`project_offers`) | Pending |
|
||
| PROJ-08 | L'utente marca ogni "servizio attivo" come one-shot o ricorrente mensile | Pending |
|
||
| PROJ-09 | Per i servizi ricorrenti, l'utente registra in quali mesi è stata incassata la fattura (schema nuovo, additivo — UI può essere minimale) | Pending |
|
||
| PROJ-10 | La pagina "Forecast" e la relativa voce di sidebar sono rimosse | Pending |
|
||
|
||
## CRM Custom Attio-style (v1)
|
||
|
||
| ID | Requirement | Status |
|
||
|----|-------------|--------|
|
||
| CRM-08 | La tabella lead (`/admin/leads`) supporta inline editing dei campi principali (status, next_action, ecc.) senza apertura modale | Pending |
|
||
| CRM-09 | L'utente assegna tag multi-select ai lead, creando nuovi tag al volo | Pending |
|
||
| CRM-10 | Il `FollowUpWidget` è in italiano, coerente col resto dell'app | Pending |
|
||
| CRM-11 | Il form lead (`LeadForm`) valida i campi senza workaround di type-relaxation su react-hook-form | Pending |
|
||
| CRM-12 | Il flusso `SendQuoteModal` (preventivo esistente vs nuovo) non contiene rami di codice irraggiungibili | Pending |
|
||
|
||
## Dashboard — Revenue Stats (v1, bloccato su mockup utente)
|
||
|
||
| ID | Requirement | Status |
|
||
|----|-------------|--------|
|
||
| DASH-11 | La Dashboard admin mostra le statistiche di revenue mensile (ex `/admin/forecast`, calcolate da `project_offers`) | Blocked — attesa mockup dashboard utente |
|
||
|
||
## Proposal AI (v1)
|
||
|
||
| ID | Requirement | Status |
|
||
|----|-------------|--------|
|
||
| PROP-01 | L'admin avvia un builder AI che genera una proposta a partire da cliente + offerta(e) selezionata(e) + note extra fornite manualmente | Pending |
|
||
| PROP-02 | La pagina pubblica `/quote/[token]` è ridisegnata (HTML/CSS) per presentare la proposta generata | Pending |
|
||
| PROP-03 | Ogni offerta/preventivo ha un campo "link di pagamento" (Stripe Payment Link) mostrato come CTA nella pagina pubblica | Pending |
|
||
| PROP-04 | All'accettazione del preventivo, il sistema crea automaticamente cliente + progetto, copia le fasi dall'offerta e configura 1-4 pagamenti (ex-Phase 11 WIN-01..06) | Pending |
|
||
| PROP-05 | Il sistema invia via email (Resend) il link della proposta pubblica al lead (ex-Phase 12) | Pending |
|
||
|
||
## v2 Requirements (Deferred)
|
||
|
||
### Catalogo Avanzato
|
||
|
||
- **OFFER-14**: Sezioni analitiche stile Notion per le offerte (psicologia, rating, performance)
|
||
|
||
### Accesso Cliente
|
||
|
||
- **AUTH-OTP-01**: Accesso dashboard cliente via OTP email (design pronto, vedi memoria `project_clienthub_otp_access`)
|
||
|
||
### Architettura
|
||
|
||
- **ARCH-01**: Split di un modulo "compartimento stagno" in deploy separato (solo se il modulo cresce abbastanza da giustificarlo)
|
||
|
||
## Out of Scope
|
||
|
||
| Feature | Reason |
|
||
|---------|--------|
|
||
| Fatturazione e invio fatture | Solo stato pagamenti, gestione contabile fuori |
|
||
| App mobile nativa | Solo web responsive |
|
||
| Multi-utente con team | Solo admin singolo per ora |
|
||
| Prezzi singoli visibili al cliente | Vede solo il totale accettato (vincolo LOCKED) |
|
||
| File hosting | Documenti solo come URL esterni (vincolo v1, ancora valido) |
|
||
| Database esterno o Excel come fonte dati | Postgres unica fonte di verità — il problema è la UX, non il dato |
|
||
| Notion-clone completo (sezioni psicologia/rating/performance) | Troppo complesso per v1, vedi v2 Requirements |
|
||
| Deploy separati per modulo (architettura OMC multi-app) | Non finché un modulo non cresce abbastanza da giustificarlo |
|
||
|
||
## Traceability
|
||
|
||
Popolata dal roadmapper durante la creazione della roadmap.
|
||
|
||
| Requirement | Phase | Status |
|
||
|-------------|-------|--------|
|
||
| OFFER-07 | Phase 11 | Pending |
|
||
| OFFER-08 | Phase 11 | Pending |
|
||
| OFFER-09 | Phase 11 | Pending |
|
||
| OFFER-10 | Phase 11 | Pending |
|
||
| OFFER-13 | Phase 11 | Pending |
|
||
| OFFER-11 | Phase 12 | Pending |
|
||
| OFFER-12 | Phase 12 | Pending |
|
||
| PROJ-06 | Phase 13 | Pending |
|
||
| PROJ-07 | Phase 13 | Pending |
|
||
| PROJ-08 | Phase 13 | Pending |
|
||
| PROJ-09 | Phase 13 | Pending |
|
||
| PROJ-10 | Phase 13 | Pending |
|
||
| CRM-08 | Phase 14 | Pending |
|
||
| CRM-09 | Phase 14 | Pending |
|
||
| CRM-10 | Phase 14 | Pending |
|
||
| CRM-11 | Phase 14 | Pending |
|
||
| CRM-12 | Phase 14 | Pending |
|
||
| DASH-11 | Phase 15 | Blocked |
|
||
| PROP-03 | Phase 16 | Pending |
|
||
| PROP-04 | Phase 16 | Pending |
|
||
| PROP-01 | Phase 17 | Pending |
|
||
| PROP-02 | Phase 17 | Pending |
|
||
| PROP-05 | Phase 17 | Pending |
|
||
|
||
---
|
||
*Requirements defined: 2026-06-13*
|
||
*Last updated: 2026-06-13 after milestone v2.1 kickoff*
|