Documento tecnico · Proof of Concept

Analisi della soluzione, architettura, integrazioni e stima di tempi e costi

Preparato da Tribus Informatica S.r.l. per Sevendata S.p.A.

1. Executive summary

Il presente documento nasce dall’incontro del 2 luglio 2026 tra Sevendata e Tribus Informatica e formalizza, sul piano tecnico ed economico, due iniziative distinte emerse nel corso della call. Entrambe condividono lo stesso obiettivo di fondo: liberare tempo commerciale e amministrativo automatizzando attività oggi manuali, senza intervenire in modo invasivo sul gestionale attuale, che il cliente sta migrando.

Progetto A – Automazione attivazione ShinyStat. Un orchestratore applicativo affianca l’ERP e intercetta i contratti del servizio ShinyStat nel passaggio di stato tra “caricato” e “validato”, raccoglie in modo strutturato i dati di attivazione oggi richiesti via email, li fa validare al back-office e, nelle versioni evolute, genera la documentazione ad hoc e attiva il servizio via API.

Progetto B – Webapp “7D Sales Copilot”. Una webapp a chat guidata che, a partire da una P.IVA/Codice Fiscale/ragione sociale, interroga il datalake Sevendata (via REST API) e applica il Metodo di vendita aziendale per produrre un playbook di preparazione all’incontro (snapshot, matrice delle opportunità conversazionali, icebreaker, lettura finanziaria e action plan). Il contatto è arricchito dal profilo LinkedIn tramite un link incollato dall’utente. È accompagnata da un mockup interattivo già realizzato.

Entrambi i progetti sono impostati con logica “PoC-first”: un primo rilascio rapido, autonomo dall’ERP e dallo strumento “Aria”, per misurare il beneficio sul campo prima di industrializzare la soluzione. Per il Progetto A sono proposte tre versioni (dalla più rapida alla più completa); per il Progetto B il perimetro è stato concordato in un’unica configurazione (webapp) a valle della presentazione del mockup. Il dettaglio economico è riportato nell’Offerta commerciale allegata; la sintesi delle stime è nella tabella seguente.

Valori imponibili, IVA esclusa; esclusi i costi di infrastruttura cloud e di consumo dei modelli AI (§7).

2. Contesto e obiettivi

2.1 Il cliente

Sevendata S.p.A. è una realtà martech indipendente, specializzata in lead generation e nella fornitura di insight di marketing, finanziari e di rischio. Dispone di un datalake che integra oltre 180 fonti ufficiali, con score generati da oltre 50 algoritmi predittivi e dati di intent dei decisori. Le linee di offerta coprono quattro aree – Risk & Credit, Marketing & Sales, Compliance, International & Data – che coincidono con i quattro quadranti del metodo di vendita descritto al §4.

2.2 Origine dell’iniziativa

Nel corso della call del 2 luglio 2026 sono emerse due esigenze diverse, presentate da referenti diversi: l’automazione di un processo operativo di back-office (attivazione del servizio ShinyStat) e la realizzazione di uno strumento a supporto della rete commerciale. Il cliente ha esplicitamente richiesto una proposta di tempi e costi per entrambe, con la possibilità di articolarle in più versioni (“dalla più veloce alla più completa”).

2.3 Principio guida: non intervenire sull’ERP

Il gestionale attuale – denominato LOKI e fornito da SEC Group – è in una fase di cambiamento/migrazione. Il cliente ha chiesto di non introdurre modifiche invasive su di esso. Entrambe le soluzioni sono quindi progettate per affiancarsi all’ERP tramite le sue API REST (accessibili in VPN), lasciando invariato il sistema esistente.

3. Progetto A – Automazione attivazione ShinyStat

3.1 Situazione attuale (as-is)

Sevendata rivende il servizio di web analytics ShinyStat. Alla vendita, il commerciale carica il contratto nell’ERP LOKI. Per questo specifico servizio, però, i campi di attivazione non sono obbligatori (a differenza di altri servizi, come “Easy Business”, in cui lo sono). Di conseguenza il back-office deve richiedere manualmente, tramite una email standard, le informazioni mancanti:

• dati anagrafici del cliente (P.IVA, ragione sociale, ecc.);
• email dell’utilizzatore della dashboard, spesso diversa dall’intestatario del contratto;
• condizioni per l’installazione del codice di tracciamento, che varia in base al CMS del sito del cliente.

Le informazioni raccolte vengono gestite off-line dal back-office, poiché nell’ERP non esistono i campi dedicati per questo servizio. Successivamente viene redatta, in parte manualmente, la documentazione ad hoc per ciascun cliente.

3.2 Criticità

• Attività manuale e ripetitiva a carico del back-office (solleciti, verifica, riscrittura).
• Tempi di attivazione allungati e dipendenti dalla reattività del commerciale.
• Nessun vincolo di completezza dato: il contratto può procedere pur mancando informazioni indispensabili.

3.3 Vincoli

• Nessuna modifica invasiva all’ERP LOKI (fase di migrazione).
• Accesso ai dati dell’ERP tramite API REST, disponibili in VPN presso il fornitore; documentazione Swagger da fornire.
• Soluzione pensata come “ponte” per il periodo di interim, ma con architettura riutilizzabile.

3.4 Soluzione proposta (to-be)

Si introduce un orchestratore applicativo che affianca l’ERP e governa il completamento del contratto ShinyStat nel passaggio di stato “caricato → validato”. Il flusso target:

• Intercettazione. All’ingresso di un contratto ShinyStat, l’orchestratore rileva lo stato e verifica la presenza dei dati di attivazione.
• Raccolta dati. Se mancano informazioni, il sistema invia al commerciale un form strutturato (link) con i soli campi mancanti. Il contratto resta “non completato” fino alla compilazione – e con esso la relativa provvigione – creando un incentivo naturale al completamento.
• Validazione. Il back-office (referente attivazioni) verifica i dati con un semplice clic di conferma.
• Documentazione. Il sistema genera la documentazione ad hoc da template, precompilando i campi (ragione sociale, utilizzatore, condizioni di installazione).
• Attivazione. I dati vengono scritti/attivati via API sull’ERP e lo stato aggiornato; il processo prosegue poi come oggi (validazione amministrativa → produzione → fatturazione).

3.5 Architettura

• Orchestratore/servizio middleware (event-driven o polling sull’ERP) con macchina a stati per il contratto ShinyStat.
• Web-form responsive per il commerciale e mini-console di validazione per il back-office.
• Motore di templating per la generazione documentale (DOCX/PDF) con segnaposto.
• Layer di integrazione verso le API REST LOKI (lettura anagrafiche/stato, scrittura attivazione/stato) e servizio di notifica email.

3.6 Integrazione con l’ERP LOKI

Dalla collection API fornita risultano già disponibili endpoint di autenticazione a token e di gestione anagrafiche, listini, plafond e ordini (dettaglio in Appendice A). L’integrazione richiederà la conferma degli endpoint di lettura stato contratto e di scrittura dei campi di attivazione; in assenza di API dedicate, l’orchestratore può gestire il completamento in modo autonomo e sincronizzare lo stato disponibile.

3.7 Versioni proposte

Raccomandazione: V2 come PoC, con evoluzione a V3 una volta consolidate le API di scrittura dell’ERP.

3.8 Stima di dettaglio (V3)

3.9 Estensioni opzionali (da perimetrare con il referente ShinyStat)

Nel corso della call sono emerse ulteriori opportunità per il Progetto A, da valutare con il referente tecnico ShinyStat (Andrea Rossi) e non incluse nella stima: verranno perimetrate e quotate a parte.

• Area cliente self-service: un terzo livello (oltre a back-office e agente) in cui il cliente finale accede, seleziona il proprio CMS (WordPress, Magento, PrestaShop…) e segue una guida passo-passo per l’installazione del codice di tracciamento ShinyStat.
• Verifica installazione automatica: alla pressione di un pulsante, il sistema verifica la presenza dello script ShinyStat sul sito del cliente (lettura come un normale visitatore, non scraping invasivo), con fallback al controllo manuale in caso di WAF/bot-protection.
• Alert perdita monitoraggio: notifica quando un sito precedentemente tracciato smette di esserlo (codice rimosso o sito modificato), evento oggi non intercettato.

Nota. Queste estensioni non sono quantificate: fattibilità ed effort verranno definiti dopo il confronto tecnico con il referente ShinyStat.

4. Progetto B – Webapp “7D Sales Copilot”

4.1 Obiettivo

Fornire alla rete commerciale uno strumento che uniformi e potenzi la preparazione degli incontri, trasformando l’agente da venditore di funzionalità a partner strategico. L’app produce, a partire dal solo nominativo del prospect, un playbook operativo per l’incontro.

4.2 I tre motori

• Il Metodo. Il “Metodo Sevendata” redatto dalla direzione commerciale, trasformato in system prompt dell’assistente.
• I Dati. Il datalake Sevendata (via API REST bidirezionale), con arricchimento a partire da P.IVA/CF/ragione sociale.
• I Prodotti. La knowledge base dell’offerta Sevendata.

4.3 Requisiti emersi dalla call

• Webapp: strumento a chat guidata accessibile da browser (desktop e responsive), non a domanda libera.
• PoC autonomo, realizzato al di fuori dello strumento “Aria”; l’integrazione con Aria e con il calendario è rimandata alla Fase 2.
• Input = azienda (P.IVA / Codice Fiscale / ragione sociale, risolta dal datalake con disambiguazione) + persona di contatto, indicata incollando il link del profilo LinkedIn (univoco, azzera le omonimie; nessuna ricerca esterna né provider a pagamento). Il contatto è inserito a mano perché non sempre presente nel datalake. Nessun calendario nel PoC.
• Output “per punti”, con possibilità di approfondire on-demand ogni tema.
• Provenienza del dato evidenziata: ogni elemento del playbook indica visivamente l’origine — dato proprietario Sevendata (datalake) vs profilo LinkedIn — tramite badge e bordo colorato.
• Veridicità del dato: priorità assoluta. In assenza di dati attendibili il sistema dichiara “informazione non disponibile” anziché ipotizzare.

4.4 Il Metodo Sevendata come system prompt

Il playbook è un documento testuale che viene codificato nel prompt di sistema dell’assistente. In fase di codifica saranno recepite le correzioni già indicate dal cliente sul prompt attuale, tra cui:

• uso del profilo DISC in luogo della profilazione psicologica dai social (e con cautela);
• icebreaker riferito all’azienda, non alla persona;
• correlazione dei dati alle aree di intervento (Mercato → impatto sull’azienda → interpretazione Sevendata), non al singolo prodotto;
• domande aperte e non accusatorie (“Quali sono le vostre politiche sul credito?”, non “Avete pagamenti lunghissimi, cosa fate?”);
• follow-up come “proposta” su misura, non “offerta”, e solo in presenza di interesse condiviso;
• numeri sempre reali e coerenti (es. corretta lettura di CCN, DSO, esposizione e perdite attese).

4.5 Architettura del PoC

• Webapp a chat guidata, accessibile da browser (desktop e responsive), con il design già definito dal mockup. Nessuna pubblicazione su app store.
• Orchestrazione AI: composizione di dati datalake + knowledge prodotti + Metodo, con output strutturato (snapshot, matrice a 4 quadranti, icebreaker, lettura finanziaria, persona, action plan) e approfondimenti on-demand.
• Connettore dati: client REST bidirezionale verso il datalake Sevendata (lettura dei dati e scrittura degli esiti/report).
• Guardrail di veridicità e citazione della fonte del dato.
• Riepilogo esportabile: al termine dell’analisi l’app produce un briefing di 1 pagina, esportabile in PDF, inviabile via email o come audio (“raccontamelo”) su WhatsApp per l’ascolto in mobilità. L’app resta snella: non conserva un archivio, l’agente esporta/invia ciò che gli serve.
• Follow-up e report obbligatorio: generazione di una “proposta” su misura; al termine dell’incontro l’agente compila un form obbligatorio di report al responsabile (esito, vantaggio ottenuto, prossimo passo), inviato a Sevendata via REST — è anche l’indicatore (KPI) di efficacia dello strumento.
• Assistente guidato: un bot che spiega come usare l’app e riesegue il Metodo su richiesta (riformula l’icebreaker, approfondisci un quadrante); non è una chat libera né un RAG.

4.6 Integrazione dati: REST API bidirezionale

Lo scambio con il datalake Sevendata avviene tramite API REST bidirezionali: la webapp legge i dati del prospect da Sevendata e vi restituisce gli esiti (report/KPI post-incontro), sempre in REST. Per un pilota su un numero contenuto di aziende (indicativamente 20–30) la via REST è adeguata e semplice da esercire.

4.7 Motore di generazione del playbook

Il cuore dell’app è la Matrice delle Opportunità Conversazionali a quattro quadranti (Risk & Credit, Marketing & Sales, Compliance, International & Data). Per ciascun quadrante il sistema trasforma i dati in spunti e domande aperte, con un approccio a imbuto che collega i cambiamenti di mercato all’impatto sull’azienda e all’interpretazione Sevendata. La lettura finanziaria è espressa in chiave di business (esposizione media, quota a rischio, perdite attese, “fatturato di recupero”).

4.8 Arricchimento del contatto (LinkedIn)

Il PoC usa un’unica fonte dati proprietaria — il datalake Sevendata — senza confronto con fonti finanziarie esterne. L’unico arricchimento esterno è il profilo LinkedIn del contatto, letto dal link incollato dall’utente: non c’è ricerca per nome né provider dati/enrichment a pagamento. La provenienza è sempre evidenziata (dato proprietario Sevendata vs profilo LinkedIn) e vale la regola di veridicità: usare il dato solo se attendibile, altrimenti dichiararlo non disponibile. Il trattamento è limitato al profilo indicato dall’utente, nel rispetto dei termini di servizio e del GDPR.

4.9 Mockup interattivo

È già disponibile un mockup interattivo della webapp (navigabile da browser), che illustra l’intero flusso: login, inserimento prospect (azienda + link LinkedIn), analisi dal datalake, playbook, approfondimento a imbuto, assistente a chat guidata, riepilogo esportabile, proposta e report obbligatorio post-incontro.

4.10 Perimetro del PoC (webapp)

A seguito della presentazione del mockup, il perimetro è stato concordato in un’unica configurazione:

• Webapp a chat guidata (browser), design del mockup; input azienda + link LinkedIn incollato dall’utente; Metodo→system prompt completo con le correzioni; 4 quadranti + approfondimenti; lettura finanziaria (solo dato Sevendata); persona (DISC); action plan.
• Riepilogo esportabile (PDF/email/audio WhatsApp), proposta di follow-up e form obbligatorio post-incontro (report al responsabile / KPI di efficacia).
• Integrazione REST bidirezionale con Sevendata (dati + esiti); enrichment da P.IVA/CF; guardrail di veridicità; 4 aziende demo; tuning.

4.11 Stima di dettaglio

5. Architettura complessiva e stack tecnologico

Le due soluzioni condividono un impianto comune: servizi applicativi che si affiancano all’ERP e ne consumano le API, senza modificarlo. Stack indicativo (da confermare con il cliente):

• Backend/orchestrazione: servizio applicativo (Node.js/Python) containerizzato.
• Frontend: webapp responsive (browser desktop e mobile).
• AI: modelli LLM esterni allo stato dell’arte, ospitati in UE (data residency), con instradamento a più livelli (modelli leggeri per i compiti semplici, modello “forte” per la sintesi) per il controllo dei costi.
• Integrazione dati: API REST LOKI (Progetto A) ed esposizione datalake Sevendata via REST bidirezionale — lettura dati e scrittura esiti/KPI (Progetto B).
• Hosting: cloud del cliente o del fornitore, con connessione VPN verso l’ERP.

5.1 Schema infrastrutturale — Progetto A (ShinyStat)

5.2 Schema infrastrutturale — Progetto B (7D Sales Copilot)

Nota. L’infrastruttura server a supporto (hosting, ambienti, gestione e manutenzione) non è compresa nel PoC e sarà quantificata separatamente in base alla collocazione scelta — presso Tribus Informatica oppure sull’infrastruttura del cliente.

6. Sicurezza, privacy e conformità

• Trattamento dei dati in conformità al GDPR; definizione dei ruoli (titolare/responsabile) e DPA se necessario.
• Modelli AI e dati ospitati in UE (data residency europea), come richiesto in fase di call.
• Accesso all’ERP tramite VPN e credenziali dedicate; principio del minimo privilegio sulle API.
• Politica di veridicità del dato per il Progetto B: fonte tracciata, nessuna informazione non verificata.
• Attività svolte sotto NDA tra le parti (da formalizzare, come emerso in call).

7. Costi di esercizio (AI/consumo)

Il Progetto B usa modelli LLM esterni ospitati in UE, con instradamento a più livelli: modelli leggeri per i compiti ad alto volume (retrieval, classificazione, estrazione, riformulazioni) e un modello “forte” solo per la sintesi finale del playbook. La scelta del modello è il fattore che determina di gran lunga il costo: tra un modello leggero e uno premium il costo per playbook varia di oltre 100 volte. Il raffronto seguente riporta i listini a consumo dei principali provider, con hosting/dati in UE (GDPR), aggiornati a luglio 2026 (indicativi, IVA esclusa; cambio USD→EUR ~0,88).

Ipotesi di calcolo. ~50 agenti; per una preparazione completa (playbook a 4 quadranti + 1–2 approfondimenti + riepilogo/audio + bozza di follow-up + Q&A) ~40.000 token in ingresso e ~12.000 in uscita; scenario medio ~2.000 preparazioni/mese.

Raffronto per modello (hosting UE/GDPR)

Architettura a più livelli e caching. In esercizio i compiti ad alto volume vengono instradati su un modello leggero UE e solo la sintesi del playbook su un modello di fascia media/forte; con il caching del Metodo (system prompt riusato) l’input ripetuto costa ~10%. L’effetto combinato colloca il costo effettivo nella parte bassa delle forbici sotto riportate.

Costo mensile per intensità d’uso e configurazione

Raccomandazione. Per il PoC e la messa a regime si consiglia la configurazione bilanciata su hosting UE (es. Mistral Large 3 / Gemini 2.5 Flash / GPT-5 mini per la sintesi + modello leggero per i compiti ad alto volume): nello scenario medio (~50 agenti, ~2.000 preparazioni/mese) il costo è dell’ordine di ~€ 60–75 al mese, riducibile a ~€ 30–50 con instradamento a più livelli e caching. La configurazione premium (Claude Sonnet/Opus, GPT-5 di fascia alta) resta disponibile per la massima qualità di sintesi, a costo maggiore (~€ 500–900/mese). Il costo è a consumo, scalabile e monitorabile per agente e per playbook; a questi volumi non è giustificata un’infrastruttura LLM proprietaria (che ha senso solo a volumi molto elevati).

8. Roadmap e tempistiche

• Avvio: firma NDA, accesso VPN/API e Swagger, referente tecnico e commerciale dedicati.
• PoC (6–7 settimane): erogazione di Progetto A – V2 e Progetto B – webapp (PoC concordato), in parallelo ove possibile.
• Verifica sul campo: periodo di prova con i commerciali e con il back-office.
• Fase 2 – industrializzazione: integrazione con Aria e con il calendario (Progetto B), evoluzione a V3 (Progetto A). Stima indicativa nell’Offerta.

9. Assunzioni, dipendenze e rischi

• Disponibilità tempestiva di documentazione API (Swagger), accesso VPN e dati demo (4 aziende con contenuto datalake completo).
• Le stime presuppongono un perimetro PoC; ampliamenti di scope saranno gestiti con change request.
• La copertura/qualità di alcune fonti esterne (es. LinkedIn) può limitare il modulo di arricchimento del Progetto B.
• Eventuali interventi lato SEC sull’ERP sono esclusi dal presente perimetro.

10. Prossimi passi

• Formalizzazione dell’NDA tra Sevendata e Tribus Informatica.
• Condivisione della documentazione API dell’ERP (Swagger) e degli accessi VPN.
• Selezione delle versioni (per progetto) e conferma del bundle PoC.
• Kick-off e pianificazione operativa.

Appendice A – Endpoint API LOKI rilevati

Dalla collection Postman fornita (base https://sevendata.secgroup.biz):

Nota: gli endpoint di lettura stato contratto e di scrittura dei campi di attivazione ShinyStat saranno verificati sulla documentazione completa.

Appendice B – Il Metodo Sevendata in sintesi

Il metodo si articola in ciò che si studia (snapshot aziendale, persona intelligence, analisi finanziaria e di rischio, intelligence qualitativa dalla nota integrativa) e in come si conduce l’incontro (storytelling commerciale, icebreaker, filtro strategico a imbuto, matrice delle opportunità conversazionali, action plan Prima/Durante/Dopo). La comunicazione segue lo schema: 1) Enuncio 2) Descrivo 3) Condivido 4) Esprimo un’opinione. I quattro quadranti della matrice – Risk & Credit, Marketing & Sales, Compliance, International & Data – corrispondono alle aree di offerta Sevendata.

Offerta economica

Proposta di Proof of Concept – Progetto A (ShinyStat) e Progetto B (Sales Copilot)

Preparato da Tribus Informatica S.r.l. per Sevendata S.p.A.

1. Premessa

La presente offerta dà seguito all’incontro del 2 luglio 2026 e propone la realizzazione, in logica Proof of Concept, delle due iniziative descritte nel Documento tecnico allegato. L’approccio è “PoC-first”: un primo rilascio rapido e autonomo, per misurare il beneficio sul campo prima dell’industrializzazione. Il perimetro del Progetto B è stato aggiornato a valle della presentazione del mockup: una webapp basata sul solo datalake Sevendata (REST API bidirezionale), con arricchimento LinkedIn da link fornito dall’utente.

2. Oggetto

• Progetto A – Automazione attivazione ShinyStat: orchestratore che raccoglie e valida i dati di attivazione e li riporta nel processo, senza modificare l’ERP.
• Progetto B – Webapp “7D Sales Copilot”: webapp a chat guidata che, dal solo datalake Sevendata (REST API), genera il playbook di preparazione all’incontro applicando il Metodo.

3. Approccio e perimetro

Per il Progetto A sono proposte tre versioni, dalla più rapida alla più completa. Per il Progetto B il perimetro del PoC è stato concordato in un’unica configurazione (webapp) a seguito della presentazione del mockup. È previsto uno sconto in caso di erogazione congiunta (bundle).

4. Progetto A – Pacchetti e prezzi

Estensioni Progetto A (opzionali, da perimetrare). Emerse in call e da valutare con il referente tecnico ShinyStat: area cliente self-service per l’installazione, verifica automatica dell’installazione, alert perdita monitoraggio. Non quantificate in questa offerta; saranno stimate a parte.

5. Progetto B – Webapp “7D Sales Copilot” (PoC concordato)

A valle della presentazione del mockup, il perimetro del PoC è stato definito in un’unica configurazione: una webapp (non app nativa) a chat guidata che, dal solo datalake Sevendata tramite REST API bidirezionale, produce il playbook di preparazione all’incontro applicando il Metodo. Le fasi del playbook restano invariate.

• Input azienda (P.IVA/ragione sociale) e contatto tramite link LinkedIn incollato dall’utente — nessuna ricerca né provider esterni a pagamento.
• Metodo completo → 4 quadranti + approfondimenti, lettura finanziaria (solo dato Sevendata), persona (DISC), action plan.
• Riepilogo esportabile (PDF/email/audio WhatsApp) e proposta di follow-up.
• Form obbligatorio post-incontro (“report al responsabile”): esito, vantaggio ottenuto e prossimo passo, con invio a Sevendata via REST — anche come indicatore (KPI) di efficacia dello strumento.
• Integrazione REST bidirezionale (Sevendata ↔ webapp); 4 aziende demo; tuning.

Formato di rilascio. Il deliverable è una webapp accessibile da browser (desktop e responsive). Non è prevista la pubblicazione sugli app store, quindi nessun costo di account/abbonamento sviluppatore.

6. Bundle PoC consigliato

Erogazione congiunta del Progetto A – V2 e del Progetto B (webapp PoC concordato), con condivisione delle attività di discovery, integrazione e delivery.

Sconto bundle rispetto ai pacchetti separati (€ 18.180): € 980.

7. Tariffa e figure professionali

I pacchetti sono proposti a corpo, alla tariffa di € 40/ora (€ 320/giornata), valida anche per eventuali attività extra-perimetro (change request). Le figure professionali coinvolte:

• Project Manager / Business Analyst
• Senior Software Engineer (full-stack / backend)
• AI / LLM Engineer
• UX/UI Designer

8. Tempistiche

• Avvio entro 1–2 settimane dalla firma, subordinato alla disponibilità di NDA, accessi VPN/API e dati demo.
• Progetto B – webapp: ~4–5 settimane. Progetto A – V2: ~3 settimane.
• Bundle PoC in parallelo: ~6–7 settimane complessive.

9. Modalità di erogazione e pagamento

• Erogazione a corpo per fasi, con stato avanzamento lavori condiviso.
• Pagamento suggerito: 40% all’avvio, 30% a metà percorso, 30% al rilascio del PoC.
• Sono esclusi: costi di consumo dei modelli AI (a consumo — ~€ 60–75/mese per ~50 agenti in uso medio con modelli UE di fascia bilanciata, riducibili a ~€ 30–50; raffronto per modello e configurazione nel Documento Tecnico §7) e le licenze di terze parti. Trattandosi di una webapp, non sono previsti account/abbonamenti sviluppatore per gli app store; l’arricchimento del contatto avviene tramite il link LinkedIn fornito dall’utente, senza provider dati esterni a pagamento.

Infrastruttura server. L’intera infrastruttura server a supporto (hosting, ambienti, gestione e manutenzione) non è compresa nella presente offerta e sarà quantificata a parte una volta definita la collocazione: presso Tribus Informatica oppure sull’infrastruttura del cliente.

10. Fase 2 – Industrializzazione (indicativa)

A valle del PoC, l’evoluzione in produzione è stimabile – in via preliminare e non impegnativa – come segue:

11. Condizioni

• Prezzi in Euro, IVA esclusa.
• Offerta valida 30 giorni dalla data di emissione.
• Attività svolte sotto NDA; proprietà intellettuale del deliverable in capo al cliente al saldo.
• Le stime in giornate presuppongono il perimetro descritto; variazioni gestite con change request alle tariffe di cui al §7.

Per accettazione – Sevendata S.p.A.

Data ________________ Firma e timbro ______________________________