Relier l’assistance vocale IA à la répartition des taxis en temps réel | Cas technique GoGoCha

Contexte du problème

Les personnes âgées, voyageurs et entreprises peuvent demander un taxi par téléphone, sur le site ou via LINE. Si chaque canal stocke séparément les demandes, les opérateurs doivent rapprocher les informations entre interfaces. Ce projet relie les canaux à un backend commun de répartition des courses pour que chauffeurs, passagers et opérateurs vérifient le même état, tout en préservant l’intervention humaine lorsque les informations manquent.

Méthode de mise en œuvre

• —Le canal téléphonique IA recueille les informations de course ; le backend commun stocke les demandes et gère leur affectation. Séparer la conversation de l’état des demandes permet de relier téléphone, site et LINE au même processus opérationnel.
• —Utiliser Express, PostgreSQL, Redis, BullMQ et Socket.IO pour créer un backend de demande en temps réel.
• —Le calculateur de prix sur le site web doit d'abord appeler l'API de prix réel, puis fournir un résultat alternatif clair en fonction des règles locales en cas d'échec.
• —Concevoir l'interface pour les personnes âgées avec des caractères de grande taille, une priorité pour la voix et un contraste élevé.

Portée réelle de Falcon

• Site web de la marque et interface de calcul des prix
• Point d'entrée de la prise en charge vocale et structure de données de la demande
• Backend de demande en temps réel SmartDispatcherV2
• Intégration du bot LINE, de l'application pour chauffeurs/passagers et de la console d'administration

Flux de données de la réponse téléphonique IA à l’affectation des taxis

1. 01Les utilisateurs peuvent soumettre une demande de transport par téléphone, sur le site web ou via LINE.
2. 02Le système organise les informations sur les lieux, les contacts et les tâches, et les envoie au processus de demande partagé.
3. 03Le backend utilise PostgreSQL pour stocker l'état, BullMQ pour gérer les files d'attente, et Redis/Socket.IO pour une synchronisation en temps réel.
4. 04Chauffeur, passager et interface d'administration ont accès à l'état de la même demande.

Limitations, échecs et alternatives

• —Si l’IA ne peut pas confirmer de manière fiable un lieu, un contact ou les détails d’une demande, une personne doit les vérifier. Les suppositions du modèle ne doivent pas devenir des données d’affectation exécutables. Cette page ne prétend pas que tous les appels peuvent être traités sans intervention humaine.
• —Si l’API tarifaire du site échoue, des règles locales fournissent une estimation de remplacement dont l’interface doit préciser la base et les limites. Ce résultat ne signifie ni que l’API en temps réel a fonctionné, ni qu’une course a été réservée, ni qu’un devis officiel a été émis.
• —Traiter les files d'attente et la communication en temps réel de manière hiérarchisée, afin d'éviter que la perte de connexion n'entraîne la disparition de la demande.

Comment vérifier les preuves

• ✓Vérifier les points d'entrée tels que le site web de la marque, le téléphone, le site web et LINE.
• ✓Les écrans de l'application et du site web sont utilisés pour prouver la portée des produits provenant de différents points d'entrée, sans inclure les données des passagers ou des chauffeurs privés.
• ✓L'architecture technique est définie par la portée réelle de Falcon. Elle ne comprend pas les volumes d'activité, les taux de réussite, les économies de temps ou les accords de niveau de service (SLA) non divulgués.

Mesures et capacités disponibles