Un assistente operativo per chi gestisce i social di più aziende.

Un ambiente unico dove stanno il marchio, i contenuti, i task, il calendario e le note delle riunioni, e sopra ci lavora un agente che quei dati li legge davvero e può modificarli con la conferma di chi di dovere. Non una chat affiancata a un gestionale: gli stessi dati, un solo posto.

La struttura ha due livelli.Sopra c'è lo studio: le persone, chi è assegnato a cosa, il conto. Sotto, ogni cliente ha uno spazio separato con il suo marchio, i suoi canali e la sua memoria, e i dati di un cliente non sono raggiungibili dagli altri. L'accesso si dà per cliente, non per persona: qualcuno è responsabile di due marchi, collaboratore su un terzo e i restanti non li vede nemmeno. Chi approva è quasi sempre una persona del cliente, che entra, dice sì o no e non ha accesso a nient'altro. È lo stesso impianto multi-azienda che ho già in produzione su un altro gestionale, con l'isolamento fatto rispettare dal database e non dal codice applicativo.

La differenza pratica sta nel contesto. Quando chiedi cinque idee, il sistema recupera il profilo del marchio, i contenuti già usciti, le decisioni prese in riunione e le correzioni fatte in passato, poi scrive. È questo che separa un output usabile da uno generico, e vale più di qualsiasi elenco di funzionalità.

Perché non basta Notion con ChatGPT accanto

È la domanda giusta da farsi prima di spendere, quindi la metto io. Con Notion, un foglio di calcolo e ChatGPT arrivi a una parte di questo, gratis: quello che non ottieni è l'agente che legge i dati da solo e ci riscrive dentro. Ogni volta devi incollare tu il contesto — che tono usate, cosa è uscito, cosa avevate deciso — e ogni volta lo incolli un po' diverso, così l'output oscilla. La piattaforma vale quei soldi solo se ti toglie quel lavoro lì: se dopo sei mesi stai ancora incollando contesto a mano, ho sbagliato io il progetto, non tu la scelta.

Hai chiesto che le tue idee vengano messe in discussione dove esiste una soluzione migliore. Queste sette incidono su tempi, costi o su quanto il prodotto sarà davvero usabile.

Non impongo lo stack, lo motivo. Questa combinazione l'ho già in produzione su altri gestionali: significa meno tempo di setup, trappole già conosciute e un percorso di deploy collaudato.

Come chiedi al punto 25, niente prompt unico che contiene tutto. Ogni richiesta viene composta da blocchi separati, ciascuno con il suo budget di spazio, e solo quelli pertinenti finiscono nel contesto.

I primi due blocchi non cambiano quasi mai: vengono messi in cache dal fornitore e a ogni richiesta successiva costano un decimo. È il motivo per cui la stima di spesa più avanti resta bassa nonostante l'uso quotidiano.

Quale modello per cosa

Lo strato di astrazione registra per ogni chiamata modello, token in entrata e in uscita, costo, latenza ed esito. Senza questa contabilità il punto 28 resta un'intenzione: con essa vedi la spesa per cliente e per tipo di attività, e puoi spostare un compito su un modello più economico quando i dati dicono che regge.

La memoria è il punto in cui questi progetti riescono o falliscono, ed è anche quello dove il brief è più esigente. Non salviamo cronologie di chat: ogni voce è un record strutturato.

Come vengono recuperate

Prima una precisazione che vale più di tutta la sezione: la maggior parte delle domande che farai — cosa scade oggi, cosa è in ritardo, a che punto è il Cliente X — non si risolve con la ricerca semantica ma con una query normale sul database, che dà sempre la stessa risposta esatta. Il semantico serve per memorie, note di riunione, copy approvati e documenti: poche migliaia di righe, non milioni. Grosso modo due terzi del contesto arrivano da query deterministiche e un terzo dal recupero per significato — ed è il motivo per cui non serve un secondo database dedicato ai vettori.

Sul terzo semantico: prima un filtro rigido — solo le voci di quel cliente e ambito — poi ricerca combinata: per significato tramite embedding e per parole esatte tramite indice testuale, perché "Reel" o un nome proprio devono essere trovati anche quando la somiglianza semantica non aiuta. I due elenchi vengono uniti, riordinati per pertinenza e ne arrivano al modello solo i primi.

Tre regole non negoziabili

• Niente scrittura silenziosa: salvare in memoria è un'azione con conferma, sempre visibile.
• Quello che arriva dal web non entra in memoria permanente, come chiedi al punto 14. Resta nella conversazione, marcato come esterno, con fonte e data.
• Ogni voce è modificabile e cancellabile dalla scheda del cliente. Una memoria che non puoi correggere diventa un problema che si aggrava da solo.

L'agente non tocca il database direttamente: passa da funzioni dichiarate, ognuna con il suo livello di autorizzazione. È così che il punto 30 diventa un meccanismo invece di un'intenzione.

Ogni chiamata porta con sé il cliente su cui sta lavorando, e l'agente vede solo gli strumenti che quella persona può usare su quel cliente: a un collaboratore non compare nemmeno publish_content. Il controllo non sta nel prompt — sta nel livello che espone gli strumenti, perché un prompt si aggira e un permesso no.

Le operazioni multiple si confermano in blocco, non una per una: «creo questi cinque task?» con l'elenco davanti. Se ogni azione richiedesse un clic separato smetteresti di usarlo entro una settimana. Ogni chiamata resta nel registro con richiesta, esito ed eventuale annullamento.

Le entità che hai elencato al punto 26, con le relazioni che contano. Ventidue tabelle: abbastanza per reggere le fasi successive, non tante da rallentare la prima.

Nel sistema finiscono dati commerciali di aziende terze: strategie, risultati, decisioni interne. Verso i tuoi clienti sei responsabile del trattamento e ti serve poterlo dimostrare.

I tredici punti che hai elencato, con due aggiunte che nascono dalle criticità: onboarding guidato del Brand Profile e timer sui task. Fuori resta tutto ciò che non serve al flusso quotidiano.

Dodici settimane, con una consegna visibile ogni due. Non ti chiedo di aspettare tre mesi per vedere qualcosa: dalla terza settimana lo puoi aprire e usare sul lavoro vero.

Chi paga è lo studio, e quanto paga dipende da quanti clienti gestisce. È l'unica struttura onesta: il costo vivo cresce con i clienti, quindi cresce anche il prezzo — ma meno che proporzionalmente, perché la parte fissa si spalma.

Avvio

Canone mensile

Aggiungere un cliente dentro uno studio non si paga a parte e non passa da me: lo fa lo studio dal flusso guidato, in dieci minuti. È il motivo per cui quel flusso sta nell'MVP: se ogni nuovo cliente richiedesse una mia configurazione, il prodotto non scalerebbe e il canone sarebbe una finzione.

Da cosa è fatto il costo vivo

Come nasce la stima AI

Ipotesi: uno studio con sette clienti e tre persone che usano l'assistente ogni giorno — circa settantacinque richieste quotidiane in tutto — più un piano editoriale e un report al mese per cliente. Prezzi di listino correnti, senza sconti introduttivi.

Il costo per cliente scende con la scala: undici euro al mese di modelli con sette clienti, contro i quaranta di un utente che ne segue uno solo. Le istruzioni di sistema e i profili dei marchi restano in cache e il grosso del contesto arriva da query normali, non dal modello. È la ragione per cui gli scaglioni possono crescere piano.

Ogni fase si preventiva quando la precedente è in uso. Preventivarle adesso significa preventivare funzioni che deciderai di non volere, il che non conviene a nessuno dei due. Le schermate però esistono già tutte nel prototipo — comprese competitor, tendenze, automazioni e la schermata di chi approva — così la discussione è su cose che si vedono, non su elenchi di funzioni.