MultiverbeBOS

Motore di crescita · roadmap "da farsi" (direttive founder 2026-06-06)

Raccolto a fine sessione #313 (i 3 esecutori mancanti del piano di crescita ora esistono — vedi decisions-log + memory project_sole_actions_catalog_2026_06_03). Qui le 2 feature di prodotto che il founder ha chiesto di costruire nelle prossime sessioni, con il pattern tecnico e i punti da confermare. Il costo Inngest è documentato in canon/05-stack.md.

1. Cron del motore — timezone per-cliente + frequenza per-tier

Oggi (hardcoded): il fan-out che accende cervello + Sole-che-agisce è un unico cron Inngest globale: triggers: [{ cron: 'TZ=Europe/Zurich 0 6 * * *' }] in frontend/multiverbe-app/api/_inngest/functions/analyze-planet-data.ts (~riga 536). Emette 1 evento insights/analyze.workspace per ogni workspace attivo → analyze-workspace-insights (cervello) e sole-actions-workspace (azioni) reagiscono.

Problema: ogni cliente/paese ha il suo fuso. Le 06:00 di Zurigo non sono le 06:00 del cliente.

✅ DECISIONE 2026-06-07 (founder + Claude · "scegli come una big tech"): 1 spin/giorno per TUTTI i tier — un solo "briefing del mattino" calmo, all'ora locale scelta dal cliente. Niente frequenza per-tier: 2-3 spin/giorno sono troppi (rumore per tutti, non solo per i piccoli). Restraint big-tech (Apple/Linear/Stripe): si differenzia sul potere, non sulla frequenza con cui si disturba l'utente. La differenza tra tier resta su: caps (cold_emails 0/1000/5000), canali, auto-send, profondità (strategist Opus). L'urgenza (es. nuovo lead arrivato di pomeriggio) si gestisce event-driven — reazione immediata e mirata, già gated da autonomia/cap — NON con più spin al giorno.

Da costruire (semplificato dalla decisione):

  • (a) Timezone per-workspace — dal fuso del cliente (onboarding / paese). Pronti almeno per tutta l'Europa, non solo Zurich. Probabile fonte: workspaces (aggiungere timezone/country se assente) o derivato dal locale.
  • (b) Orario preferito settabile dall'utente — il titolare sceglie a che ora vuole il "giro del mattino" (default sensato per fuso).
  • (c) Frequenza per tier → SCARTATA: 1/giorno per tutti. Niente cap-spin in tier_caps, niente cron multipli → build più semplice.

Pattern tecnico: sostituire il cron fisso TZ=Europe/Zurich 0 6 * * * con un cron orario (0 * * * *) che fa fan-out solo ai workspace dove (ora-locale-del-workspace == ora-preferita-del-cliente). Un giro al giorno per workspace, al momento giusto nel suo fuso. Nessun conteggio spin.

Anti-"troppo" (il vero guard, indipendente dalla frequenza) — affinamento da decidere quando si costruisce: tetto giornaliero di output (card mostrate) + invii AUTO bassi (max pochi/giorno ai clienti del cliente, separato dal cap mensile) + l'idempotenza già esistente (winback 30g · recensione 60g · lead 14g · content 1/settimana). È qui che si previene il "bollino giallo", non nella frequenza.

Nota costo: 1 spin/giorno → costo Inngest ancora più contenuto (vedi canon/05-stack.md). Trascurabile a questa scala.

2. Sales — pipeline di follow-up personalizzabile (N step + canale)

Oggi (hardcoded): frontend/multiverbe-app/api/_inngest/functions/sales-outreach-followup.ts fa un solo follow-up (email-2) a +3 giorni fissi (FOLLOWUP_DELAY_MS in api/sales/send-outreach.ts).

Da costruire: una sequenza configurabile:

  • N step, ognuno con: canale (email · sms · whatsapp · call = task per l'umano, non automatica · dm) + ritardo + template.
  • Config per-workspace (con default per-settore).
  • Tabella nuova tipo outreach_sequences (+ step) · il runner Inngest cammina gli step con step.sleepUntil tra uno e l'altro (durevole, sopravvive ai deploy · stesso pattern di oggi ma generalizzato).

Dipendenze canali oltre l'email:

  • SMS → provider sovrano EU (da scegliere · no provider US per PII).
  • WhatsApp → Meta API + business verification (post-gate).
  • "chiamata" → non automatica: genera un task/promemoria nel CRM per il venditore.

Si innesta sull'Hub Messaggi nel CRM multi-canale (memory feedback_notification_architecture_hub_crm): i pianeti emettono eventi, l'Hub rende+instrada per canale/lingua/fuso. La sequenza Sales è un consumatore di quell'Hub, non un'isola separata.

3. Costo Inngest (fatto — documentazione)

Capito e segnato in canon/05-stack.md (riga stack + note costi Build/Scale): Free Hobby $0 (50k execution/mo, fattura per step-execution), Pro da $75/mo (1M execution). Stima: gratis fino a ~100 clienti attivi (ordine di grandezza), poi Pro. Da ri-misurare dal dashboard a regime.

🔴 Prima di costruire (1) e (2): confermare col founder i numeri spin-per-tier (refuso "pro 2 e pro 1"). Entrambe additive (migrazioni tier_caps + outreach_sequences), nessuna rottura. Owner: Gregorio (decisioni) · prossima sessione (build).