Paso 1
Bienvenida y orientación
Comienza con una explicación tranquila de lo que el onboarding hará y no hará. La meta es avanzar sin fingir que todo debe configurarse de una vez.
TR-2531 onboarding y docs de lanzamiento en español
Este primer tramo de onboarding es intencionalmente un shell de docs y secuencia de lanzamiento, no un wizard falso. Hace más clara la ruta inicial ahora, mientras mantiene la IA en modo advisory, sensible a migración y limitada por aprobación explícita para acciones de alto riesgo.
El shell de lanzamiento debe reducir confusión secuenciando buenas decisiones, no fingiendo que todo puede manejarse automáticamente.
Paso 1
Comienza con una explicación tranquila de lo que el onboarding hará y no hará. La meta es avanzar sin fingir que todo debe configurarse de una vez.
Paso 2
El acceso debe ser deliberado desde el inicio. El onboarding puede explicar roles y postura de configuración, pero no debe alentar ampliaciones casuales de permisos solo para avanzar más rápido.
Paso 3
Concéntrate primero en el pequeño conjunto de decisiones fundacionales que facilitan el trabajo posterior. Deja la configuración avanzada para después en lugar de cargar todo al principio.
Paso 4
Mantén visibles la postura mes a mes, la prueba de dos meses, la visibilidad de hardship y la opción de ayuda guiada antes de que la iglesia construya expectativas equivocadas.
Paso 5
Haz explícito importar ahora versus después. La ayuda de migración debe ser honesta sobre staging y revisión en lugar de implicar perfección de un clic.
Paso 6
Las iglesias deben poder seguir aprendiendo sin verse forzadas a una migración completa de inmediato. Si van a importar, la ruta debe seguir siendo gradual, revisable y explícita.
Paso 7
Muestra una secuencia pequeña y de alto valor con límites claros entre lo opcional y lo requerido. Evita listas interminables de configuración y tours vacíos de funciones.
Paso 8
Después del onboarding, la iglesia debe saber qué es seguro hacer ahora, qué debe esperar y cuándo escalar a ayuda humana en lugar de adivinar.
Transparent debe sentirse inteligente reduciendo confusión, no quitando decisiones importantes de las manos de la iglesia.
Algunas acciones deberían prepararse desde onboarding, pero nunca ejecutarse casualmente a través de él.
El onboarding puede explicar estas acciones y ayudar a una iglesia a prepararse para ellas, pero el producto debe mostrar consecuencias en lenguaje claro y requerir aprobación explícita del operador antes del commit.
Esta es la primera superficie real de onboarding en español. El resto de la familia de docs de onboarding todavía no debe tratarse como si ya tuviera paridad completa.
Esto mantiene la página honesta sobre lo que ya aterrizó y lo que todavía pertenece a trabajo posterior.
Una secuencia tranquila del shell de lanzamiento que explica la ruta inicial, los límites de IA advisory, las decisiones sensibles a migración y las clases de aprobación explícita.
El primer set documental debe extender el onboarding, no separarse de él.
Una secuencia calma del shell de lanzamiento que explica la ruta inicial, los límites de IA advisory, elecciones sensibles a migración y clases de aprobación explícita.
Abrir doc de lanzamiento →Una lista corta de lanzamiento que separa decisiones inmediatas de evaluación de acciones que deberían esperar revisión explícita.
Abrir doc de lanzamiento →El shell de onboarding debe mantener soporte y escalación visibles antes de que una iglesia se atasque.
Usa el contenido de ayuda de lanzamiento cuando quieras primero la explicación gobernada.
Explorar centro de ayuda →Usa el asistente cuando un artículo de ayuda de lanzamiento pueda responder la pregunta rápidamente.
Abrir asistente de soporte →Usa intake estructurado cuando el problema esté bloqueado, sea sensible o se maneje mejor como caso.
Abrir intake estructurado →