Para contratar un portal de clientes destinado a España y Portugal, define recorridos completos en los idiomas necesarios, no solamente páginas traducidas. El acceso, los mensajes de error, los documentos, las notificaciones y la atención posterior forman parte del producto. El presupuesto debe aclarar quién adapta cada elemento y cómo se verifica el resultado.
Este planteamiento sirve para trabajar con un proveedor local o un equipo remoto. No presupone que todos los usuarios de un país prefieran el mismo idioma. Investiga a tus clientes y decide qué variantes lingüísticas necesita el servicio. Una interfaz en español y otra en portugués pueden compartir procesos, pero requieren revisión de personas que comprendan su uso real.
Dibuja el recorrido que quieres digitalizar
Empieza con una tarea concreta: consultar un pedido, solicitar asistencia o descargar documentación. Identifica cómo la realiza hoy el cliente y dónde interviene el personal interno. Anota sistemas, documentos y decisiones, incluyendo los pasos que todavía se resuelven por correo.
Después describe la tarea desde el punto de vista del usuario. ¿Qué información necesita para entrar? ¿Cómo identifica su pedido? ¿Qué sucede si los datos no coinciden? ¿Puede terminar la solicitud sin llamar? Estas preguntas permiten valorar si el portal resuelve un problema o simplemente añade otra pantalla al proceso existente.
Nuestro artículo sobre el coste del software a medida ayuda a entender los factores de presupuesto. Para pedir ofertas comparables, conviene resolver primero qué recorrido entra en la primera entrega y qué queda fuera.
Separa idioma, mercado y datos del cliente
El idioma elegido no debe determinar automáticamente todos los datos comerciales. Un cliente puede preferir español y tener una dirección de entrega portuguesa. Otro puede trabajar en inglés aunque su empresa esté en España. Define estas preferencias como decisiones distintas cuando el negocio lo necesite.
Las recomendaciones de internacionalización del W3C incluyen declarar el idioma y admitir formatos locales en formularios. Para tu proyecto, concreta cómo se capturan y muestran nombres, direcciones, fechas y cantidades. No impongas reglas de validación basadas únicamente en los primeros ejemplos que el equipo tenga disponibles.
- ▸Acuerda los idiomas de interfaz, comunicaciones y soporte.
- ▸Define cómo se guarda y cambia la preferencia del usuario.
- ▸Identifica los datos que dependen de la cuenta comercial, no del idioma.
- ▸Prepara ejemplos representativos para formularios y documentos.
- ▸Decide qué ocurre cuando falta una traducción aprobada.
Incluye los mensajes que aparecen cuando algo falla
Una demostración suele mostrar el recorrido correcto con textos breves. Pide también una sesión caducada, un archivo rechazado, una búsqueda sin resultados y una respuesta lenta del sistema central. Los mensajes deben explicar qué ocurrió y qué puede hacer el cliente.
Evita construir frases a partir de fragmentos cuya combinación solamente funciona en un idioma. Entrega a los revisores el contexto: pantalla, acción, límite de espacio y significado. Una traducción aislada de “pendiente” puede ser ambigua si unas veces describe un pago y otras una aprobación interna.
Comprueba asimismo los correos y documentos descargables. Un portal que cambia de idioma pero envía confirmaciones incomprensibles sigue dejando al usuario con una tarea incompleta. El responsable de aprobar esos contenidos debe formar parte del calendario de entrega.
Ejemplo: un portal de pedidos y devoluciones
Imagina una empresa que permite a sus clientes en España y Portugal consultar pedidos y solicitar devoluciones. Es un escenario ilustrativo, no una referencia de cliente. El sistema de gestión mantiene el estado del pedido; el portal presenta la información y recoge una solicitud.
El proveedor debe explicar qué ocurre si la devolución llega mientras el pedido cambia de estado. La pantalla no puede prometer una aprobación que el sistema central todavía no ha confirmado. Define un estado intermedio comprensible y una forma de continuar la consulta sin repetir la solicitud.
En las pruebas, un usuario inicia la solicitud en portugués, cambia a español y vuelve a entrar al día siguiente. El pedido y la solicitud deben conservar su identidad. Cambiar el idioma no debería crear otro registro ni modificar una decisión comercial. El equipo de atención debe poder encontrar el caso mediante un identificador estable.
Presupuesta integración y operación por separado
Pide una lista de sistemas conectados, permisos necesarios y entornos de prueba. Aclara quién concede acceso y quién responde cuando una interfaz cambia. Si el proveedor necesita una licencia adicional del sistema de gestión, debe aparecer como dependencia del proyecto.
Los datos del portal también necesitan reglas de acceso. Un contacto no debe ver información de otra empresa por conocer un identificador. El estándar de verificación de seguridad de aplicaciones de OWASP puede servir para acordar requisitos comprobables; hay que seleccionar el alcance y la versión relevantes, no limitarse a mencionar el nombre del estándar.
Incluye la entrega de documentación y una práctica de resolución de incidencias. El equipo receptor debe saber dónde comprobar un fallo de sincronización, cómo escalarlo y qué información puede comunicar al cliente.
Acepta el portal con pruebas por recorrido
Selecciona recorridos esenciales y ejecútalos en cada idioma comprometido. Revisa navegación, errores, confirmaciones y documentos. Comprueba también el uso con teclado y los ajustes de tamaño de texto dentro del alcance de accesibilidad acordado.
Registra la versión probada, los resultados y las limitaciones conocidas. Si falta una traducción o una integración sigue simulada, indícalo expresamente. No presentes como completo un recorrido cuya última etapa depende de un trabajo pendiente.
Tras el lanzamiento, asigna responsables para los cambios editoriales. Una nueva opción del producto puede requerir instrucciones, mensajes y soporte actualizados. Incluye esa revisión en la entrega de cada funcionalidad para evitar que los idiomas diverjan con el tiempo.
Prepara una solicitud de propuesta concreta
Envía al proveedor tus recorridos prioritarios, idiomas requeridos, sistemas existentes y ejemplos anonimizados de documentos. Identifica a quienes aprobarán los procesos y los textos. Puedes comparar las respuestas mediante nuestra guía de evaluación de proveedores de software en Europa, disponible en inglés.
TuniCyberLabs ofrece desarrollo de software e integraciones a medida. Solicita una propuesta para tu portal de clientes con ese contexto. Así será posible delimitar una primera entrega útil y la evidencia necesaria para aceptarla.