Schedy

Il problema

Studi medici e centri estetici italiani gestiscono la prima linea su WhatsApp, ma la segretaria non scala: no-show del 30–40%, chiamate in attesa che non vengono billate, calendario diviso tra Google Calendar, quaderno e messaggi. Ogni prenotazione passa almeno per tre mani.

L’approccio

• FSM derivata dalla memoria, non dallo schema. Lo stato conversazionale è ricostruito dalla memoria cifrata del tenant via keyword matching, senza tabelle dedicate. Zero migration quando si aggiunge un tenant nuovo.
• Routing LLM empirico. gpt-5.4-mini come primary (4× più economico di Sonnet 4.6, qualità equivalente sui volumi reali), Sonnet 4.6 come fallback. Il classifier V2 a monte è stato disabilitato dopo un 50% di error rate sull’italiano.
• Anti-echo a tre livelli per l’handoff umano. Message-ID + hash del contenuto + finestra temporale 1.5s. Senza, il bot risponde sopra l’operatore umano quando prende in mano la conversazione.
• Voice con keyterm prompting. Deepgram Nova-3 nel bridge WhatsApp, staff/servizi/clienti iniettati come keyterm. Latenza STT < 500ms.
• Prompt a 4 layer, versionato. Core immutabile + verticale (medico/estetico/veterinario) + tenant dinamico + learned dalla KB. Eval solo su paid model — il free tier è inaffidabile.

I numeri

• 4 tenant in produzione
• 100–250 messaggi/giorno sul tenant più attivo
• ~700 MB RAM per tenant full stack
• $0.00054 costo per call (Haiku cache warm, −92% vs baseline gpt-4o)
• <500ms latenza STT Deepgram
• 2–3s sync GCal bidirezionale (push), fallback cron 5 min

Cosa potresti volerne

Se gestisci uno studio dentistico, una clinica veterinaria, un centro estetico o un poliambulatorio e la prima linea è un collo di bottiglia — l’architettura di Schedy si adatta. I verticali cambiano il layer 2 del prompt e i servizi del tenant, il resto è il medesimo runtime.