LLM · Real-Time · Hospitality
QuickComm
5 P@SHA ICT Awards, 2026My roleAs Co-Founder & CTO of QuickComm, I architected it and wrote the core voice pipeline, from radio ingestion to routing, then led its migration to microservices.
Walk any hotel back-of-house and you hear it: "Housekeeping, 412 needs towels." "Engineering, pool pump again." Every request exists for exactly as long as the audio hangs in the air. No record, no routing, no accountability.

System architecture
- Hotel radiosPCM audio
- Audio ingestionFastAPI · WebSockets
- Speech-to-textAIWhisper · Deepgram94%+ accuracy
- Intent classifierAIGemini LLM~88% precision
- Team routerRedis · microservices
- Health monitoringanomaly detection · AWS70% faster incident response
- Command centeranalytics · SLA
- Staff appsinstant task push~45% faster response
Architecture decisions I made
- D1Streaming first, every stage on a latency budgetPCM audio streams per channel into the cloud, streaming speech-to-text, a fast classifier and push delivery over WebSockets. Batch anywhere in the chain would have broken the 3-second feel.
- D2Two speech engines, not one vendorGetting to 94%+ on noisy radio came from audio preprocessing and Whisper plus Deepgram redundancy, not from picking a single provider.
- D3Constrain the LLM with a contractGemini classifies each utterance against a fixed intent taxonomy into a strict JSON schema validated at the boundary, with a mandatory confidence field. Below the threshold, the event routes to a human dispatcher.
- D4Monolith first, then Strangler Fig to microservicesV1 shipped as a monolith to learn the real load. Audio (CPU-bound), LLM inference (GPU-bound) and the dashboard API scale completely differently, so I extracted them one at a time: REST API, then the LLM pipeline (Redis Streams as the interface), then audio last.
Measured in production

















