Automatización posterior a la compra para Shopify: flujo de trabajo para configurar con Shopify Flow y tu servicio de asistencia
Shopify Flow puede automatizar los pasos del servicio poscompra del lado de Shopify, mientras que tu mesa de ayuda sigue siendo el sistema para las conversaciones con los clientes, la gestión de tickets y el seguimiento por parte de los agentes. La configuración más fiable consiste en usar Flow para detectar un evento de pedido, comprobar un pequeño número de condiciones y, a continuación, actualizar el pedido o enviar información estructurada a una integración de mesa de ayuda. No consideres Flow por sí solo como un sistema completo de supervisión de envíos: los retrasos del transportista, las excepciones de entrega y los eventos de devolución pueden requerir una plataforma de seguimiento o devoluciones que proporcione esas señales.
Esta guía muestra cómo diseñar el flujo de trabajo, elegir el activador adecuado, conectar el resultado con tu mesa de ayuda y probar la automatización sin crear tickets duplicados ni mensajes engañosos para los clientes.
Qué debe hacer el flujo de trabajo
Un flujo de trabajo poscompra útil tiene cuatro partes:
- Evento: Ocurre algo en un pedido, como un pago, un proceso de preparación, una cancelación o un reembolso.
- Decisión: Flow comprueba si el evento requiere una acción. Las condiciones pueden incluir el valor del pedido, el país de envío, el estado de preparación, las etiquetas o si el cliente ya se ha puesto en contacto con el servicio de asistencia.
- Acción: Flow añade una etiqueta, actualiza un pedido, envía un correo electrónico o una notificación, o envía datos a un endpoint externo.
- Responsable: Una persona o una cola de la mesa de ayuda recibe el caso cuando se requiere criterio o comunicación con el cliente.
El objetivo no es automatizar todas las interacciones con los clientes. Consiste en eliminar el trabajo repetitivo de clasificación y mantener un traspaso claro para las excepciones.
Antes de crear el flujo: define la fuente de verdad
Empieza por decidir qué sistema conoce cada dato. Shopify suele ser la fuente de información sobre pedidos, pagos, preparación, reembolsos y clientes. Un transportista o una plataforma de seguimiento puede ser la fuente de información sobre los escaneos durante el tránsito, las excepciones de entrega y la confirmación de entrega. La mesa de ayuda debe ser la fuente del historial de conversaciones, el estado de los tickets, la asignación y las notas de los agentes.
Esta distinción evita un error de diseño común: crear un flujo de trabajo que suponga que Shopify Flow puede identificar todos los problemas de entrega. Flow puede reaccionar a eventos de Shopify y a la información disponible mediante aplicaciones conectadas o servicios externos, pero no puede inferir un retraso del transportista simplemente porque un pedido se haya preparado. Un evento de preparación confirma que un registro o estado de preparación ha cambiado; por sí solo, no demuestra que el paquete se esté desplazando con normalidad.
Anota el evento que realmente necesitas antes de seleccionar un activador. Por ejemplo:
- «El pedido se ha preparado y el cliente debe recibir el mensaje poscompra estándar».
- «Un envío tiene una excepción del transportista y el servicio de asistencia debe recibir un caso prioritario».
- «Se ha creado un reembolso y el cliente debe dirigirse a la cola de reembolsos si ya existe una conversación».
Arquitectura recomendada con Shopify Flow y una mesa de ayuda
Hay dos patrones de conexión prácticos.
Patrón 1: Usa una integración nativa con la mesa de ayuda
Si tu mesa de ayuda tiene una integración con Shopify, instálala y configúrala primero. Las integraciones nativas suelen permitir que los detalles del pedido estén disponibles dentro de un ticket o que los agentes abran el pedido correspondiente sin copiar los datos manualmente. Los eventos y las acciones exactos dependen de la mesa de ayuda, así que confírmalos en su documentación actual en lugar de suponer que todos los eventos de Shopify son compatibles.
En este patrón, Flow puede encargarse de la clasificación del lado de Shopify. Por ejemplo, puede añadir una etiqueta como post_purchase_priority cuando un pedido cumpla tus criterios de asistencia. La mesa de ayuda puede utilizar después esa etiqueta, los datos del pedido o un evento proporcionado por una aplicación para dirigir la conversación.
Patrón 2: Envía una solicitud HTTP desde Flow
Cuando ninguna acción nativa cubra el traspaso, Shopify Flow puede enviar una solicitud HTTP a un servicio de middleware, una plataforma de automatización o un endpoint de la mesa de ayuda cuando dicha opción sea compatible. El sistema receptor debe validar la solicitud, transformar la carga útil si es necesario y crear o actualizar un ticket.
Usa este patrón únicamente cuando puedas controlar la autenticación, la detección de duplicados, el manejo de errores y los datos enviados al servicio externo. Una solicitud que simplemente cree un ticket nuevo cada vez que se ejecute Flow puede producir rápidamente casos duplicados.
Flujo de trabajo 1: Traspaso de preparación al servicio de atención al cliente
Este es un buen flujo de partida porque la preparación es un evento claro de Shopify y el resultado operativo es fácil de medir.
Paso 1: Elige el activador
En Shopify Flow, crea un flujo de trabajo utilizando el activador relacionado con la preparación que corresponda a tu proceso. El nombre exacto del activador y las variables disponibles pueden cambiar a medida que Shopify actualiza Flow, así que selecciona la opción actual que aparece en tu panel de administración e inspecciona las variables disponibles en el editor del flujo.
Paso 2: Añade condiciones empresariales
No envíes todos los pedidos preparados a un agente. Añade condiciones que identifiquen una excepción o un segmento operativo útil. Algunos ejemplos son:
- El pedido tiene una prioridad interna de asistencia alta.
- El destino de envío pertenece a un mercado con una cola de servicio independiente.
- El pedido contiene un producto que requiere instrucciones poscompra especiales.
- El pedido tiene una etiqueta que indica una reclamación previa del cliente o una revisión manual.
- La preparación es parcial y el cliente puede necesitar una explicación.
Mantén la primera versión limitada. Una regla como «todos los pedidos internacionales se envían al servicio de asistencia» puede generar más trabajo del que elimina, a menos que exista una razón operativa específica.
Paso 3: Elige la acción
Para una clasificación de bajo riesgo, añade una etiqueta al pedido o una nota interna. Para un caso que necesite un responsable, envía una notificación a la mesa de ayuda o crea un ticket mediante la integración. Incluye únicamente la información que el equipo receptor necesita:
- ID y número de pedido de Shopify
- Nombre del cliente e identificador de contacto
- País o región de envío
- Estado de preparación y referencia de seguimiento, cuando estén disponibles
- Motivo del enrutamiento
- Cola y prioridad sugeridas
Si la API de la mesa de ayuda requiere un formato JSON específico, utiliza su documentación como contrato. No adivines los nombres de los campos. En Flow, inserta las variables mediante el selector de variables siempre que sea posible y compara después la carga útil de prueba con los campos requeridos por el sistema receptor.
Paso 4: Evita los tickets duplicados
Utiliza una estrategia de idempotencia. Antes de crear un caso nuevo, comprueba si el pedido ya tiene una etiqueta de asistencia, una referencia a un ticket abierto o un campo personalizado que indique que el traspaso se ha completado. Si tu mesa de ayuda admite una clave de idempotencia, utiliza un valor estable basado en el pedido y el evento, no en una marca de tiempo. Si no la admite, haz que el middleware busque un caso abierto existente antes de crear otro.
Flujo de trabajo 2: Escalado de excepciones de entrega
Las excepciones de entrega requieren más cuidado porque el evento puede originarse fuera de Shopify. Shopify Flow debe ser únicamente la capa de acción si la aplicación de seguimiento o la integración transmite un evento fiable a Shopify o al endpoint utilizado por Flow.
Un diseño sólido es el siguiente:
- Un transportista o servicio de seguimiento informa de una excepción.
- El servicio de seguimiento o middleware comprueba si el envío sigue abierto y si ya se ha procesado una excepción similar.
- El sistema envía un evento estructurado a la mesa de ayuda o a un endpoint compatible con Flow.
- La mesa de ayuda crea o actualiza un ticket, asigna la cola adecuada y muestra al agente el contexto del seguimiento.
- Un agente decide si debe contactar con el cliente, esperar otro escaneo, solicitar la confirmación de la dirección u ofrecer una solución aprobada.
Utiliza una lista controlada de categorías de excepción, como problema con la dirección, retraso en aduanas, intento de entrega fallido, envío dañado o ausencia de un escaneo reciente. Evita prometer automáticamente una fecha de entrega a menos que el servicio subyacente proporcione una estimación actual y tu política de atención al cliente permita ese mensaje.
Si utilizas Flow para etiquetar el pedido relacionado, elige etiquetas que describan el estado y no el resultado. carrier_exception_open es más seguro que delivery_failed cuando el transportista no ha confirmado un fallo definitivo.
Flujo de trabajo 3: Devoluciones, reembolsos y preguntas poscompra
Las devoluciones y los reembolsos suelen generar preguntas repetitivas, pero no deben agruparse en una sola automatización. Un reembolso puede haberse completado mientras el cliente sigue esperando a que el proveedor de pagos abone los fondos. Una devolución puede haberse solicitado, pero aún no haberse recibido. Cada estado debe tener una respuesta diferente de la mesa de ayuda o una instrucción interna distinta.
Utiliza Shopify Flow para clasificar eventos como una solicitud de devolución, la creación de un reembolso, una cancelación o una actualización del pedido cuando esos eventos estén disponibles en la configuración de Flow de tu tienda. Dirige el resultado según tu política:
- Informativo: Añade una etiqueta interna y deja que la macro existente de la mesa de ayuda responda a las preguntas habituales.
- Urgente: Crea o prioriza un ticket cuando una ventana de servicio prometida esté en riesgo.
- Revisión manual: Dirige los productos dañados, los reembolsos impugnados o los historiales de pedido inusuales a un especialista.
- Se requiere una acción del cliente: Solicita únicamente la información que falta, como fotografías o una dirección corregida.
Si las devoluciones se gestionan mediante una aplicación especializada, mantén el estado de la devolución en ese sistema y transmite el estado necesario a Shopify o a la mesa de ayuda. No mantengas estados manuales en conflicto en tres sistemas, a menos que exista un proceso de conciliación claro.
Cómo configurar el traspaso a la mesa de ayuda
Antes de activar una acción externa, prepara el lado de la mesa de ayuda.
Define las colas y los responsables
Crea colas que correspondan a decisiones reales, no solo a etiquetas generales. «Excepción de entrega», «corrección de dirección» y «revisión de reembolso» suelen llevar a procedimientos diferentes. Asigna una cola de reserva para eventos incompletos o no reconocidos, de modo que los fallos de automatización no desaparezcan.
Crea un esquema de eventos compacto
Utiliza nombres y valores de campo coherentes. Un evento práctico puede incluir event_type, event_id, shopify_order_id, order_number, customer_reference, tracking_number, reason_code, priority y occurred_at. Envía un ID de evento estable y regístralo en el lado receptor.
Minimiza los datos personales. Es posible que la mesa de ayuda ya pueda recuperar el perfil del cliente a partir del número de pedido, así que no envíes más información del cliente de la que requiera la integración.
Establece la regla de contacto con el cliente
Decide qué eventos crean un ticket interno, cuáles envían un mensaje al cliente y cuáles hacen ambas cosas. Una excepción del transportista suele requerir una revisión interna antes de enviar un correo electrónico automatizado. Una confirmación estándar de preparación puede ser adecuada para una plantilla aprobada. La regla debe quedar documentada en el flujo de trabajo para que los agentes sepan por qué se envió un mensaje.
Lista de comprobación de pruebas y supervisión
Realiza las pruebas por etapas en lugar de activar todas las acciones a la vez.
- Prueba el activador: Confirma que el evento seleccionado se ejecuta para los tipos de pedido esperados y no para cambios no relacionados.
- Prueba las condiciones: Utiliza ejemplos positivos y negativos, incluida la preparación parcial, los destinos internacionales, los reembolsos y los pedidos con etiquetas existentes.
- Inspecciona la carga útil: Verifica los identificadores del pedido, los datos de seguimiento, las fechas, la prioridad y el código de motivo. Comprueba que los campos vacíos no interrumpan la API receptora.
- Prueba el comportamiento ante duplicados: Ejecuta el mismo evento más de una vez y confirma que no cree varios tickets activos.
- Prueba la gestión de fallos: Utiliza temporalmente un endpoint no válido o un campo obligatorio incorrecto en un entorno controlado. Confirma que el fallo sea visible para un responsable.
- Realiza un lanzamiento limitado: Empieza con una cola, un mercado o un tipo de evento. Revisa los tickets y los comentarios de los agentes antes de ampliar el alcance.
Supervisa tanto los resultados operativos como los de los clientes. Entre las métricas útiles se incluyen el número de traspasos automatizados, los tickets duplicados, los tickets sin asignar, las solicitudes fallidas, el tiempo hasta la primera revisión humana y el porcentaje de casos dirigidos que los agentes vuelven a clasificar. Una automatización que crea más tickets, pero no mejora la asignación ni la resolución, no funciona bien, aunque el historial de ejecuciones de Flow muestre éxito.
Errores comunes que debes evitar
- Usar la preparación como prueba de entrega: La preparación y la entrega son estados diferentes.
- Crear un ticket para cada pedido: Utiliza condiciones y umbrales de enrutamiento para reservar a los agentes para las excepciones.
- Enviar identificadores inestables: Los números de pedido, los ID de evento y las referencias de seguimiento deben asignarse de forma coherente.
- Omitir la autenticación: Trata un endpoint HTTP que recibe datos de clientes o pedidos como un servicio protegido.
- Ignorar los límites de la aplicación y del plan: Confirma qué acciones de Flow, activadores, llamadas a la API y funciones de la mesa de ayuda están disponibles en tu configuración actual.
- Automatizar decisiones de política: Deja que Flow clasifique los casos rutinarios, pero mantén los reembolsos, las compensaciones, los cambios de dirección y los posibles fraudes dentro de las reglas aprobadas y de la revisión humana.
Secuencia práctica de implementación
Para la mayoría de las tiendas Shopify, la secuencia más segura es comenzar con una etiqueta o notificación interna, añadir después el enrutamiento a la mesa de ayuda y, solo más adelante, introducir la automatización orientada al cliente. Empieza con un evento fácil de verificar, como una excepción de preparación o un estado de reembolso conocido. Documenta el activador, las condiciones, la acción, el responsable, la regla de duplicados y el procedimiento en caso de fallo. Cuando el flujo de trabajo haya producido resultados estables, añade más tipos de eventos de uno en uno.
El mejor diseño no es el que tiene más acciones de Flow. Es el que proporciona a los agentes de asistencia el contexto adecuado en el momento adecuado, deja un registro auditable y evita que el cliente repita información que ya está disponible en Shopify o en el sistema de seguimiento correspondiente.
Preguntas frecuentes
¿Puede Shopify Flow crear directamente un ticket en la mesa de ayuda?
Depende de la mesa de ayuda y de la integración disponible en tu tienda. Si no hay una acción nativa de Flow disponible, una solicitud HTTP puede transmitir los datos del evento a un servicio de middleware o a un endpoint de la mesa de ayuda cuando sea compatible. Confirma los requisitos de autenticación, carga útil y creación de tickets del sistema receptor antes de activar el flujo de trabajo.
¿Puede Flow detectar que un paquete llega tarde?
No solo a partir del estado de preparación. Un envío tardío o retrasado requiere una regla de tiempo de entrega y una fuente fiable de eventos del transportista o de seguimiento. Utiliza una integración o un servicio de seguimiento que proporcione esas señales y, después, dirige el evento a la mesa de ayuda o al flujo de trabajo de Shopify correspondiente.
¿Debe cada evento poscompra crear un ticket?
No. Utiliza etiquetas, notificaciones internas o automatizaciones existentes de la mesa de ayuda para los eventos de bajo riesgo. Crea un ticket cuando una persona deba investigar, contactar con el cliente, aprobar una solución o supervisar una excepción.
¿Cómo evito los tickets duplicados?
Utiliza un ID de evento estable o una clave basada en el pedido y el evento, comprueba si ya existe un ticket abierto y registra el resultado del traspaso. Una etiqueta como support_handoff_complete puede ayudar en flujos sencillos, pero una consulta en la mesa de ayuda o el middleware es más segura cuando los eventos pueden volver a intentarse.
¿Qué debe probarse antes del lanzamiento?
Prueba el activador, las condiciones, la asignación de datos, los permisos, el comportamiento ante duplicados, las alertas de fallo y el texto dirigido al cliente. Incluye la preparación parcial, los datos de seguimiento ausentes, los eventos repetidos, los reembolsos y los pedidos que ya tengan un caso de asistencia.
