Cómo planificar flujos digitales seguros para clientes

Lo que es

Un flujo de trabajo orientado al cliente puede abarcar un portal, un servicio web, una experiencia móvil, un backend, una API, un proveedor de pagos, un proceso de soporte y un equipo administrativo. La planificación debe identificar los roles de usuario y los límites de acceso; la autenticación y la recuperación; los formularios, archivos, mensajes, paneles y estados; las rutas de pago, suscripción, factura, reembolso, cancelación y derechos de acceso; la titularidad y la conservación de los datos; las integraciones con terceros; y la responsabilidad operativa. También debe decidir si conviene una solución móvil o web, si el backend y las API existentes están preparados y quién se encargará de los registros, el soporte, los cambios y el traspaso. La revisión de seguridad y la entrega de software pueden tener alcances independientes.

Para quién es

Esta guía ayuda a equipos que planifican:

• Un portal para clientes o socios, un flujo de recepción de solicitudes, un panel, un recorrido de pago, una transición de web a móvil o el lanzamiento de una aplicación
• Accesos según el rol, recuperación de cuentas, archivos, información de estado, soporte y responsabilidades administrativas
• Un cambio de producto que implica backends, API, proveedores externos, estados de facturación o datos de clientes existentes
• Un límite más claro entre el descubrimiento, el diseño, la entrega, el refuerzo, la revisión y la posterior responsabilidad operativa

Qué ayuda a aclarar

Las preguntas de planificación ayudan a revelar:

• Si los usuarios, los roles, las reglas de acceso, la recuperación de cuentas, la titularidad de los datos y su conservación se comprenden antes de empezar la entrega
• Qué formularios, archivos, mensajes, paneles, vistas de estado, estados de pago y decisiones sobre derechos de acceso cruzan los límites entre sistemas
• Si las integraciones, el backend y las API, la entrega móvil, la fase de lanzamiento, los registros, el soporte y la responsabilidad sobre los cambios están preparados para un siguiente paso con alcance definido
• Si el equipo necesita un sprint de portal, una revisión de pagos, una transición de web a móvil, una revisión de preparación para el lanzamiento, el refuerzo del sitio web o un trabajo previo de descubrimiento o blueprint

Qué se incluye

• Una lista de comprobación para compradores que abarca recorridos, roles, acceso, autenticación, recuperación, formularios, archivos, mensajes, paneles, estados, pagos, suscripciones, facturas, reembolsos, cancelaciones, derechos de acceso, datos e integraciones
• Preguntas de planificación sobre la responsabilidad administrativa, la preparación del backend y las API, la elección entre móvil y web, la fase de lanzamiento, los registros, el soporte, el control de cambios y el traspaso
• Una comparación de cuándo pueden ser relevantes Secure Client Portal Sprint, Subscription & Payment Infrastructure Security, Secure Web-to-Mobile Launch, App Launch Readiness y Website Performance & Security Hardening
• Un recordatorio de que unos flujos, roles, integraciones o responsabilidades poco claros pueden requerir un trabajo de descubrimiento o de blueprint antes de la entrega

Qué no se incluye

• La promesa de seguridad, idoneidad regulatoria, aprobación de pagos, prevención del fraude, ingresos, aprobación en las tiendas, éxito del lanzamiento, disponibilidad, rendimiento o funcionamiento ininterrumpido
• La afirmación de que un sprint de portal es una plataforma SaaS completa, de que una revisión de pagos es una certificación PCI o una operación contra el fraude, o de que la entrega móvil deja automáticamente un producto listo para su lanzamiento
• La sugerencia de que el refuerzo sustituye al diseño de aplicaciones, las pruebas de carga, la respuesta a incidentes o las operaciones continuas
• La suposición de que la entrega de software, la revisión de seguridad, la aprobación del proveedor y la responsabilidad continua forman un único alcance automático

Cuándo elegirlo

Utilice esta guía antes de que un cambio orientado al cliente se convierta en una lista de funcionalidades inconexas. Resulta útil cuando un equipo está decidiendo si desarrollar un portal, modificar los accesos, introducir suscripciones, ampliar un servicio web a móvil, preparar el lanzamiento de una aplicación o mejorar un sitio web. Si el flujo básico, las responsabilidades, las integraciones o los roles de usuario siguen sin estar claros, un trabajo de descubrimiento o de blueprint de producto suele aportar más valor que una implementación temprana. Después puede seguir una revisión con alcance definido, cuando esté lista una cuestión concreta de seguridad u operativa.

Nuestro enfoque

Trace el recorrido antes de elegir el método de entrega. Empiece por el usuario, su rol, la decisión de acceso, los datos que aporta o ve, el sistema responsable del siguiente estado y el equipo responsable cuando algo cambia. Siga los estados de pago y de derechos de acceso con el mismo cuidado que las pantallas de la interfaz. Después, identifique las dependencias de proveedores y del backend, las necesidades de soporte y de registros, las restricciones móviles, la responsabilidad sobre la publicación y los requisitos de traspaso. Así se pone de manifiesto si la siguiente decisión se refiere a la entrega de un portal, la lógica de pagos, el trabajo de web a móvil, la preparación para el lanzamiento, el refuerzo del sitio web o un descubrimiento previo. También se evita que un servicio con alcance definido se confunda con una responsabilidad ilimitada de producto, operaciones o cumplimiento. Un mapa del flujo por escrito también puede recoger las rutas normales y excepcionales: un usuario nuevo, un pago fallido, una cancelación, una cuenta perdida, un archivo que falta, una caída de un proveedor o una solicitud de soporte. Ofrece a los equipos de producto, operaciones, ingeniería y soporte un lugar compartido para identificar responsables antes de que un cliente se vea afectado. Esa claridad puede reducir la desviación del alcance en los trabajos de entrega posteriores. A medida que avance la planificación, revise el mapa cada vez que cambien un proveedor, el modelo de pago, un rol, una regla de acceso, una API, un canal de publicación o un proceso de soporte. Un flujo que parecía sencillo en un diagrama puede tener excepciones importantes en producción. Registrar esas excepciones facilita decidir si el siguiente alcance es de diseño, entrega, revisión, refuerzo, pruebas o preparación operativa. También ayuda al comprador a solicitar a los proveedores las evidencias adecuadas antes de tomar una decisión. Por último, utilice el mapa para decidir qué se medirá tras la entrega y quién actuará ante una conclusión, un pago fallido, una señal de soporte o una solicitud de cambio. Un traspaso es más sólido cuando designa a un responsable, un punto de revisión y un límite acordado, en lugar de limitarse a enumerar funcionalidades.

Preguntas frecuentes

Artículos relacionados