Vinsyt / Comunicaciones
The Lifecycle Engine
Recordatorios de vehículo diseñados alrededor de lo que se sabe, lo que se estima y cuándo no enviar.
Rol
Modelado de línea de tiempo y eventos, enrutamiento, UX writing, captura de kilometraje y diseño para el personal.
Una línea de tiempo por propietario
Organizar alrededor del auto, no en campañas separadas
Un servicio completado, un hito que se acerca, un recall abierto y una solicitud de kilometraje se refieren al mismo vehículo. Diseñarlos por separado puede esconder cómo se acumulan para el propietario.
Organicé los mensajes como entradas de una sola línea de tiempo. La distinción está entre una actualización sobre lo que pasó, un recordatorio de lo que toca y una solicitud para que el propietario haga algo.
Los tres tipos de entrada
Hay tres tipos de entrada y solo tres, y cada uno lleva una promesa distinta.
La confianza dentro del copy
Hacer de la confianza parte del copy
Un recordatorio basado en una lectura de kilometraje antigua no debería sonar como una observación actual. Los tres ejemplos muestran cómo cambia la redacción según la información disponible.
Cuando una lectura es antigua, el mensaje identifica la estimación y le da al propietario una forma de corregirla. Cuando no hay lectura, el copy no introduce una cifra de kilometraje como si se conociera.
El mismo recordatorio, tres lecturas
El mensaje cambia según la evidencia detrás del kilometraje, no solo según la fecha del calendario.
El dato que falta
Hacer fácil entregar el número que falta
Los ejemplos de captura de kilometraje exploran la misma tarea en tres lugares: lecturas sugeridas en una notificación de la app, una respuesta numérica por SMS y una ruta por cámara dentro de la app.
Mantuve la solicitud enfocada en la lectura. No necesita convertirse al mismo tiempo en una propuesta de agendamiento ni en una promoción.
Una solicitud, tres lugares
Cada canal hace la misma pregunta y da una forma distinta de responderla con un solo toque.
Cuándo no enviar
Diseñar las condiciones que detienen un mensaje
Especifiqué verificaciones al momento del envío para que una cita reciente pueda detener un mensaje programado antes. También definí límites de frecuencia a lo largo de la relación con el propietario y una forma de combinar el trabajo que toca en la misma semana.
La comparación hace visible la consecuencia: el propietario recibe la suma de los mensajes de la plataforma, no una experiencia separada por cada campaña o vehículo.
Un año con y sin límites compartidos
Los límites de frecuencia, los recordatorios combinados y las verificaciones de cancelación pertenecen a la línea de tiempo compartida.
Los dos lados del envío
Darle al asesor el mismo historial
El par personal/cliente muestra los dos lados de un envío. El asesor necesita saber qué recibió el cliente, y el registro necesita distinguir un mensaje retenido de uno fallido.
Especifiqué que la entrada del personal se escriba antes del envío y que los mensajes retenidos lleven un motivo. Así una decisión deliberada de no contactar a alguien queda visible para quienes usan el sistema.
El registro del personal y la bandeja del cliente
La vista del personal registra el mensaje y explica por qué otro fue retenido.
La especificación de eventos
Escribir la tabla de eventos como la especificación
Cada evento necesita una fuente, un disparador, una condición y un canal. La fuente determina qué se puede afirmar; el disparador determina cuándo se vuelve relevante; la condición decide si todavía hace falta; el canal lleva el mensaje.
Usé la misma tabla de eventos para definir el diseño y para apoyar a ingeniería y QA. Así las limitaciones de los feeds pueden cambiar la promesa del mensaje, en lugar de quedar escondidas detrás de ella.
Fuente, disparador, condición, canal
Un solo modelo de eventos conecta la decisión de diseño con la implementación y con las pruebas. Hoy hay 95 eventos activos en producción.
La ruta de entrega
Tener en cuenta la ruta de entrega
La arquitectura conecta la creación de plantillas, el HTML almacenado, la configuración de eventos, los proveedores de envío y la retroalimentación de entrega. Son restricciones de diseño porque el copy contiene bloques condicionales y valores que se llenan al momento del envío.
Mi trabajo de diseño tuvo que contemplar esa ruta: qué valores recibe una plantilla, qué bloques renderiza y qué puede mostrar el registro del personal después de un envío.
La ruta de entrega
La ruta compartida desde la creación de plantillas hasta la retroalimentación de entrega.
Tres reglas que impuso el stack
Lo que el stack impuso sobre cómo se escribe una entrada.
Hacer inspeccionables las reglas
Hacer inspeccionables las reglas
El reporte de ejemplo compara los envíos esperados con los envíos reales por regla nombrada. Muestra cómo se podría revisar el sistema en busca de fallas silenciosas, incluidos mensajes que debieron retenerse.
Este es el formato de validación propuesto, mostrado con valores ilustrativos y no con una corrida completa en staging.
Esperado contra real
Un reporte de validación de ejemplo, con valores ilustrativos y no con una corrida completa en staging.
Alcance y evidencia
Mensajería en producción. Un formato de validación ilustrativo
El caso de estudio muestra el modelo de mensajería y sus diseños de interfaz. El reporte de validación es un formato de ejemplo, no un resultado completo de staging.
- 17,067 recordatorios enviados entre enero y septiembre de 2026
- Email, SMS y notificaciones de la app. El email se abrió entre el 36 y el 67 por ciento de las veces, según la entrada. 385 avisos iniciales de kilometraje salieron por email en los primeros ocho meses de 2026, y el 52 por ciento fueron abiertos.
- Una condición, evaluada al momento del envío
- Un registro para el personal de qué salió y qué se retuvo