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 – App “7D Sales Copilot”. Un’app mobile a chat guidata che, a partire da una P.IVA/Codice Fiscale/ragione sociale, interroga il datalake Sevendata 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). È 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 ciascun progetto sono proposte tre versioni (dalla più rapida alla più completa). 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 partecipata dal gruppo Kompass International, 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)

4. Progetto B – App “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 o server MCP), con arricchimento a partire da P.IVA/CF/ragione sociale.
• I Prodotti. La knowledge base dell’offerta Sevendata.

4.3 Requisiti emersi dalla call

• Mobile-first: il commerciale è in mobilità; app a chat guidata (web responsive o nativa iOS/Android), 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 = P.IVA / Codice Fiscale / ragione sociale (nessun calendario nel PoC).
• Output “per punti”, con possibilità di approfondire on-demand ogni tema.
• 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

• App mobile a chat guidata, realizzabile come web app responsive oppure come app nativa (iOS/Android) pubblicata sugli store, a parità di prezzo (design già definito dal mockup).
• 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 o server MCP verso il datalake ed enrichment anagrafico.
• Guardrail di veridicità e citazione della fonte del dato.
• Riepilogo esportabile: al termine dell’analisi l’app produce un briefing di 1 pagina (le informazioni chiave dell’incontro), esportabile in PDF, condivisibile o inviabile via email, che il commerciale porta con sé all’incontro.

4.6 Integrazione dati: REST o MCP

Il datalake può essere esposto tramite API REST (via preferenziale per il PoC) oppure tramite un server MCP dedicato, che rende i dati direttamente “interrogabili” dall’assistente. Per un pilota su un numero contenuto di aziende (indicativamente 20–30) entrambe le vie sono adeguate; a regime andrà valutata la modalità più efficiente.

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 e fonti esterne

Oltre al datalake, il PoC può includere – come opzione – la sintesi del sito del prospect e del profilo LinkedIn, subordinata alla verifica di attendibilità del dato (rischio di omonimie azienda/persona). La regola operativa: usare il dato solo se verificato; in caso contrario, non esplorarlo.

4.9 Mockup interattivo

È già disponibile un mockup interattivo dell’app (navigabile su smartphone), fornito a parte, che illustra l’intero flusso: login, inserimento prospect, analisi, playbook, approfondimento a imbuto, assistente a chat guidata, riepilogo esportabile e follow-up.

4.10 Versioni proposte

Raccomandazione: V2 come PoC da mettere in mano ai commerciali per un periodo di prova.

4.11 Stima di dettaglio (V2)

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: web app responsive/mobile-first.
• AI: modelli LLM allo stato dell’arte (famiglia Claude) per la generazione dei playbook, con instradamento a più livelli per il controllo dei costi.
• Integrazione dati: API REST LOKI ed esposizione datalake via REST/MCP.
• Hosting: cloud del cliente o del fornitore, con connessione VPN verso l’ERP.

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.
• 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 comporta un costo di consumo dei modelli AI proporzionale all’uso. Per contenere la spesa a regime si adotta un instradamento a più livelli (modelli più leggeri per i compiti semplici, modello “forte” solo per la sintesi finale) e il caching dei dati già recuperati. In fase di PoC, con poche decine di aziende, il costo di consumo è trascurabile (nell’ordine di poche decine di euro complessivi). Il costo unitario per playbook e le proiezioni a regime saranno stimati insieme al cliente sui volumi reali.

8. Roadmap e tempistiche

• Avvio: firma NDA, accesso VPN/API e Swagger, referente tecnico e commerciale dedicati.
• PoC (5–6 settimane): erogazione delle versioni V2 dei due progetti, 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.

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 – App “7D Sales Copilot”: app mobile a chat guidata che genera playbook di preparazione all’incontro dal datalake e dal Metodo Sevendata.

3. Approccio e perimetro

Per ciascun progetto sono proposte tre versioni, dalla più rapida alla più completa. Il cliente può comporre il perimetro scegliendo una versione per progetto. È previsto uno sconto in caso di erogazione congiunta (bundle).

4. Progetto A – Pacchetti e prezzi

5. Progetto B – Pacchetti e prezzi

Formato di rilascio. L’app può essere consegnata come web app responsive oppure come app nativa (iOS/Android) pubblicata sugli store, a parità di prezzo. Sono esclusi gli account sviluppatore Apple/Google e le relative fee, oltre ai tempi di revisione degli store.

6. Bundle PoC consigliato

Erogazione congiunta delle versioni consigliate (Progetto A – V2 e Progetto B – V2), con condivisione delle attività di discovery, integrazione e delivery.

Sconto bundle rispetto ai pacchetti separati (€ 17.920): € 1.020.

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 – V2: 3–4 settimane. Progetto A – V2: ~3 settimane.
• Bundle PoC in parallelo: ~5–6 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), licenze di terze parti, account sviluppatore Apple/Google e relative fee per la pubblicazione su store.

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 ______________________________