Una presentación de retirada de un producto debe mostrar qué dejará de funcionar, quién depende de ello y cómo podrá continuar su trabajo cada grupo afectado. Una fecha de retirada no es un plan de transición. Las diapositivas más útiles conectan una tarea concreta con su alternativa, un responsable y cualquier decisión pendiente antes de anunciar el cambio.
Esta guía utiliza un portal de reservas ficticio. Sus usuarios web, responsables de integraciones y usuarios de registros necesitan instrucciones distintas. Puedes documentar primero esas rutas en un informe breve y después usar Presenti para convertir el documento de Word en un borrador de presentación. La presentación explica la transición; no migra cuentas, reservas ni registros históricos.
Explica exactamente qué dejará de funcionar
«Vamos a retirar el portal antiguo» puede parecer claro para el equipo de producto. Para un cliente deja preguntas abiertas: ¿podré iniciar sesión?, ¿seguirá siendo válida una reserva existente?, ¿fallará mi integración?, ¿podré recuperar los registros del año pasado?
Describe los comportamientos afectados antes de usar una etiqueta del ciclo de vida. Por ejemplo, el glosario de ciclo de vida de Microsoft da significados diferentes a obsolescencia, eliminación y retirada dentro de sus propias políticas. Esos términos no sustituyen una explicación de los cambios reales de tu servicio.
En el portal ficticio, el primer cambio propuesto consiste en dejar de aceptar nuevas reservas en la interfaz web antigua. Eso no decide, por sí solo, el futuro de las reservas existentes, las solicitudes API, el acceso a registros o el soporte. Sepáralos en filas distintas:
| Tarea del usuario | Cambio propuesto en el ejemplo | Qué debe resolver el equipo |
|---|---|---|
| Crear una reserva en el navegador | Las nuevas reservas pasan al portal sustituto. | Quién puede acceder, cuándo entra en vigor el cambio y dónde pedir ayuda. |
| Gestionar una reserva anterior al cambio | No queda resuelto al dejar de aceptar reservas nuevas. | Dónde se puede consultar, modificar o cancelar. |
| Crear reservas mediante una API | Requiere una transición de integración independiente. | Endpoint, autenticación, correspondencia de campos, tratamiento de errores y condiciones del cambio. |
| Recuperar registros históricos | Requiere una vía de acceso definida. | Registros disponibles, método de recuperación, acceso autorizado y política de conservación aplicable. |
La tabla evita que un anuncio aparentemente pequeño prometa mucho más. También ayuda a soporte a explicar el cambio sin improvisar políticas.
Dibuja la transición por tarea, no por nivel de cuenta
Un mismo cliente puede utilizar la web, mantener una integración y consultar registros históricos. Trátalos como usos que se solapan, no como segmentos excluyentes. Si cuentas organizaciones afectadas, elimina duplicados en ese recuento por separado: sumar las tres rutas podría contar varias veces la misma organización.
La guía de GOV.UK sobre retirada de servicios parte de lo que necesitarán los usuarios después y distingue usuarios directos de usuarios de API. Esa es una buena pregunta para esta presentación: ¿qué debe poder seguir haciendo cada persona?
| Ruta actual | Ruta siguiente | Pruebas necesarias antes de pedir el cambio |
|---|---|---|
| Recepción crea reservas en el portal antiguo. | Crear las nuevas reservas en el portal web sustituto. | La cuenta afectada puede iniciar sesión, crear una reserva y encontrar ayuda; el tratamiento de reservas existentes se explica aparte. |
| Un sistema de operaciones envía reservas por API. | Utilizar la integración sustituta admitida. | Su responsable ha definido campos y comportamiento, probado solicitudes representativas y acordado el cambio. |
| Una persona consulta reservas pasadas. | Utilizar un archivo o procedimiento de recuperación aprobado. | Un usuario autorizado puede encontrar y leer el registro necesario; hay un responsable de las cuestiones de conservación y acceso. |
No dibujes una flecha hacia «Nueva plataforma» para dar el trabajo por terminado. Muestra la tarea de destino. El sustituto quizá cree bien nuevas reservas, pero no permita cancelar una antigua. Esa carencia debe aparecer aunque la nueva plataforma tenga más funciones.
En las integraciones, concreta la correspondencia. Un campo llamado referencia de reserva en el servicio antiguo podría convertirse en otro identificador en el sustituto. Documenta si quien llama a la API conserva la referencia, guarda una nueva o necesita una consulta de equivalencias. Los nombres son ilustrativos; el contrato real lo define la documentación de la API, no quien escribe la diapositiva.
Separa el calendario propuesto de la promesa al cliente
Una presentación interna puede mostrar una fecha propuesta con una dependencia aún abierta. Un aviso a clientes solo debe comprometerse con el alcance aprobado. Identifica así el calendario interno para que una fecha tentativa no parezca una promesa cuando se reenvíe el archivo.
En el ejemplo, el acceso web podría estar listo antes que la correspondencia de la integración. El acceso a registros puede tener una tercera dependencia. Dibuja tres carriles con sus propios hitos: destino disponible, usuarios informados, acción del usuario completada y ruta antigua detenida. No fuerces una misma fecha final solo para ordenar el gráfico.
La reunión podría aprobar únicamente la comunicación del cambio web y dejar sin anunciar la fecha de retirada de la API. Eso no equivale a aprobar la retirada del servicio entero. Sitúa el alcance real de la decisión junto al calendario.
Si afectan contratos, reembolsos, accesibilidad u obligaciones sobre registros, incorpora las políticas aprobadas pertinentes y a sus responsables. Un modelo genérico de aviso no puede decidir esos términos. Mantén concreta la cuestión abierta —por ejemplo, «¿Qué equipo aprueba que continúe el acceso a los registros?»— en lugar de llenar la diapositiva de advertencias generales.
Escribe tres avisos para tres tareas distintas
Los siguientes modelos pertenecen al portal ficticio. Sustituye los campos entre corchetes por información aprobada antes de utilizarlos. Cada aviso comienza por la tarea afectada, indica la acción y ofrece una vía útil de ayuda.
Para quienes crean reservas en la web
A partir de [fecha, hora y zona horaria], utiliza [enlace del portal sustituto] para crear nuevas reservas. El portal actual dejará de aceptar nuevas reservas en ese momento. Las reservas anteriores al cambio podrán consultarse, modificarse o cancelarse mediante [vía confirmada para reservas existentes]. Antes de tu próxima reserva, inicia sesión en el nuevo portal siguiendo [instrucciones de acceso aprobadas]. Si no puedes acceder, contacta con [canal de soporte] e indica tu organización y la tarea que intentas completar.
La frase sobre reservas existentes es importante. Sin ella, alguien con una reserva para el próximo mes no sabrá si el anuncio le afecta. Si el equipo no ha resuelto esa ruta, debe hacerlo antes de enviar un aviso que parezca abarcar a todos los usuarios web.
Para responsables de integraciones
Tu integración utiliza [API o versión afectada] para enviar reservas. Está previsto que esa interfaz deje de aceptar solicitudes el [fecha, hora y zona horaria aprobadas]. La documentación de sustitución está en [enlace a la documentación]. Revisa la autenticación, los campos obligatorios, los identificadores de respuesta y el comportamiento ante errores de tu integración; después acuerda el cambio con [contacto técnico]. Envía el nombre de tu integración y la franja de cambio propuesta mediante [canal de soporte]. Trasladar a los usuarios web no actualiza esta integración.
Envía el aviso a quienes mantienen la integración, no solo al contacto comercial de la cuenta. Un anuncio general puede no llegar a quien debe modificar software y reservar tiempo para hacerlo.
Para quienes necesitan registros históricos
Si necesitas registros del portal actual de reservas, utiliza [vía de recuperación aprobada]. Ofrece [alcance y formato confirmados] a [usuarios o roles autorizados]. El acceso mediante el portal actual cambia el [fecha, hora y zona horaria aprobadas]. Para consultar sobre registros fuera del alcance disponible o sobre los requisitos de acceso, contacta con [canal de soporte de registros]. La información aplicable sobre conservación está en [enlace a la política aprobada].
No añadas «Todos tus datos se transferirán automáticamente» salvo que se haya establecido exactamente ese alcance y comportamiento. Un informe descargable, un archivo con búsqueda y un historial editable de reservas son resultados distintos; nombra el que los usuarios recibirán de verdad.
Organiza una presentación breve alrededor de rutas y mensajes
Abre con el cambio concreto: «Trasladar las nuevas reservas web al portal sustituto; resolver por separado las rutas de API y registros». Continúa con la tabla de alcance y las tres rutas. Así se pueden discutir las consecuencias antes de ver el calendario.
Usa la parte central para los hitos propuestos y un aviso representativo. Deja los otros dos en un anexo o documento adjunto para mantener legible la reunión principal. La última diapositiva debe nombrar la decisión solicitada, quién tiene autoridad para tomarla y qué cuestiones siguen fuera de ella.
En Word, coloca cada ruta bajo su propio título. Incluye la tabla de alcance, los avisos aprobados y el estado de cada hito. Al preparar las diapositivas, pide que las tres rutas permanezcan separadas y que las fechas sin resolver sigan así. Evita pedir a la herramienta que invente un calendario de migración a partir del nombre de un producto.
Para un programa más amplio, un plan de comunicación con las partes interesadas puede organizar público, canal y responsable de cada aviso. La presentación de retirada aporta el cambio concreto que debe explicar cada mensaje.
Explica quién ayuda cuando se detiene la ruta antigua
El último día del portal antiguo no es necesariamente el último día de transición. Alguien puede llegar desde un marcador guardado, preguntar por una reserva antigua o descubrir una integración ausente del inventario. Da al equipo receptor de soporte una ruta clara para esos casos.
En el ejemplo, la ayuda web atiende el acceso al sustituto, el contacto técnico resuelve las integraciones y el contacto de registros atiende solicitudes de recuperación. Indica qué ruta se responsabiliza de cada petición y qué información debe acompañarla. Un buzón compartido sin responsabilidades claras obliga a repetir la historia.
Termina la reunión registrando por separado el alcance aprobado y las decisiones pendientes. Una buena presentación permite entender el siguiente paso y deja al equipo en condiciones de responder «¿Qué pasa con mi trabajo?» sin inventar una respuesta.
