01 — Contexto
MP Asistencias Legales es una firma de Bogotá que acompaña a personas naturales y pequeños comerciantes en procesos de insolvencia económica, con atención principalmente virtual. El sitio le habla a alguien que ya está en mora y recibe llamadas de cobro.
El encargo era explicar un proceso judicial, con carga emocional y jurídica, sin alarmismo ni promesas, y llevar a la persona hacia una revisión inicial de su caso sabiendo qué se revisa y qué no. Diseñé la experiencia UX/UI y desarrollé el sitio en WordPress, sobre un tema a medida.
02 — Mi rol
Ordené el recorrido de la home (problema, elegibilidad, mecanismo, proceso y primer paso) y diseñé la home, las páginas de servicio, la página de contacto y el formulario de revisión. Desarrollé el tema, el formulario con su endpoint, que clasifica cada consulta, y la capa de eventos, incluidos los enlaces de WhatsApp que llevan su origen. Instrumenté GA4 y revisé mapas de calor en Clarity. El copy y las fotos los aportó el cliente.
03 — Diagnóstico
Un proceso judicial que se lee bajo presión de cobro
El riesgo del encargo era doble: sonar alarmista o sonar a promesa. Era un sitio nuevo, sin una versión anterior que corregir, así que la pregunta era cómo plantearlo desde el principio. Asumí que la persona llega con una pregunta concreta, si puede acogerse al proceso, y no con el nombre del trámite. Mi lectura: si la página empieza por la firma o por la solución, la persona no sabe si su caso encaja hasta después de haber contado sus deudas.
Ese orden le costaría a la persona, que probablemente escribe con miedo a exponer su situación y desconfía de quien le promete eliminar sus deudas. Y le costaría a la firma, que recibiría consultas de casos que no cumplen las condiciones y tendría que reunir en la primera llamada los datos que dicen si hay proceso.
04 — Decisiones
A. Tres salidas según cuánto quiere exponerse la persona
- Problema
- Pedir los datos de la deuda de entrada es una barrera alta para alguien que todavía no sabe si le conviene hablar con un abogado.
- Decisión
- El hero ofrece tres botones: "Hablar por WhatsApp" como principal, "Solicitar revisión inicial", que lleva a la página de contacto, y "Agendar llamada", que marca el número de la firma.
- Por qué esa
- Valoré un único botón hacia el formulario; preferí tres salidas porque el formulario obliga a escribir montos y acreedores antes de la primera conversación. El coste: tres botones de peso parecido que compiten entre sí y que en móvil ocupan casi toda la primera pantalla.
- Qué esperaba
- Que cada persona empezara por el canal con el que se sintiera menos expuesta, y que nadie se fuera por falta de uno.
B. WhatsApp en todas partes, y cada enlace dice de dónde viene
- Problema
- Una conversación de WhatsApp no deja rastro en la analítica: la firma no sabe qué parte de la página la inició.
- Decisión
- WhatsApp está en el header fijo, en un botón flotante y en cada cierre. Los nueve enlaces de la home abren wa.me con un mensaje prellenado que termina en su origen ("Origen: wp-home-hero", "wp-footer"…), y el botón flotante se reduce a un icono mientras hay un botón principal a la vista.
- Por qué esa
- Valoré quedarme con el evento de clic en la analítica; preferí marcar además el origen dentro del mensaje porque el evento cuenta el clic, pero no ve si la conversación empezó. El coste: la persona ve una etiqueta técnica en su primer mensaje, justo en un tema delicado.
- Qué esperaba
- Saber qué bloques inician conversaciones y cuáles sobran, aunque la conversación siga fuera del sitio.
C. Las condiciones antes que el proceso
- Problema
- Quien no cumple las condiciones lo descubre tarde, después de haber contado su caso.
- Decisión
- Justo después del hero, el bloque "¿Puedo acceder al proceso de insolvencia?" presenta las cuatro condiciones numeradas, una tarjeta que abre un vídeo explicativo y un cierre que dice "Si cumples varias condiciones, tu caso merece revisión" antes del botón. El panel del hero adelanta esas condiciones.
- Por qué esa
- Valoré un test de elegibilidad con veredicto automático; preferí las condiciones como lectura porque solo un abogado puede decir si un caso aplica. El coste: se pierde la inmediatez de una respuesta a cambio de no dar falsas certezas, y la persona hace la cuenta sola.
- Qué esperaba
- Menos consultas de casos que no aplican, y que las que llegan lo hagan sabiendo por qué.
D. Decir lo que el proceso no hace
- Problema
- En insolvencia, la promesa que más atrae, eliminar las deudas, es también la que el proceso no cumple.
- Decisión
- El bloque del mecanismo dice en su segundo párrafo "Las deudas no se eliminan. Se reorganizan y renegocian…", y el proceso se explica en cinco etapas de una frase, de la revisión inicial a la ejecución del acuerdo.
- Por qué esa
- Valoré un tono de alivio inmediato; preferí decir pronto lo que el proceso no hace porque quien llega desconfía de quien le promete eliminar sus deudas. El coste: una promesa menos atractiva a primera vista, a cambio de consultas de personas que ya saben que el proceso es una negociación con sus acreedores.
- Qué esperaba
- Consultas con expectativas realistas, y menos abandono cuando el abogado explica el alcance.
E. Un formulario que pregunta lo que decide la viabilidad
- Problema
- Con solo nombre y teléfono, el abogado tiene que reunir en la primera llamada los datos que dicen si hay proceso.
- Decisión
- El formulario de revisión pide diez datos, cuatro obligatorios: nombre, celular, monto en rangos y número de acreedores. Mora y procesos activos van como selectores, el monto admite "Prefiero no indicarlo por ahora" y, antes del botón, un aviso dice que enviar no es una aprobación. El envío va a un endpoint propio que clasifica cada consulta.
- Por qué esa
- Valoré un formulario mínimo seguido de una llamada de calificación; preferí preguntar en el formulario por las condiciones porque son los datos que permiten al abogado priorizar. El coste: más campos, aunque los rangos y la opción de no indicar el monto bajan el de la pregunta más delicada.
- Qué esperaba
- Consultas que llegan clasificadas y con las condiciones ya respondidas, y menos llamadas de descubrimiento.
05 — Sistema
Quedó una home ordenada como recorrido: hero con tres salidas y el marco legal (Fig. 0), elegibilidad (Fig. 2), problema, mecanismo y proceso (Fig. 3), un bloque de confianza y un cierre con WhatsApp y formulario. Alrededor, WhatsApp con el origen en cada enlace y un botón flotante que cede ante los botones principales (Fig. 1), un formulario de revisión con un endpoint propio que clasifica cada consulta (Fig. 4) y las plantillas de insolvencia, requisitos, embargos, FAQ y blog.
El alcance cerró en entrega e instrumentación, no en reporting de impacto, así que este caso no reporta cifras.
06 — Qué probaría ahora
Hoy el hero reparte la atención en tres botones: "Agendar llamada" marca directamente el número de la firma, y "Solicitar revisión inicial" abre la página de contacto por arriba, varias pantallas antes del formulario (Fig. 0 frente a Fig. 4). Probaría dos salidas, con la revisión llevando directo al formulario.
- Hipótesis
- Si el hero deja dos botones, WhatsApp y "Solicitar revisión inicial" con destino directo al formulario, suben los envíos del formulario desde la home sin que bajen las conversaciones por WhatsApp.
- Métrica primaria
- Envíos del formulario de revisión por sesión que entra por la home, con el evento contact_form_submit en GA4.
- Guarda
- Clics a WhatsApp desde el hero (whatsapp_click con origen wp-home-hero) por sesión: si caen, se descarta la variante.
- Control
- El hero actual, con tres botones. Reparto 50/50 hasta el tamaño de muestra calculado sobre la línea base; con el tráfico de un despacho, probablemente varias semanas.