Domande frequenti

Scegli un workflow ad alto volume e avvialo in un singolo canale. Dimostra che le risposte sono accurate e che le escalation raggiungono le persone giuste, poi espandi a più canali e pack.

I copilot generici sono legati al modello di un singolo fornitore. Threada è una piattaforma di lavoro: ogni richiesta diventa un WorkItem tracciato con controlli policy, esecuzione governata e analytics sui risultati, su qualsiasi LLM.

No. Threada lavora accanto ai tuoi strumenti attuali. Cattura e struttura le richieste, poi esegue azioni approvate nei sistemi che già usi.

L'AI gestisce comprensione e strutturazione. Controlli policy, code di revisione e approvazioni gestiscono le eccezioni. Le persone restano nel loop per tutto ciò che è ad alto rischio.

Contenimento, time-to-resolution, qualità dell'escalation, tempo del ciclo di approvazione e successo delle azioni: risultati a verbale, non conteggi di interazioni.

Esegui gate di valutazione che testano estrazione, routing, grounding e comportamento delle azioni. Fai rollout graduale con traffico canary, shadow mode e rollback con un clic.

I team che gestiscono lavoro operativo ad alto volume sotto responsabilità: operazioni e assistenza clienti, IT e approvvigionamento, sicurezza e conformità, e operazioni finanziarie. Se il lavoro arriva sotto forma di richieste a cui rispondere o da gestire lasciando un record, può essere gestito su Threada come WorkItem governati.

I sistemi in cui risiedono il lavoro e le azioni — strumenti di assistenza e ticketing come Zendesk, issue tracker come Jira, chat come Slack, oltre a email e intake tramite API o webhook. Le richieste entrano e le azioni approvate escono come azioni governate. Consulta la pagina delle integrazioni per l'elenco aggiornato.

No. Un chatbot risponde a un messaggio e lo dimentica. Threada gestisce il lavoro: ogni richiesta diventa un WorkItem tracciato con evidenze citate, controlli di policy, approvazioni umane, azioni governate e una pista di audit — così il lavoro è governato e verificabile dall'inizio alla fine, non solo una risposta.

Un WorkItem è l'unità centrale di lavoro in Threada: un oggetto tipizzato e gestito nel lifecycle che cattura intake, decisioning, esecuzione e risultato per ogni richiesta.

Gli strumenti tradizionali di automazione solo messaggi gestiscono richieste un messaggio alla volta. Threada gestisce il lavoro: intake, policy, approvazioni, azioni e misurazione dei risultati, con audit trail e controlli di governance.

Sì. La maggior parte dei team inizia con un singolo workflow scoped a un canale o workspace e si espande in modo incrementale man mano che cresce la fiducia.

Siti web, documenti caricati, connettori API e fonti basate su feed. Ognuna viene registrata come asset di conoscenza gestito con propria policy di freshness e conservazione.

Imposti cadenza sync e soglie stale per fonte. Threada avvisa su drift di freshness e sync falliti affinché le evidenze restino aggiornate.

Sì. I requisiti di citazione possono essere applicati per workflow e intent. Le risposte con poche evidenze vengono instradate automaticamente a revisione o escalation.

Sì. Passaggi decisionali e requisiti di approvazione sono guidati dalla configurazione.

Sì. Gli overlay policy specifici per canale possono sovrascrivere il comportamento baseline del workflow.

Sì. I kill switch possono disabilitare l'esecuzione per canale, workflow o scope integrazione.

Sì. Le dimensioni di telemetria includono sia identificatori di canale sia di workflow per analisi cross-sectional.

Sì. La telemetria di esecuzione include dimensioni di integrazione e azione con stati di successo, retry e fallimento.

Sì. La versione policy è disponibile come dimensione di report first-class per analisi di qualità e risultati.

Threada redige le risposte ai questionari di sicurezza a partire dalle tue evidenze citate e le instrada per la revisione. Le risposte a basso rischio e ben fondate possono essere approvate automaticamente in base ai criteri; quelle sensibili attendono un responsabile della sicurezza designato. Non invii mai una risposta non revisionata, a meno che i tuoi criteri non lo consentano esplicitamente.

Threada attinge le risposte dalle fonti che approvi (questionari precedenti, policy di sicurezza, report SOC 2 e DPA) recuperate e citate per ogni risposta. Se l'evidenza non supporta una risposta, il WorkItem la segnala a una persona invece di tirare a indovinare.

Threada registra ogni risposta redatta, modifica e approvazione come evento con marca temporale e con l'evidenza citata, così un audit successivo, un rinnovo o un controllo modificato possono essere ricostruiti: chi ha risposto a cosa, su quale base e chi ha approvato.

Threada ancora le risposte finance con il recupero dalle tue fonti, cita la pagina o il record specifico e utilizza l'etichettatura della provenienza per le affermazioni ad alto impatto; quando il contesto è insufficiente e la modalità di astensione è attiva, restituisce una risposta di fallback che indica l'assenza di risposta invece di tirare a indovinare.

I passaggi decisionali di Threada modellano la revisione umana, l'approvazione del manager, l'approvazione della sicurezza, i gate automatizzati e le code delle eccezioni, mentre gli overlay di policy impostano i requisiti di approvazione con una precedenza deterministica.

Sì: le azioni governate di Threada vengono eseguite con idempotency keys e nuovi tentativi, sono reversibili e producono registri di esecuzione verificabili, insieme a un envelope di telemetria unificato ed esportazioni in CSV/NDJSON.

Threada acquisisce input tipizzati da web, in-app, Slack, Teams, email, API ed endpoint personalizzati; i canali provider in ingresso includono webhook di Gmail, Twilio SMS, WhatsApp, social, Discord e Teams, tutti normalizzati in WorkItems.

Con la modalità di astensione attiva, Threada utilizza una soglia di pertinenza e restituisce un fallback esplicito che indica l'assenza di risposta invece di inventarne una, e ogni risposta che produce include citazioni.

Threada può subordinare le azioni di supporto, come l'aggiornamento di un ticket o la notifica a un cliente, a passaggi decisionali; le approvazioni vengono registrate, le azioni sono reversibili grazie alle idempotency keys e l'esecuzione viene registrata come cronologia verificabile.

Un evento runtime misurato, come intake, bozza, approvazione, azione o operazione su un WorkItem, conteggiato dal registro di utilizzo della piattaforma.

Una pagina elaborata da contenuti caricati o sincronizzati che conta nella quota di pagine documento usata per l'indicizzazione e le evidenze.

Sì. In qualsiasi momento. Le modifiche hanno effetto dal ciclo di fatturazione successivo.

Riceverai avvisi quando ti avvicini al limite; superandolo, l'uso viene limitato (dove disponibili si applicano crediti per il superamento). In caso di mancato pagamento si applica un periodo di grazia separato di 7 giorni.

Risparmia il 20% con la fatturazione annuale.

No. Vengono indicizzati solo per il retrieval.

Operiamo secondo obiettivi di disponibilità interni con auto-scaling, backup automatizzati e playbook di ripristino testati. Gli obiettivi contrattuali di uptime e gli eventuali rimedi sotto forma di service credit vengono concordati per ciascun order form.

No. Threada applica la policy nell'automazione del lavoro AI: si integra con i tuoi strumenti GRC e identità esistenti invece di sostituirli.

Gli overlay policy sono versionati e scoped per tenant, canale, pack e workflow. Ogni esecuzione registra la versione policy attiva.

Sì. Eventi di lifecycle, policy e azioni sono esportabili per audit esterni, integrazione SIEM e report normativi.

Disponibilità mensile 99,9% con obiettivi RTO (4h) e RPO (24h) espliciti e runbook incidenti documentati.

Abbonamenti Stripe + contatori d'uso; automazione di avviso nel periodo di grazia e disabilitazione controllata al termine del periodo di grazia.

Sì. Feed di export (GCS e BigQuery) e download on demand sono disponibili per revisioni di conformità.

No. Threada è progettato per orchestrare intorno ai sistemi esistenti tramite integrazioni e azioni governate.

Sì. I requisiti di approvazione possono essere applicati per workflow, canale, classe di rischio e tipo di azione.

Usa i gate EvalSuite per estrazione, routing, grounding e comportamento delle azioni prima di un rollout ampio.

Sì. Il web può essere il primo canale, mantenendo le stesse primitive di workflow per i canali futuri.

Sì. L'esecuzione delle integrazioni è asincrona e supporta i retry con classi di errore tracciabili.

Usando correlation ID, cronologia del WorkItem, eventi decisionali e log di esecuzione è possibile ricostruire il flusso end to end.