Caso publicado por Make el 20 de mayo de 2020, basado en una entrevista con Ludwig Wurlitzer, cofundador y director de producto de Chronext. Las valoraciones comparativas corresponden a su experiencia de entonces, no al estado actual de los productos citados.
De pequeñas tareas a procesos de atención
Chronext operaba una plataforma de compraventa de relojes de lujo. A medida que crecía, incorporaba más software en la nube y necesitaba conectar los procesos de atención al cliente.
Wurlitzer relató que empezaron con automatizaciones sencillas, como tareas relacionadas con Google Sheets. Más adelante, Zendesk pasó a ocupar un lugar central en el soporte y la empresa quiso integrar una parte mayor de sus flujos de trabajo.
El objetivo era reducir tareas repetitivas y responder con más agilidad, sin emplear constantemente a los desarrolladores en conexiones entre herramientas.
La lógica de negocio necesitaba más flexibilidad
Según el entrevistado, la solución que utilizaban entonces no cubría bien sus necesidades de lógica condicional y procesamiento por lotes. El equipo de desarrollo podía construir las integraciones, pero tenía otras prioridades.
Chronext ya había creado automatizaciones de Zendesk con sus propios desarrolladores. Wurlitzer las consideraba útiles, aunque costosas en tiempo. El problema no era la capacidad técnica, sino dónde invertir ese recurso escaso.
Esta observación no permite afirmar que Zapier o las integraciones de Zendesk carezcan hoy de esas funciones: el artículo recoge una decisión tomada en el contexto de 2020.
Make como parte del trabajo con Zendesk
La empresa explicó que trasladó a Make buena parte de las integraciones que rodeaban a sus procesos de atención. A medida que aprendía a usarlo, descubría más oportunidades de automatizar la lógica de negocio.
Wurlitzer distinguía dos esfuerzos: decidir qué debía ocurrir y construir el código que conectaba los sistemas para hacerlo posible. Su valoración era que Make reducía parte de este segundo esfuerzo y permitía concentrarse más en la solución.
El caso no publica la configuración exacta de sus tickets ni una secuencia de módulos que pueda reproducirse sin más. Por eso no se añaden aquí desencadenadores, reglas de enrutamiento o plazos de respuesta que el original no documenta.
Qué resultados describe realmente la entrevista
Chronext destacó una mayor rapidez para construir integraciones y más margen para automatizar sus procesos de soporte. El artículo no ofrece una medición controlada de ahorro ni un porcentaje verificable de mejora en el servicio.
La comparación de Wurlitzer entre caminar e ir en bicicleta era una metáfora de su experiencia, no una prueba de rendimiento. El aprendizaje es que reducir trabajo de conexión puede dejar más tiempo para diseñar las reglas del negocio.
Una lectura práctica
Orientación editorial: antes de automatizar atención al cliente, escribe qué situaciones pueden resolverse con reglas y cuáles deben llegar a una persona. Después identifica los datos que necesita cada decisión. Este caso sirve para plantear esa conversación entre soporte y desarrollo, pero no sustituye la documentación actual de Zendesk ni las pruebas de los cambios en una cuenta concreta.
Fuente: caso original de Make.