Skip to content

5 min de lectura

Armamos nuestro soporte con la herramienta que ya teníamos.

En Brault el soporte vivía en una herramienta de terceros. Hoy vive en nuestra plataforma, con IA que sugiere y personas que responden. Cómo funciona.

Un desarrollador pasa a mano una tarjeta a la última columna de un tablero de soporte, y recién ahí sale el mail.

En nuestro soporte, ningún mail le llega a un cliente sin que una persona cambie el estado de una página. La IA propone un borrador, alguien escribe la respuesta, y recién cuando esa persona la pasa a "Ready to send", sale el mail.

Hasta hace poco llevábamos los pedidos de soporte en una herramienta de terceros. Hoy viven en un board de Brault, conectado al mail. Brault es la plataforma que construimos: la hicimos para guardar y ordenar archivos creativos, y la adaptamos para llevar un kanban de tickets de soporte. Así que esto no es el caso de un cliente: es nuestro propio soporte. Para el cliente siguen siendo mails. Para nosotros, todo pasa en un solo lugar.

Por qué lo hicimos

No fue para apagar un incendio. Recibimos pocos pedidos por semana, casi todos sugerencias para mejorar flujos de trabajo, y los contestamos entre dos o tres personas. Responde el primero que lo ve, y siempre fue en menos de 24 horas. Eso no cambió.

Lo hicimos por dos razones. La primera: estamos construyendo una plataforma que reúna el trabajo de un equipo, y no tenía sentido que nuestro propio soporte viviera en otra herramienta. La segunda: probar la API pública de Brault con un caso real antes de recomendársela a nadie.

Cómo funciona

  1. Un cliente manda un pedido desde el formulario de soporte de la aplicación, y se crea una página en estado "New" con el detalle. En Brault una página es un archivo propio, un documento donde se escribe y se comenta, así que el ticket entero vive ahí adentro.
  2. La página trae una respuesta sugerida por IA. Es un borrador, no la respuesta.
  3. Quien lo toma escribe la respuesta como comentario, en la sección de feedback de la página.
  4. Cuando está lista, pasa la página a "Ready to send". Una automatización hecha en n8n manda el mail al cliente y deja la página en "Answered".
  5. Si el cliente responde en ese mismo hilo, su mail vuelve a la página, la IA sugiere una respuesta nueva y la página vuelve a "New". El ciclo se repite las veces que haga falta, y todo el ida y vuelta queda en esa misma página.

Diagrama: el pedido entra por el formulario de soporte y crea una página en estado New, con un borrador de IA. Alguien responde en un comentario y la pasa a Ready to send; n8n manda el mail al cliente y la deja en Answered. Si el cliente responde en el hilo, la página vuelve a New y el ciclo se repite.

Al final quedan dos hilos que cuentan lo mismo: uno de mails, del lado del cliente, y uno de comentarios en la página, del nuestro.

Lo que resuelve

Nadie contesta a ciegas. Si dos personas agarran el mismo pedido, cada una ve qué respondió la otra y qué dijo el cliente, sin reenviar mails ni preguntar por chat.

El historial está junto al pedido. No hay que buscar en una casilla qué se habló: está en la página, con su estado.

Una herramienta menos. Lo que antes estaba afuera ahora está donde ya trabajamos.

Nada de esto es espectacular, y ese es justamente el punto: un circuito chico, bien resuelto, con lo que ya había.

Por qué la IA sugiere y no contesta

La respuesta sugerida sirve para no arrancar de cero. Pero ningún mail sale solo: sale cuando una persona escribe el comentario y cambia el estado de la página. Ese cambio de estado es la firma.

Es la misma regla que escribí sobre la inteligencia artificial en una pyme: sirve para borradores, en tareas donde alguien revisa. Una respuesta a un cliente es exactamente eso.

Qué lo hace posible

Brault tiene una API pública (abre en una pestaña nueva): una forma documentada de que otras herramientas lean y modifiquen lo que hay adentro. Además tiene webhooks firmados, que son avisos que Brault le manda a otra herramienta cuando algo cambia, por ejemplo cuando una página pasa a otro estado.

Con eso se conecta cualquier herramienta de automatización que sepa llamar a una API. n8n ya tiene un nodo propio para Brault, y es el que usamos. Zapier y Make están en camino.

De guardar archivos a llevar un proceso

Este es el caso de uso que más nos interesa mostrar. Brault se hizo para guardar, ordenar y compartir archivos creativos. Con boards, páginas y la API, la misma herramienta terminó llevando un kanban de tickets de soporte, que no es lo que teníamos en la cabeza cuando la diseñamos.

Y no es lo único que entra ahí. Un circuito de aprobaciones, una agenda de producción o el seguimiento de una campaña son la misma idea: un board con estados, y una automatización que avisa cuando algo cambia de estado.

Lo que te sirve aunque no uses Brault

Antes de pagar otra herramienta para ordenar algo, hacete tres preguntas.

¿Lo que ya pagás se puede conectar? Muchas herramientas tienen una API o se conectan con n8n, Zapier o Make. Si la que usás todos los días lo permite, quizás no hace falta sumar otra. Es la misma lógica de comprar lo estándar y construir solo lo propio.

¿El circuito está claro? El nuestro se pudo automatizar porque es simple: entra un pedido, alguien responde, sale un mail. Si en el tuyo nadie sabe quién contesta ni cuándo, automatizarlo no lo ordena: lo acelera.

¿Dónde mira una persona? Si la automatización le habla a un cliente, tiene que haber un paso en el que alguien revise antes de que salga.

Si tenés un circuito repartido entre mails, planillas y chats, y querés ver si se puede resolver con lo que ya usás, lo charlamos sin costo.

Posts relacionados