>Delivery, un enfoque informático

>Yo personalmente uso mucho el delivery de comidas de cierto conocido local comercial que no vale la pena mencionar. El problema con esto es que después de convertirte en un cliente frecuente que llama siempre a pedir lo mismo o que si cambia sus gustos sabe bien que pedir, que te atienda la operadora con ese infernal ruido, te pregunte tu número de teléfono (what, again?!) y te haga repetir mil veces lo que pediste se vuelve algo tedioso y con consecuencias nerviosas difíciles de ocultar.

Que tal si te atiende un operador inteligente que te liste los menús mas comunes y te pase con la operadora ruidosa solo cuando lo que escuchaste no esta ahí (poco probable) ?. Bueno, a mi me encanta la idea.

¿Cómo solucionamos esto?

La verdad que es un poco complicado pero básicamente necesitamos lo siguiente:

  1. Una entrada de línea telefónica a través de un media gateway que nos haga de pasarela entre la red celular (GSM) y/o fija (PSTN).
  2. Un PBX, pero no cualquier PBX, tiene que ser un IPPBX porque queremos poder programarlo y no gastar ni un guaraní en adquirirlo e instalarlo. Para esto tenemos varias opciones pero mi favorita es Asterisk .
  3. Las voces del IVR . Son las grabaciones que se reproducirán cuando alguien llame e interactúe con la central.Enlace
  4. Nuestro cerebro e Internet para programar el dialplan que básicamente, es lo más dificil en todo esto.

Necesitamos saber quién es el cliente que llama, para esto tenemos su caller-id. Con ese dato podemos ir a tratar de identificarlo en una base de datos (MySQL en mi caso) buscando su nombre y dirección particular. Si no lo encontramos, lo derivamos directamente con la operadora para que le tome sus datos y lo dé de alta en el sistema, cosa que se hace siempre cuando llamas por primera vez.

Si el cliente ya está registrado, le reproducimos el menú estadísticamente más pedido o todo el menú si quieren (no es buena idea). Por ejemplo:

  • Llamo y me atiende una IVR deciéndome: “Bienvenido al bar X” y me reproduce el menú.
  • “Presione 1 para pizzas, 2 para lomitos, 3 para bebidas, 0 (cero) para hablar con un operador”.
  • Me gustaría comer pizza y presiono 1 reproduciéndome…
  • “Presione 1 para napolitana, 2 para cuatro quesos, 3 para muzarela, 4 para peperoni.”
  • Me gusta la de 4 quesos y presiono 2 y me reproduce…
  • “Seleccione la cantidad que desea”
  • Bueno, estoy con algunas personas y quiero tres, entonces aprieto 3…
  • “Usted ha pedido 3 pizzas de cuatro quesos, el precio total es, 90 mil guaraníes, presione 1 para confirmar, 2 para cambiar el pedido, 3 para salir”
  • Quiero confirmar, presiono 1…
  • “Su pedido ha sido procesado con éxito, adiós”, y termina la transacción. Opcionalmente, recibís un SMS que te confirma que tu pedido fue atendido y otro mensaje cuando se encuentra en tránsito, es decir, cuando el delivery guy se está yendo a tu casa en su moto.

Cuando llega un nuevo pedido se levanta un ticket o alerta que la cajera o algún encargado puede ver en su pantalla y éste se procesa como cualquier otro pedido hecho físicamente en la caja.

¿Cuánto tiempo tardé en pedir?

Escuchar toda la grabación me tomó 30 segundos o menos, tiempo decente pero, cuando me sepa de memoria el menú, al llamar puedo presionar 123 (1 + 2 + 3) de seguido y lo siguiente que escucharé será: “Usted ha pedido 3 pizzas de cuatro quesos, el precio total es, 90 mil guaraníes, presione 1 para confirmar, 2 para cambiar el pedido, 3 para salir”, entonces, presiono 1 y listo. Cuánto tardé?, menos de 10 segundos.

Como había dicho, lo más difícil de programar fue el dialplan. Tenía 4 opciones para esto, usar el seudolenguaje de programación de extensiones (no!!!), AEL (tampoco, pero lo usé solo para algunas operaciones de muy bajo nivel), AGI (mucho mejor, pero no) y FastAGI, el ganador.

Por qué fastAGI? porque utiliza sockets sobre IP lo que me permite manejar la carga en una suerte de computación distribuida, mucho mas escalable y encima elegante.

Hay demasiadas cosas por explicar sobre cómo funciona Asterisk y fastAGI. tal vez en otra ocasión me siente a hacer un ensayo, pero por ahora les dejo un snippet esencial para el manejo de pedidos, hecho en C#, para que se den una idea.

4 thoughts on “>Delivery, un enfoque informático

  1. >MMm…Interesante idea pero para los q hacemos pedidos de empanadas seria medio complicado.

    A quiere 1 jamon y queso, 2 de palmitos y una de roquefort.
    B quiere 2 de huevo, 1 de roquefort y una de carne
    C quiere 1 de pollo, 1 de carne, 1 de choclo y 1 de roquefort.
    Todos queremos papas grandes y una coca grande

    Tenemos:
    2 palmitos
    1 jamon y queso
    2 huevo
    2 roquefort
    2 carne
    1 pollo
    1 choclo
    3 papas grandes
    1 coca

    La serie de botones seria un poco mas compleja para un pedido tipico en casa.

    Pero ya es cuestion de interface, me sigue gustando 😀

  2. >jajaja. En ese caso, entras al menu de empanadas y haces todos tus pedidos, despues confirmas y elegis la opcion de hacer otro pedido, cosa que olvide agregarle al post pero que esta disponible.

    Aca se puede ver:

    http://1.bp.blogspot.com/_qQ2i8b8SKWI/TE4lnuHi8wI/AAAAAAAAABI/65KAryI_Ysg/s1600/delivery-part-2

    Linea:
    confimation = Ask("123", "pizza/1_confirmar_2_ordenar_3_salir");

    Es demasiado largo pedir asi por lo que es mejor usar la version para el celular, que también hice y voy a estar posteando proximamente 😀

  3. >Ciertamente para pedidos muy largos derepente va a ser hincha, pero imaginate si el lugar tiene una web (hablamos de donvito, pancholos, macdonalds, o por que no algun lomitero consciente de que tiene que tener presencia en la web) entonces entrás, y te suscribís para cliente, y podés hacer tu "pedido frecuente" por ejemplo, que lo configuraste vos por una interfaz más amigable, la idea es ofrecer una alternativa para agilizar lo que quieras pedir.

  4. >Claro, esas son variantes de la misma idea y son perfectamente realizables. Solo falta que alguien quiera adoptar la idea y hacerla realidad en un ambiente real.

Leave a Reply

Your email address will not be published. Required fields are marked *