Automatización · 6 min de lectura
Leads que llegan y quedan sin seguimiento
Una prueba con el formulario de DS: conservar consultas, distinguir pendientes y revisar el seguimiento. Los resultados de seis casos sintéticos y el límite que quedó abierto.
En preparaciónArtículo en revisión editorial.
Una consulta puede entrar por la web, generar una notificación y recibir un acuse automático. Para quien escribió, el proceso empezó. Para el negocio quedan decisiones concretas: quién la toma, cuándo responde y qué pasa si la conversación se queda abierta.
Cuando todo llega al mismo buzón, una consulta pendiente compite con lo que parece más urgente. Volver a encontrarla, recuperar el contexto y decidir qué responder también requiere tiempo. El seguimiento necesita conservar esa próxima acción entre una revisión y la siguiente.
Tomar un flujo que ya existe
Usé el formulario de DS para ensayar ese recorrido. El sitio ya valida una consulta, envía una notificación y prepara un acuse. Le añadí al ensayo un registro posterior con responsable, estado y próxima acción.
La prueba se ejecutó localmente con seis consultas sintéticas. Recorrieron el formulario y su lógica de envío; el proveedor de correo, las respuestas de las personas y el paso del tiempo se simularon. Así pude revisar el circuito sin atribuirle actividad comercial que todavía no hemos observado.
Dónde empieza el registro en este ensayo
- 01Consulta en el formulario DS
- 02Validación y solicitud de notificación
Respuesta del proveedor simulado
Acepta
Registrar la consultaResponsable, estado y próxima acción
Preparar la tarea pendienteRespuesta o cierre: actualizar el registro
Rechaza
Sin registro posteriorEl formulario indica indisponibilidad; no se genera una próxima acción.
Darle continuidad a una consulta
En el ensayo, yo era la persona responsable. Una consulta nueva quedaba pendiente de respuesta del negocio. Si el negocio respondía, el estado cambiaba a espera del contacto y la próxima acción pasaba a seguimiento. Una nueva respuesta del contacto volvía a poner trabajo de nuestro lado.
Preparar una tarea no marcaba la consulta como atendida. Ese cambio requería un evento posterior. También probé el cierre: una consulta cerrada dejaba de aparecer entre los pendientes.
Estas diferencias importan al decidir sobre qué trabajar. Un correo que espera una respuesta nuestra y otro que espera al cliente pueden estar juntos en el buzón y necesitar acciones distintas.
Estado y próxima acción
- Pendiente del negocio
- Responder la consulta
- Esperando al contacto
- Revisar el seguimiento
- Cerrada
- Fuera de pendientes
Seis consultas, ocho envíos del formulario
Uno de los casos simulaba una respuesta perdida después de que el proveedor hubiera aceptado la notificación. El formulario mostraba que el envío no se había completado. Al repetirlo con el mismo identificador, el registro conservó una sola consulta y su plazo original. Una repetición adicional mantuvo ese resultado.
En otro caso preparé una tarea de seguimiento y después introduje una respuesta del contacto. La tarea anterior quedó retirada y la siguiente acción pasó a ser responder. Volver a procesar esa misma respuesta no pospuso el plazo ni añadió otra tarea.
Cinco consultas de ensayo quedaron registradas. Una se cerró. Al reabrir el registro y avanzar el reloj de prueba, aparecieron cuatro tareas pendientes. Una segunda pasada del planificador conservó esas cuatro.
Resultados del ensayo local
Proveedor de correo, respuestas de las personas y paso del tiempo simulados. El formulario y la persistencia se ejercitaron localmente. No se enviaron correos reales.
- Consultas sintéticas
- 6
- Envíos del formulario
- 8
- Consultas registradas
- 5
- Tareas pendientes al final
- 4
| Caso | Resultado observado |
|---|---|
| Consulta nueva | Conserva responsable, próxima acción y plazo. |
| Respuesta perdida tras aceptar | Dos repeticiones mantienen una sola consulta y el plazo original. |
| Conversación con respuestas | La respuesta del contacto retira el seguimiento anterior y deja pendiente responder. |
| Consulta cerrada | Sale de la selección de pendientes. |
| Rechazo antes de aceptar | El formulario indica indisponibilidad; el registro posterior no recibe la consulta. |
| Mensaje con instrucciones | Se conserva como datos; no cambia otras consultas ni responsables. |
El punto en que el registro no recibía nada
La sexta consulta mostraba un límite de dónde había colocado el registro. Al simular que el proveedor rechazaba la notificación antes de aceptarla, el formulario indicaba indisponibilidad. El registro posterior no recibía esa consulta, así que tampoco podía asignarle una próxima acción.
Para cubrir ese fallo, la consulta tendría que guardarse al entrar en la aplicación. La notificación sería un paso posterior con su propio reintento. El ensayo dejó visible esa decisión de integración y el trabajo que requiere.
Es un resultado útil para diseñar el circuito: una automatización que empieza leyendo notificaciones depende de que esas notificaciones lleguen a existir.
Qué desarrollar después de esta prueba
Este primer ensayo se centró en conservar el estado y la próxima acción. La recepción real de correo y la generación de respuestas con AI quedan para una siguiente prueba.
La AI puede ayudar a recuperar contexto, resumir una consulta y proponer una respuesta. El registro debe permitir revisar de dónde sale esa propuesta y qué ocurrió después. Con ese circuito en funcionamiento podremos medir consultas atendidas, tiempos de respuesta y siguientes pasos completados.
Trabajar sobre el seguimiento de tu negocio
Si tu negocio recibe consultas que se quedan pendientes, puedo ayudarte a conectar la entrada, el registro y el seguimiento. Podemos partir de tu web, tu correo y las herramientas que ya usas, elegir un flujo concreto y probar qué cambia al darle continuidad.
Conversemos sobre tu seguimiento.