Aprende a crear un flujo de recepción de referencias que registre el consentimiento, los datos de cualificación, la actividad de seguimiento y los resultados de cada referencia.
Una referencia suele empezar con buenas intenciones y después perderse entre las tareas diarias. Una persona envía una presentación por correo electrónico, otra menciona un nombre durante una llamada y alguien más guarda los datos en una nota privada. Cada método parece rápido, pero juntos hacen que las referencias sean difíciles de encontrar, asignar y medir.
Las cadenas de correo se pierden con facilidad. Un miembro del equipo puede responder al referente, pero olvidarse de registrar al posible cliente. Otra persona puede suponer que el contacto ya está en marcha. Cuando un empleado cambia de puesto o se ausenta, el contexto puede quedarse en una bandeja de entrada que nadie revisa.
Las notas privadas generan otro problema. Suelen contener información útil, como el motivo de la presentación o lo que necesita la persona referida. Sin embargo, el resto del equipo no puede verla. La referencia termina dependiendo de la memoria de una sola persona en lugar de seguir un proceso compartido.
La falta de información crea brechas costosas. Sin un consentimiento registrado, el equipo puede contactar con alguien que no esperaba recibir mensajes. Sin un responsable asignado, varias personas pueden ponerse en contacto con la misma persona, o puede no hacerlo nadie. Sin una fecha de seguimiento, un posible cliente interesado puede esperar demasiado y perder el interés.
El coste va más allá de una oportunidad perdida. Los referentes notan cuando sus presentaciones no reciben respuesta o cuando tienen que pedir noticias. Es posible que estén menos dispuestos a recomendar a alguien de nuevo. El equipo también pierde visibilidad sobre qué referencias de redes profesionales generan conversaciones reales, posibles clientes cualificados y trabajos completados.
Un flujo de recepción de referencias proporciona a cada presentación un registro compartido y un recorrido claro dentro del equipo. Debe recoger quién hizo la referencia, si la persona aceptó ser contactada, qué ayuda necesita, quién responderá y cuál fue el resultado final.
En cualquier momento, el equipo debería poder responder a estas preguntas:
Cuando las respuestas están en un mismo lugar, el seguimiento de referencias pasa a formar parte del trabajo habitual, en vez de ser una tarea que alguien recuerda solo cuando el referente pide una actualización.
Define las funciones antes de crear un formulario o añadir etiquetas de estado. Las referencias suelen desaparecer porque varias personas suponen que otra se encargará de responder, comprobar el consentimiento o actualizar al referente.
Haz una lista de todas las personas implicadas. Un contacto profesional puede enviar una referencia. La persona referida puede tener que confirmar que quiere recibir el contacto. Después, alguien del equipo de ventas, selección, soporte o alianzas decide si la referencia encaja y da el siguiente paso.
Mantén separadas estas funciones, aunque una misma persona desempeñe varias en una empresa pequeña:
El responsable interno también necesita un sustituto. Si la persona habitual no está disponible, una presentación prometedora no debería esperar hasta su regreso. Asigna las referencias por área, cuenta, ubicación o mediante un sistema rotativo, y haz visible la asignación.
Decide dónde ocurre cada transferencia. Un socio puede enviar una referencia mediante un formulario. El flujo la asigna a un gestor de cuentas. El gestor comprueba el consentimiento, registra el primer intento de contacto y cualifica la oportunidad o la cierra indicando el motivo. Si otro equipo se hace cargo, el nuevo responsable acepta la transferencia dentro del mismo registro.
Los datos de contacto necesitan un acceso más restringido que la actividad general. Normalmente, los referentes solo necesitan confirmación de que el equipo recibió su presentación, no las notas privadas, las conversaciones sobre contratos ni cada cambio de estado. La persona referida debe recibir únicamente mensajes que correspondan al consentimiento que dio.
Para muchas referencias de redes profesionales basta con un modelo sencillo de permisos. Los referentes pueden enviar presentaciones y ver confirmaciones básicas de recepción o resultados. Los responsables internos pueden consultar los datos de contacto, las notas de cualificación y las tareas de seguimiento. Los líderes del equipo pueden revisar asignaciones, cargas de trabajo e informes de resultados. Los equipos especializados solo deberían tener acceso cuando su trabajo lo requiera.
Decide qué pueden ver los referentes cuando se cierra una referencia. Algunos equipos comparten resultados generales, como «contacto realizado» o «no encaja», para proteger la privacidad. Otros ofrecen actualizaciones más completas cuando la persona referida lo acepta. Elige la regla antes de recibir la primera referencia y aplícala siempre de la misma manera.
AppMaster puede representar estas funciones en una aplicación de referencias con pantallas separadas para referentes, equipos internos y gerentes. Su editor visual Business Process puede dirigir un registro nuevo al responsable adecuado y limitar a cada usuario la información que necesita.
Un formulario de referencias debe dar a la persona que recibe la referencia suficiente contexto para actuar, sin convertir al referente en alguien que tenga que introducir muchos datos. Mantén breve el primer envío. Recopila información más detallada después de la primera conversación, cuando sea necesario.
Empieza por la fuente. Registra el nombre del referente, su empresa o relación profesional, el medio de contacto preferido y cómo conoce a la persona referida. Una presentación directa de un antiguo cliente requiere una respuesta distinta a la de un nombre mencionado después de una conversación en una conferencia. Los datos de la fuente también ayudan al equipo a agradecer a la persona adecuada y a ver qué referencias producen buenas coincidencias.
Recoge el nombre de la persona referida, su dirección de correo o teléfono, su ubicación cuando afecte a la prestación del servicio y el medio de contacto preferido. Incluye un campo en lenguaje sencillo para explicar el motivo de la presentación. «Necesita ayuda para configurar un portal de clientes antes de julio» resulta mucho más útil que «podría estar interesado».
El consentimiento necesita su propio campo. El referente debe confirmar que la persona aceptó compartir sus datos, junto con la fecha y el medio del consentimiento. Por ejemplo, el formulario puede ofrecer correo electrónico, llamada telefónica, reunión o formulario escrito. Si el consentimiento no está claro, deja la referencia pendiente y pide al referente que lo confirme antes de que alguien se ponga en contacto.
Usa una sección breve de cualificación para los datos que afectan al siguiente paso:
Evita pedir a los referentes que puntúen un posible cliente o redacten un perfil largo. Puede que no conozcan la respuesta, y las suposiciones pueden influir en la primera conversación. Unos pocos campos concretos crean registros más limpios que un formulario grande lleno de casillas opcionales.
Mantén separadas las notas internas y los datos proporcionados por el referente. «Pidió una demostración el próximo martes» pertenece a las notas de actividad, mientras que «Referido por Maya Chen después de una reunión de proyecto» pertenece al registro inicial. Así resulta más sencillo revisar los resultados de las referencias y se evita que el personal sobrescriba los datos originales.
Si creas el formulario en AppMaster, haz obligatorios el consentimiento, los datos de contacto y el motivo de la presentación. Deja opcionales al principio los campos de cualificación. El equipo puede recopilar el contexto que falte durante la primera llamada en lugar de retrasar una respuesta oportuna.
Una referencia nunca debería quedar en un estado impreciso como «en proceso». Dale a cada presentación un estado que indique qué ha ocurrido y qué debe suceder después.
Usa un conjunto breve de etapas que refleje el trabajo real de tu equipo:
Escribe estas definiciones en el flujo. «Contactada» debe significar que alguien envió el correo, hizo la llamada o utilizó otro medio de contacto registrado. No debe significar que alguien planea hacerlo.
Cada referencia activa necesita un único responsable. Esa persona puede pedir ayuda a sus compañeros, pero sigue siendo responsable del registro, la próxima acción y las actualizaciones. Cuando las responsabilidades se comparten, a menudo nadie se hace cargo cuando las bandejas de entrada se llenan.
Añade una próxima acción y una fecha límite antes de avanzar una referencia. Después de la revisión, el responsable puede tener que confirmar el consentimiento antes del jueves. Después del contacto, quizá deba llamar de nuevo dentro de tres días laborables. Si la próxima acción está vacía, es probable que el registro se enfríe.
Un registro sencillo podría decir: «Estado: Contactada. Responsable: Maya. Próxima acción: enviar un correo de seguimiento. Fecha límite: 16 de mayo». Cualquiera que revise la referencia podrá entender su situación en cuestión de segundos.
Mantén las referencias cerradas en el mismo sistema en lugar de borrarlas. Registra el resultado y un motivo breve, como «no encaja», «sin respuesta después de tres intentos» o «se convirtió en cliente». Estas notas muestran qué referencias de redes profesionales generan presentaciones adecuadas y dónde necesita mejorar el proceso.
Un flujo de recepción de referencias funciona mejor cuando cada presentación sigue el mismo recorrido breve. El referente no debería tener que escribir a varias personas ni adivinar quién se ocupa de la relación.
Empieza con un único formulario de envío. Pide el nombre del referente, los datos de contacto de la persona referida, el motivo de la presentación, la confirmación del consentimiento y cualquier contexto útil. Mantén separadas las preguntas opcionales para que el formulario siga siendo rápido de completar.
Usa estados que reflejen acciones reales, como Nueva, Pendiente de revisión, Aceptada, Contactada, Cualificada, Cerrada y Rechazada. En las referencias rechazadas, registra un motivo sencillo, como contacto duplicado, fuera del área de servicio o falta de adecuación. El equipo puede utilizar esos resultados para orientar mejor a los referentes en el futuro.
AppMaster puede mantener el formulario, el registro de referencias, las reglas de asignación y las notificaciones en una sola aplicación no-code. Un Business Process puede comprobar si existe consentimiento, dirigir las referencias completas a la persona adecuada y crear automáticamente una tarea de seguimiento. El equipo trabaja con el mismo registro en lugar de copiar datos entre bandejas de entrada y hojas de cálculo.
Una consultora presenta a Maya, propietaria de una pequeña empresa de logística, a un equipo de software. Maya necesita un portal de clientes donde puedan consultar las actualizaciones de sus envíos, subir documentos y enviar solicitudes de servicio. La consultora incluye el permiso de Maya para compartir sus datos de contacto y una breve descripción del problema.
El equipo crea ese mismo día un registro de la referencia. Incluye el nombre de la consultora, la empresa de Maya, el medio de contacto y la fecha de la presentación. El registro indica que Maya aceptó recibir una presentación por correo electrónico y espera que el equipo de software se ponga en contacto con ella. Este dato evita enviar un primer mensaje incómodo que presuponga un permiso mayor del que realmente dio.
El equipo también registra la necesidad en un lenguaje sencillo. Actualmente, los clientes escriben por correo para preguntar por el estado de los envíos, el personal envía actualizaciones manualmente y Maya quiere disponer de un portal antes de la temporada alta. Añaden los usuarios previstos, las tareas principales y cualquier fecha límite que Maya haya mencionado.
Una persona del equipo se encarga de la referencia y envía una respuesta personalizada en el plazo de un día laborable. Agradece la presentación a la consultora, reconoce la presentación y pide a Maya que elija una hora para una llamada breve. El estado cambia de «Nueva» a «Contactada», de modo que nadie más envía el mismo mensaje.
Durante la llamada, el responsable registra lo que el equipo necesita saber para decidir si el trabajo encaja. En el caso de Maya, las notas pueden incluir un inicio de sesión seguro para clientes, un área administrativa para el personal, una conexión con los datos de envíos existentes y una fecha objetivo de lanzamiento. Maya confirmará el presupuesto disponible.
Después de la llamada, el equipo marca la referencia como cualificada si la necesidad, el plazo y el proceso de decisión tienen sentido. Si el trabajo no encaja, selecciona «no cualificada» y escribe un motivo concreto, como un presupuesto inferior al tamaño mínimo del proyecto. Un resultado claro es mejor que dejar la referencia en duda durante semanas.
En una referencia cualificada, el responsable registra la próxima acción antes de terminar la llamada. Maya acepta celebrar una reunión de descubrimiento con su gerente de operaciones, así que el registro incluye la fecha, los asistentes y el objetivo. Cada actividad completada añade una nota fechada y crea un proceso sencillo de seguimiento de referencias que no depende de la memoria.
Si Maya sigue adelante, el equipo cierra la referencia como «ganada» y registra el trabajo acordado. Para un portal con flujos y conexiones de datos, podrían utilizar una plataforma no-code como AppMaster para crear el backend, la aplicación web y la aplicación móvil desde un mismo proyecto. Si Maya elige otro proveedor o pausa el proyecto, el responsable registra el resultado y cualquier motivo que ella comparta.
La consultora recibe una actualización breve y respetuosa. El equipo puede decirle que Maya aceptó una reunión de descubrimiento, inició un proyecto o decidió hacer una pausa. No debe compartir cifras privadas de presupuesto, notas internas ni datos que Maya no haya aprobado.
La mayoría de las referencias no desaparecen porque alguien decida ignorarlas. Desaparecen en pequeñas brechas: una presentación queda en una bandeja de entrada, una nota no tiene fecha o dos personas suponen que la otra responderá.
Un referente puede decir: «Está encantado de que te pongas en contacto», pero un mensaje verbal deja demasiados aspectos sin aclarar. Registra quién dio el consentimiento, cuándo lo dio, qué medio de contacto aprobó y qué información aceptó compartir.
No envíes por defecto informes detallados de progreso al referente. Comparte únicamente lo que la persona referida haya aprobado. «Contacto realizado» puede ser apropiado, pero el motivo del rechazo o sus necesidades personales quizá no lo sean.
Cada referencia nueva necesita un único responsable. Una bandeja compartida o una cola general puede recibir una presentación, pero no debería seguir siendo la responsable. Si un coordinador de ventas la asigna a un asesor, el registro debe mostrar esa transferencia y la próxima acción.
Evita notas como «hacer seguimiento pronto» o «contactar más adelante». Describen una intención, no una tarea. Añade una acción concreta, una fecha límite y una persona responsable. Por ejemplo: «Llamar a Jordan para confirmar disponibilidad antes del martes 10 de junio. Responsable: Priya».
Una herramienta de flujo puede señalar tareas vencidas, pero no puede arreglar un registro sin responsable ni fecha. En AppMaster, los equipos pueden crear formularios de recepción, reglas de estado y pantallas de tareas alrededor del proceso que ya utilizan, en lugar de depender de mensajes dispersos.
No cierres una referencia simplemente porque no se logró el contacto o porque terminó una conversación. Registra el resultado: cliente aceptado, no cualificada, rechazada, referencia duplicada, sin respuesta después de los intentos acordados u otro motivo claro. Incluye la fecha de cierre y una nota breve y objetiva.
Estos resultados señalan mejoras prácticas. Si muchas referencias se detienen después del primer mensaje, mejora el primer contacto. Si una fuente envía presentaciones que no encajan, revisa con ella los criterios de cualificación.
Una revisión semanal de 20 a 30 minutos evita que las presentaciones desaparezcan después del primer mensaje. Comprueba siempre los mismos campos.
Empieza por la fuente de la referencia. Cada registro debe indicar la persona u organización que hizo la presentación. Si alguien escribió «evento de networking» en lugar de un nombre, actualízalo mientras sea fácil encontrar el dato.
Después, comprueba el consentimiento. Cada referencia necesita una fecha y un texto que explique qué aceptó compartir la persona. Una dirección de correo reenviada no da automáticamente permiso para añadir a alguien a una lista de correo ni para contactar con esa persona sobre servicios no relacionados.
A continuación, revisa el trabajo activo. Cada referencia abierta debe tener un responsable y una próxima acción con fecha límite. «Alex llamará el jueves para confirmar el presupuesto y el plazo» ofrece al equipo una tarea real. «Hacer seguimiento pronto» no.
Usa una lista breve:
El responsable debe completar una tarea vencida, establecer una nueva fecha realista o cerrar el registro indicando el motivo. Dejar tareas antiguas abiertas hace que la cola parezca más saludable de lo que realmente es.
Lee algunos registros, no solo los totales. Si varias referencias cualificadas se cierran porque el servicio no se ajustaba a sus necesidades, formula una pregunta de cualificación mejor. Si varias se cierran por falta de respuesta, revisa el momento y el texto del primer contacto.
Empieza poco a poco. Crea un formulario de referencias, asigna un responsable a cada presentación nueva y usa una lista corta de estados que todo el mundo entienda. Una primera versión práctica podría incluir Nueva, Contactada, Cualificada, En proceso, Cerrada ganada y Cerrada perdida.
Pide únicamente los datos que ayuden a la siguiente persona a actuar: quién hizo la referencia, cómo contactar con el posible cliente, qué necesita, si aceptó recibir una presentación y cualquier contexto útil. Añade campos más adelante solo cuando el equipo tenga un motivo claro para utilizarlos.
Prueba el flujo con unas pocas referencias reales. Observa cuánto tarda cada transferencia y en qué punto la gente deja de actualizar el registro. Si un coordinador recibe referencias rápidamente, pero espera dos días a que un gerente confirme si encajan, corrige ese retraso antes de añadir más preguntas al formulario.
Mantén una revisión semanal breve hasta que el proceso se vuelva rutinario. Busca referencias sin responsable, sin actividad siguiente o con un estado que no haya cambiado recientemente. Compara también los resultados por fuente. Si las presentaciones de un socio rara vez se cualifican, ajusta lo que el equipo pide antes de aceptar la siguiente referencia.
Cuando las cadenas de correo y las hojas de cálculo ya no permiten que todos tengan la misma visión, lleva el proceso a una aplicación compartida. AppMaster permite a los equipos crear una aplicación de referencias no-code con formularios de recepción, reglas de flujo, campos de responsables y registros de seguimiento. Crea la primera versión alrededor del trabajo que tu equipo ya realiza, y después elimina los campos que no se usan y agiliza las transferencias lentas tras unas semanas de uso real.
¿Qué información debe recopilar un formulario de recepción de referencias?Registra al referente, los datos de contacto aprobados de la persona referida, el motivo de la presentación, el consentimiento y cualquier necesidad relacionada con los plazos o el servicio. Mantén corto el primer formulario para que la gente lo complete.
¿Cómo registro el consentimiento de una referencia?Pide al referente que confirme que la persona aceptó compartir sus datos. Guarda la fecha del consentimiento, cómo lo dio y el medio de contacto que aprobó antes de que alguien se ponga en contacto con ella.
¿Quién debe ser responsable de una referencia?Asigna un único responsable interno a cada referencia activa. Esa persona mantiene actualizado el registro, completa o delega la próxima acción y se asegura de que haya alguien que pueda asumir el trabajo cuando sea necesario.
¿Qué estados debe utilizar un flujo de referencias?Usa un conjunto reducido de estados basados en acciones, como Recibida, En revisión, Contactada, Cualificada y Cerrada. Define cada estado con claridad para que «Contactada» signifique que alguien realmente intentó ponerse en contacto.
¿Cómo evito que las referencias se enfríen?Añade una próxima acción concreta y una fecha límite a cada registro abierto. Por ejemplo, «Enviar un correo a Sam para concertar una llamada antes del jueves» da al responsable una tarea clara y permite a los gerentes detectar retrasos.
¿Qué debe ocurrir después de enviar una referencia?Comprueba si hay nombres duplicados, confirma el consentimiento y los datos de contacto y asigna un responsable antes del primer contacto. Si falta información, pide una aclaración al referente en lugar de hacer suposiciones.
¿Qué actualizaciones puedo compartir con el referente?Comparte únicamente la actualización que la persona referida haya aprobado. Por lo general, el referente puede recibir una confirmación de recepción, de contacto o un resultado general, pero las notas privadas, los datos de presupuesto y los motivos de rechazo deben permanecer dentro del equipo.
¿Deben mantenerse separados las notas y los datos iniciales de la referencia?Mantén separados los datos originales de la referencia y las notas de actividad posteriores. Guarda quién hizo la presentación y por qué en el registro inicial, y registra las llamadas, los correos, las reuniones y los resultados de la cualificación como actualizaciones fechadas.
¿Qué debe incluir una revisión semanal de referencias?Revisa una vez por semana las referencias abiertas para detectar consentimientos ausentes, responsables sin asignar, acciones vencidas y estados que no han cambiado. Compara también las fuentes con los resultados cualificados y cerrados para encontrar patrones que convenga abordar.
¿Puedo crear una aplicación de seguimiento de referencias sin programar?Sí. AppMaster permite crear una aplicación de referencias sin código con formularios de recepción, pantallas basadas en roles, campos de responsables, reglas de estado, notificaciones y tareas de seguimiento. Sus flujos visuales pueden comprobar el consentimiento, dirigir las referencias y mantener la actividad en un único registro compartido.
14 jul 2026
6 min
13 jul 202610 min
08 jul 202610 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
