Caso · Taxitel · Email → Servicio
Del correo al servicio, en segundos
Las solicitudes llegaban por correo y alguien tenía que leerlas y digitarlas una por una. Construimos la integración que las registra sola, la desplegamos en su clúster y la mantenemos en operación. Esto es cómo está hecha, y cómo se comprueba que ninguna se pierde.
La arquitectura
El recorrido de un correo
Cinco etapas y una derivación, tal como quedó desplegado. Fíjate en el carril de abajo: no es un paso más al final, es lo que observa a todos los demás.
Desliza para ver el mapa completo
Qué pasa en cada etapa
- 01
El requerimiento
Los clientes de Taxitel piden sus servicios por correo. Cada solicitud necesitaba que una persona abriera el mensaje, lo interpretara y lo digitara en la plataforma.
- 02
Lectura y validación
El agente lee el correo, identifica los datos de la solicitud y los valida antes de escribir nada. Si un dato no cuadra, no completa por su cuenta: deriva.
- 03
Creación por API
El servicio no se inserta contra la base de datos: se crea llamando a la API de la plataforma. Pasa por las mismas reglas de negocio que un alta hecha a mano, así que no hay un camino de segunda para los registros automáticos.
- 04
Clúster y tenant
La integración quedó desplegada en el clúster de Kubernetes y ahí corre. Cada cliente de Taxitel es un tenant: su configuración y sus datos viven aislados de los del resto.
- 05
Confirmación al cliente
El cliente recibe un correo confirmando que su solicitud quedó recibida y registrada. Antes no tenía forma de saber si alguien había abierto su mensaje.
- 06
Traza de punta a punta
Cada paso emite trazas con OpenTelemetry, los registros van a Loki y todo se consulta en Grafana. Una solicitud concreta se sigue entera, desde el correo que entró hasta el servicio que quedó creado. Es lo que usamos nosotros para darle soporte.
Aislamiento
Cada cliente es un tenant
Los clientes de Taxitel no comparten espacio. Cada uno tiene su configuración y sus datos separados dentro de la misma plataforma, y la integración escribe siempre dentro del tenant que corresponde.
Es la diferencia entre una automatización y un script: un script lee un buzón y escribe donde le digan. Esto respeta el modelo de datos de la plataforma, así que un cliente nuevo no obliga a tocar el código.
La regla de oro
Ante la duda, revisión humana
El agente no adivina. Toda solicitud termina en uno de estos tres estados, y los tres quedan registrados: ninguna se pierde por el camino.
Procesado
Los datos estaban completos y validados. El servicio quedó creado y confirmado.
Pendiente de revisión
Algo no estaba claro. En vez de adivinar, la solicitud espera a una persona.
Reintentando
Un servicio no respondió a tiempo. Se reintenta, y queda registrado que se reintentó.
El ahorro no se promete: se mide
Antes de implementar nada medimos una semana de la operación real: cuántos correos entran, cuánto toma hoy cada solicitud, cuántas llegan fuera de horario y cuántas se quedan esperando.
Por eso en esta página no hay un porcentaje de ahorro. Las cifras que sostienen la decisión son las del cliente, no las nuestras, y publicaremos las de este caso cuando estén medidas, con el método al lado. Un proveedor que llega con el número ya puesto lo sacó de otro sitio.
¿Tienes un proceso que hoy hace una persona a mano?
Cuéntanos cuál es. Te decimos si se puede automatizar y qué habría que medir primero, antes de hablar de presupuesto.
Cuéntanos tu caso