Nota de producto: Playbooks de Starter en Arcanum Engine
Qué se incluyó en la última versión de Engine, cómo se relacionan los playbooks con los flujos de trabajo de los comercios y qué estamos observando a continuación.
Cuando lanzamos por primera vez el plan Starter de Arcanum Engine, incluía tres playbooks por correo electrónico.
Eran útiles. Un comercio podía supervisar el inventario, recibir un resumen semanal de ingresos y detectar checkouts abandonados que podían necesitar atención.
Pero la experiencia era más limitada de lo que queríamos.
Era suficiente para mostrar lo que Engine podía hacer, pero no siempre para ayudar a un equipo pequeño a construir un verdadero ritmo operativo alrededor de la herramienta. Los comercios podían ver el potencial, pero a menudo llegaban al límite del plan antes de tener la oportunidad de integrarlo en su trabajo diario.
La última versión cambia eso.
Starter ahora incluye catorce variantes de playbooks por correo electrónico para recuperación de ingresos, operaciones, retención, experiencia del cliente y merchandising. El plan sigue permitiendo tres playbooks activos al mismo tiempo, y las alertas continúan enviándose mediante la propia cuenta de Resend del comercio.
La diferencia es que ahora esos tres espacios pueden utilizarse de formas mucho más útiles.
Una persona fundadora podría elegir un resumen semanal de ingresos, una alerta de inventario bajo y una advertencia de cumplimiento de pedidos. Un equipo pequeño de experiencia del cliente podría centrarse en checkouts abandonados, clientes inactivos y pedidos de alto valor. Un responsable de merchandising podría supervisar inventario de baja rotación, productos huérfanos y la preparación de nuevos productos.
Starter sigue siendo deliberadamente enfocado. Simplemente ya no se siente como una vista previa del producto real.
Lectura de Hollow: Los playbooks de Starter utilizan la misma lógica de activación principal que sus equivalentes de Growth. Las diferencias principales son dónde se entrega la alerta y cuántas automatizaciones pueden ejecutarse al mismo tiempo.
Qué cambió
Los playbooks originales de Starter siguen disponibles:
Inventory Guardian: Alerta al equipo cuando el inventario supervisado cae por debajo de un umbral definido.
Revenue Watch: Envía un resumen semanal de pedidos, ingresos, tendencias y productos más vendidos.
Winback Engine: Detecta checkouts inactivos para que el equipo pueda decidir si debe hacer un seguimiento.
Ahora también hemos añadido versiones por correo electrónico de varios flujos de trabajo que antes dependían de los canales de equipo disponibles en Growth.
Esto incluye:
- Fulfillment SLA
- Back-in-Stock
- Refund Alert
- Daily Ops Digest
- High-Risk Order
- Dormant Customer Winback
- Review Accelerator
- VIP Recovery
- Slow Mover Digest
- New Product Launch Checklist
- Orphan Product Alert
No son versiones simplificadas creadas únicamente para ampliar el catálogo de Starter.
En la mayoría de los casos, utilizan la misma lógica de activación que las versiones de Growth. Inventory Guardian supervisa las mismas condiciones de inventario, tanto si la alerta se entrega por correo electrónico como si se publica en Slack. High-Risk Order sigue detectando niveles elevados de riesgo de fraude, aunque el etiquetado automático de pedidos en Shopify continúa formando parte del flujo de trabajo de Growth.
Tomamos esa decisión de forma deliberada.
Un comercio más pequeño puede no necesitar Slack, Microsoft Teams, Klaviyo o diez automatizaciones ejecutándose al mismo tiempo. Eso no significa que deba recibir una versión más débil de la señal subyacente.
El correo electrónico es la capa de entrega, no el recorrido del cliente
Las alertas de Starter se envían al equipo del comercio. No se envían directamente a los compradores.
Antes de que un playbook pueda activarse, el comercio debe conectar una cuenta de Resend desde:
Settings → Email alerts
La configuración incluye una clave API de Resend, una dirección de remitente verificada y las bandejas de entrada del equipo que deben recibir las alertas. También hay una prueba de conexión, porque descubrir que una clave API es incorrecta después de la primera alerta importante no debería formar parte de la experiencia de incorporación.
El flujo de instalación ahora muestra una vista previa del correo electrónico durante el paso de revisión. Los comercios pueden ver cómo será la alerta y quién la recibirá antes de activar el playbook.
También hicimos más visible el uso de espacios en Command Center.
Starter permite tres playbooks activos. La interfaz ahora muestra ese uso con claridad y avisa al comercio cuando está a punto de ocupar el último espacio. La misma comprobación se aplica cuando se reactiva un playbook pausado.
No hay nada especialmente emocionante en la lógica de límites de un plan, pero es importante. Un comercio debe entender la implicación mientras elige un flujo de trabajo, no después de que el sistema se niegue a ejecutarlo.
Queríamos que Starter mostrara su trabajo
Uno de los errores más fáciles de cometer en un software de automatización es confundir actividad con valor.
Llega un correo electrónico, así que la automatización debe estar funcionando. Aparece una ejecución en un registro, así que el sistema debe estar ayudando. Un panel muestra varios indicadores verdes, así que algo importante debe estar ocurriendo.
No siempre es así.
Los comercios de Starter ahora reciben la misma estructura básica de Command Center que los de Growth:
- Una lista guiada de lanzamiento
- Una puntuación operativa de comercio
- Indicadores de cobertura del sistema
- Un registro de Results para cada ejecución de un playbook
La lista de lanzamiento guía al comercio por los primeros pasos importantes: conectar la entrega de alertas, configurar el perfil de comercio, instalar un playbook, confirmar una ejecución correcta y añadir Revenue Watch.
La puntuación operativa evalúa cinco áreas:
- Crecimiento
- Operaciones
- Retención
- Experiencia
- Automatización
Cuando Engine detecta una carencia, dirige al comercio hacia un playbook relevante, en lugar de limitarse a mostrar una puntuación más baja y dejar que el equipo descubra por su cuenta qué debe hacer.
Results registra cada ejecución, su estado y cualquier impacto direccional útil. Según el playbook, esto puede incluir el valor de checkout detectado, un pedido marcado, una condición de inventario bajo o un producto que necesita atención de merchandising.
La idea es sencilla: recibir una alerta es útil, pero saber por qué se activó y qué ocurrió después es aún mejor.
El merchandising por fin tiene una ruta práctica dentro de Starter
Tres de los nuevos playbooks de Starter se centran en la higiene del catálogo y de los productos.
Slow Mover Digest
Es una vista semanal de los productos que todavía tienen inventario, pero que no han generado ventas recientes.
No decide qué debe hacer el comercio con ellos. Le da al equipo un punto de partida más claro.
Algunos productos necesitan una mejor ubicación. Otros necesitan formar parte de un paquete. Algunos necesitan una historia diferente. Y probablemente otros necesiten una reducción de precio. La alerta está diseñada para plantear la pregunta antes de que el inventario permanezca inmóvil durante otro trimestre.
New Product Launch Checklist
Cuando se crea un producto, Engine envía un recordatorio para comprobar los detalles que suelen pasarse por alto durante un lanzamiento apresurado.
Esto incluye la ubicación en colecciones, la preparación de merchandising y la visibilidad en la tienda.
Un producto puede estar completamente configurado en Shopify y seguir siendo difícil de encontrar, estar mal agrupado o lanzarse sin los elementos de apoyo que el equipo pensaba añadir más adelante.
“Más adelante” tiene la costumbre de convertirse en permanente.
Orphan Product Alert
Este resumen semanal identifica productos activos que no están asignados a ninguna colección.
Pueden existir en el catálogo, aparecer mediante enlaces directos y estar técnicamente disponibles para la venta. Pero, desde el punto de vista del comprador, pueden ser prácticamente invisibles.
Los comercios de Growth pueden instalar estos flujos de trabajo juntos como parte del sistema más amplio de Merchandising Ops. Los comercios de Starter los instalan de uno en uno y deciden si cada uno merece ocupar uno de los tres espacios disponibles.
Tres espacios todavía pueden cubrir mucho
El límite de espacios obliga a tomar una decisión, lo cual no es necesariamente algo negativo.
La mayoría de los equipos pequeños no necesita todas las automatizaciones posibles ejecutándose desde el primer día. Necesitan las pocas que eliminen la mayor cantidad de incertidumbre durante la semana.
Una configuración centrada en operaciones podría utilizar:
- Inventory Guardian
- Fulfillment SLA
- Daily Ops Digest
Esto ofrece al equipo un resumen por la mañana y dos alertas de excepción para problemas que no deberían esperar hasta que alguien los encuentre por casualidad en Shopify Admin.
Una configuración centrada en recuperación podría utilizar:
- Winback Engine
- VIP Recovery
- Dormant Customer Winback
Esto cubre checkouts abandonados, momentos importantes con clientes valiosos y clientes que han dejado de comprar.
Una tienda dirigida directamente por su fundador podría elegir:
- Revenue Watch
- Inventory Guardian
- Slow Mover Digest
Esto crea un ritmo semanal básico alrededor de los ingresos, la presión del inventario y los productos que no se están moviendo.
No existe una configuración de Starter que sea correcta para todos. Los tres playbooks adecuados dependen de lo que el equipo esté dejando pasar, retrasando o descubriendo demasiado tarde.
Cuándo Growth empieza a tener sentido
Starter tiene actualmente un precio de 29 dólares al mes después de una prueba de siete días. Growth cuesta 79 dólares al mes.
La diferencia no consiste únicamente en un catálogo más amplio.
Growth incluye:
- Diez espacios para playbooks activos
- Entrega mediante Slack, Discord y Microsoft Teams
- Conexiones con Klaviyo, Recharge y Gorgias
- Seguimiento de la tienda
- Sistemas de comercio y paquetes por sector
- La biblioteca más amplia de playbooks de Engine
Algunos flujos de trabajo siguen siendo exclusivos de Growth porque dependen de datos que Starter no recopila.
El abandono de navegación y el abandono del carrito requieren seguimiento de la tienda mediante el theme app embed o el puente de API para arquitecturas headless. Replenishment Reminder depende de datos de suscripciones o de recompra.
No son barreras de actualización arbitrarias. La infraestructura necesaria es realmente diferente.
Para la mayoría de los comercios, el momento de actualizar debería resultar bastante evidente. El equipo quiere recibir alertas en Slack. Tres playbooks activos ya no son suficientes. Un flujo necesita Klaviyo o Recharge. El comportamiento en la tienda debe pasar a formar parte del panorama operativo.
Hasta entonces, Starter debe ser capaz de realizar trabajo útil por sí solo.
Cómo poner en marcha el primer playbook
El proceso de configuración es deliberadamente breve:
- Instalar Arcanum Engine y elegir Starter.
- Conectar Resend desde Email alerts.
- Configurar el perfil de comercio y el objetivo principal.
- Instalar el primer playbook.
- Activar un evento de prueba.
- Confirmar una ejecución correcta en Results.
Inventory Guardian puede probarse reduciendo el inventario supervisado por debajo del umbral configurado.
Winback Engine tarda un poco más porque el checkout debe permanecer inactivo durante el tiempo seleccionado, más un máximo de cinco minutos adicionales. La pestaña del checkout debe cerrarse después de introducir el correo electrónico. Engine no considerará abandonado un checkout mientras el comprador continúe editándolo activamente.
La última comprobación en Results es la parte importante.
Instalar una automatización es configuración.
Ver cómo completa una ejecución real es el momento en el que empieza a convertirse en parte de la tienda.
Sentinel y Engine están empezando a trabajar de forma más estrecha
Cuando Hollow Sentinel y Arcanum Engine están instalados en la misma tienda, Engine puede mostrar dentro de Command Center oportunidades detectadas por Sentinel.
El comercio puede pasar desde la detección hasta la ruta de instalación del playbook correspondiente.
Todavía estamos ajustando cómo se priorizan esas recomendaciones. Un comercio de Starter debería ver el flujo por correo electrónico disponible cuando exista, en lugar de recibir automáticamente una recomendación de una versión de Growth.
La medición útil aquí no es cuántas recomendaciones puede mostrar Engine.
Es la rapidez con la que un comercio puede pasar de detectar un problema real a tener una respuesta correcta ejecutándose en la tienda.
Lo que estamos observando
Hay varias áreas a las que estamos prestando especial atención a medida que esta versión empieza a utilizarse en tiendas reales.
Queremos ver si las alertas semanales de merchandising son suficientes para cambiar el comportamiento o si los comercios necesitan más contexto antes de actuar sobre el inventario de baja rotación.
También estamos observando si los equipos prefieren que Engine se encargue de la detección operativa mientras Klaviyo sigue siendo responsable de los mensajes dirigidos a clientes. Esa separación nos parece razonable, pero los flujos de trabajo reales de los comercios importan más que el diagrama.
También estamos midiendo el traspaso entre Sentinel y Engine, especialmente el tiempo que transcurre entre la detección, la instalación del playbook y la primera ejecución correcta.
Las señales de la tienda siguen siendo otra área activa. La actividad de navegación y del carrito puede ser valiosa, pero solo cuando las alertas son lo suficientemente precisas como para merecer la atención del equipo.
Estas son preguntas de producto en las que estamos trabajando activamente, no promesas asociadas a fechas de lanzamiento.
En resumen
Starter solía ser una introducción limitada a Arcanum Engine.
Ahora es una capa operativa creíble para un pequeño equipo de Shopify.
Catorce variantes de playbooks ofrecen a los comercios suficientes opciones para cubrir las áreas del negocio que necesitan atención en este momento. El límite de tres espacios mantiene la configuración enfocada. Resend simplifica la entrega. Command Center y Results permiten comprobar con mayor facilidad si los flujos de trabajo realmente están haciendo algo.
Algunas tiendas superarán rápidamente las capacidades de Starter. Otras podrán operar cómodamente durante mucho tiempo con tres playbooks bien elegidos.
Ambos resultados son válidos.
El plan debería quedarse pequeño porque las operaciones del comercio han crecido, no porque los flujos de trabajo útiles se hayan reservado desde el principio.