El cliente debe entender a quien ayudas, por que confiar, y que resultado busca producir la sesion.
ConsultaChecklist consultor
Checklist de readiness del consultor
Este checklist es la version publica del nivel de readiness que Consulta usa antes de listar un consultor. Mantiene honestidad: un perfil debe sentirse reservable, listo para pago y con soporte antes de enviarlo a clientes.
Intros gratis, duraciones pagadas, tarifas, moneda y ventanas de politica deben configurarse antes de promover el perfil.
Toda reserva necesita una ruta obvia para confirmacion, Beam, calendario, recordatorios y recuperacion.
Perfil y prueba
El perfil debe responder las primeras preguntas de confianza antes del calendario. Identidad, posicionamiento, resultados, idiomas, preparacion y una foto usable importan porque la pagina de reserva tambien es la vitrina del consultor.
- Nombre publico, foto, titular, idiomas, zona horaria y ruta de contacto estan listos.
- Areas de enfoque, resultados, preparacion y FAQs son suficientemente especificos para vender la sesion.
- No se hace claim regulado, legal, financiero o de cumplimiento sin una politica aprobada para esa oferta.
Ofertas y precios
Un consultor debe publicar un menu simple: una intro gratis opcional y sesiones pagadas con duraciones y tarifas claras. Las reglas de dinero siguen visibles porque sesiones pagadas confirman solo con prueba server-side.
- La intro gratis esta activada o desactivada intencionalmente, con duracion configurada.
- Duraciones pagadas y tarifas BZD estan configuradas como datos de oferta, no texto hardcoded.
- Modo de proveedor de pago, checkout hospedado, QR/links de pago, refunds y rutas WOP estan claros antes de claim live paid booking.
Disponibilidad y politica
La disponibilidad debe ser operativa, no aspiracional. La pagina publica solo debe ofrecer horarios creados desde zona horaria, ventanas semanales, buffers, aviso minimo, bloqueos y conflictos confirmados.
- Ventanas semanales regulares estan configuradas en la zona horaria del consultor.
- Aviso minimo, ventana de cambio, ventana de cancelacion y buffers estan como datos de politica.
- Fechas bloqueadas y limitaciones de temporada se registran antes de promover el perfil.
Entrega al cliente
El cliente nunca debe preguntarse a donde ir despues de reservar. El pase de confirmacion es la respuesta canonica, y las notificaciones deben repetir esos datos en vez de enviar links dispersos.
- El pase muestra detalles, ruta Beam unica, acciones de calendario y acciones de politica.
- Correo y WhatsApp deben apuntar al pase cuando el proveedor de envio este live.
- Links vencidos o perdidos van a recuperacion de Cuenta y WhatsApp 501-672-3021.
Gates de proveedor
Algunas partes siguen gated mientras Consulta esta en MVP revisado. Un perfil publico puede ser util antes de que todo proveedor este live, pero la pagina no debe sobreprometer lo que no se probo.
- Silvatech Payments live y WOP/SMTP necesitan credenciales, callbacks, templates y smoke proof.
- Sync de calendario conectado, cuentas completas, publicacion automatica y links privados siguen como gates posteriores.
- Texto legal, privacidad y data policy sigue visible y draft/open donde falta aprobacion final.
Como usarlo
Usa este checklist antes de solicitar revision, antes de compartir un perfil con un cliente, y despues de cambiar tarifas, politica, disponibilidad o configuracion de proveedor.
- Consultores prospectivos pueden reunir la informacion antes de usar Registro.
- Operadores usan el dashboard protegido para configurar ofertas, disponibilidad, politicas, readiness y sharing.
- Clientes usan paginas publicas de confianza para entender que esta live, que esta simulado y como recuperar acceso.