Participe en las pruebas de LadVen OSSolicitar demo
Saltar al contenido principal

Formularios

Los formularios de LadVen OS reciben solicitudes desde el sitio, una landing, la documentacion o una pagina externa y las convierten en trabajo gestionado dentro de CRM. Sirven para demos, consultas de clientes, solicitudes de asesoria, soporte y otros flujos de entrada.

Un formulario debe pedir solo los datos necesarios para el siguiente paso: quien escribe, como contactarle, que necesita y a donde debe ir la solicitud.

Cuando usar formularios

Cuando usar formularios — conceptual guidance, not UI evidence

Use formularios para captar solicitudes del sitio, enviarlas al pipeline CRM correcto, estandarizar campos de entrada, revisar solicitudes, separar spam de trabajo real y saber que version publicada esta activa.

Si la solicitud llega por correo o chat, no la copie manualmente sin motivo. Vincule el mensaje o la conversacion con CRM cuando eso conserve mejor contexto.

Elegir escenario y responsable

Elegir escenario y responsable — conceptual guidance, not UI evidence

Antes de crear el formulario, defina quien es responsable del escenario: marketing, ventas, soporte u operaciones. Esa persona aprueba campos, texto de consentimiento, ruta CRM, primer responsable y regla para cerrar solicitudes de baja calidad.

Para cada formulario fije objetivo, pagina de ubicacion, idioma principal, idiomas adicionales, campos obligatorios, pipeline CRM, etapa inicial, revisor diario y condicion para retirarlo o archivarlo.

Escenario de solicitud de demo

Escenario de solicitud de demo — conceptual guidance, not UI evidence

Una solicitud de demo debe llevar rapidamente a la prueba del producto. Normalmente bastan nombre, contacto laboral, empresa, rol, idioma preferido y una breve descripcion. No pida presupuestos internos, contrasenas, tokens ni datos personales innecesarios en el primer paso.

Despues de una solicitud de prueba, compruebe que llega al responsable correcto, el texto es claro, el idioma no se mezcla y el origen ayuda a entender desde que pagina llego la persona.

Consulta de cliente o soporte

Consulta de cliente o soporte — conceptual guidance, not UI evidence

Para asesoria, soporte o consulta de cliente, agregue campos que ayuden a calificar: tema, area de producto, horario de contacto, adjunto solo si es necesario y comentario. Si debe ir a soporte o account management en vez de ventas, use una ruta y un responsable separados.

No mezcle procesos distintos en un mismo formulario. Demo, solicitud de partner y soporte suelen necesitar formularios diferentes.

Crear el formulario

Crear el formulario — conceptual guidance, not UI evidence

En el constructor configure nombre, codigo, idioma principal, titulo, descripcion, boton de envio y campos. El nombre interno debe ser claro para el equipo; titulo y descripcion deben ser claros para la persona externa.

Los campos deben ser breves: nombre, contacto, empresa, pregunta, horario de contacto y comentario. Si hay varios idiomas, revise textos y etiquetas de campos en cada idioma antes de publicar.

Campos obligatorios y calidad de datos

Campos obligatorios y calidad de datos — conceptual guidance, not UI evidence

No agregue campos obligatorios innecesarios. Cuanto mas largo es el formulario, menor es la probabilidad de envio. Haga obligatorio solo lo que el equipo necesita para responder o calificar.

Un buen formulario evita preguntas duplicadas, usa nombres claros, no usa abreviaturas internas, no pide elegir una etapa interna de CRM y recoge consentimiento y contacto con lenguaje simple.

Publicar y colocar

Publicar y colocar — conceptual guidance, not UI evidence

Guardar un formulario no siempre cambia el sitio publicado. Antes de publicar revise vista previa, campos obligatorios, idiomas, apariencia, proteccion antispam, dominios permitidos y ruta CRM.

Despues de publicar, coloque el formulario solo en paginas que deban recibir solicitudes reales. Si se retira o archiva, confirme que el sitio ya no tiene una entrada activa.

No muestre claves activas, contactos reales ni enlaces privados en materiales de formacion ni en demostraciones. Para mostrar el trabajo a colegas, cree un formulario de prueba aparte con datos seguros.

Ruta CRM

Ruta CRM — conceptual guidance, not UI evidence

Elija pipeline, etapa inicial y reglas para nuevas solicitudes. Si no se elige ruta, el formulario puede usar reglas generales de la plataforma.

Una buena ruta aclara quien ve primero la solicitud, donde aparece, que campos la califican, quien resuelve errores CRM y cuando se considera aceptada.

Solicitudes y estados

Solicitudes y estados — conceptual guidance, not UI evidence

Revise solicitudes con regularidad. Una solicitud debe quedar aceptada, marcada como spam o reenviada despues de corregir errores CRM. Si parece sospechosa, no la pase a trabajo hasta comprobar contacto y contenido.

Para errores CRM, revise campos obligatorios, ruta, permisos y datos del cliente antes de reintentar. Si el error se repite, entregue al responsable el formulario, la solicitud exacta y el comportamiento esperado.

Localizacion y consentimiento

Localizacion y consentimiento — conceptual guidance, not UI evidence

Si el formulario tiene varios idiomas, revise titulo, boton, etiquetas, errores, consentimiento y notificacion al responsable. La persona debe ver un solo idioma en todo el envio.

El consentimiento debe explicar por que se recogen datos y quien los procesa. No reutilice textos legales de otro pais o proceso sin revision.

Seguridad

Seguridad — conceptual guidance, not UI evidence

No recoja contrasenas, tokens, documentos personales, datos de pago ni otra informacion sensible innecesaria mediante formularios publicos. En formularios para clientes, acuerde de antemano el texto del consentimiento y la finalidad de la recopilacion. Revise dominios permitidos y formularios activos con la misma disciplina que los enlaces publicos a archivos.

Checklist del manager

Checklist del manager — conceptual guidance, not UI evidence

  • El formulario tiene responsable y escenario claro.
  • Los campos coinciden con el siguiente paso de trabajo.
  • Los campos obligatorios son minimos.
  • Idiomas, consentimiento y boton estan revisados.
  • Una solicitud de prueba llego al pipeline CRM correcto.
  • El responsable sabe aceptar, marcar spam y reintentar.
  • El sitio no contiene una version vieja o archivada.

Errores comunes

Errores comunes — conceptual guidance, not UI evidence

  • Un formulario se usa para todas las solicitudes de entrada.
  • Se piden datos que el equipo puede aclarar despues.
  • La pagina donde esta colocado no se revisa tras cambios.
  • Las solicitudes se copian a mano y pierden el origen.
  • El spam entra al pipeline de trabajo.
  • Para las demostraciones, use contactos sintéticos y un formulario de prueba separado con un ejemplo de inserción no productivo o enmascarado; nunca use contactos reales ni código de inserción activo.

Escenarios para el negocio

Escenarios para el negocio — conceptual guidance, not UI evidence

Secciones relacionadas

Secciones relacionadas — conceptual guidance, not UI evidence