Lógica de Servicio, Transparencia y Eficiencia Comercial
I. EL PROBLEMA FUNDAMENTAL
Las empresas de servicios públicos operan bajo una paradoja única: el usuario no los eligió. No hay un funnel de adquisición, no hay un momento de «descubrimiento de marca». El ciudadano nace, se muda o simplemente existe en un territorio, y ya es cliente. Esta realidad cambia absolutamente todo el enfoque de diseño.
Mientras un e-commerce compite por la atención, una empresa eléctrica, de agua o telecomunicaciones ya tiene la atención cautiva — pero también tiene la obligación moral y legal de no abusar de esa posición. El sitio web no es un canal de venta. Es una interfaz de gobernanza cotidiana entre una entidad de derecho público (o concesionaria de un servicio esencial) y millones de personas que dependen de ella para vivir con dignidad.
El diseño, entonces, no puede pensarse como marketing. Debe pensarse como arquitectura de servicio público digital.
II. PRINCIPIOS RECTORES DEL DISEÑO
1. Servicio primero, institución después
El error más común en los sitios de empresas públicas es abrir con la misión institucional, el organigrama, la foto del directorio o la historia de la fundación. Al usuario no le interesa. Lo que necesita resolver es urgente, concreto y repetitivo:
- ¿Cuánto debo?
- ¿Cuándo vence mi factura?
- ¿Por qué me cortaron el servicio?
- ¿Cómo registro un reclamo?
- ¿Dónde está el punto de atención más cercano?
Principio: La pantalla principal debe resolver antes de informar. El contenido institucional existe, pero se ubica en una capa secundaria accesible, no en la primera vista.
2. Transparencia como diseño, no como declaración
Muchos sitios dicen «somos transparentes» y enlazan a un PDF de 200 páginas con estados financieros. Eso no es transparencia funcional. La transparencia en diseño significa:
- Ver en tiempo real el estado de un reclamo.
- Saber antes de preguntar cuándo corte programado habrá en tu zona.
- Entender sin formación técnica cómo se compone tu factura.
- Comparar sin esfuerzo tarifas, planes y opciones.
La transparencia es una experiencia, no una política publicada.
3. Eficiencia comercial como reducción de fricción
«Eficiencia comercial» en este contexto no significa vender más, sino:
- Reducir la carga operativa del call center al trasladar trámites al canal digital.
- Disminuir la mora facilitando el pago en línea.
- Incrementar la adopción de canales digitales con experiencias que superen al teléfono y la cola presencial.
- Fidelizar a través de la confianza, no a través de la dependencia forzada.
III. ARQUITECTURA DE INFORMACIÓN
La estructura de navegación debe responder a tareas, no a departamentos internos. Esto es crucial porque las empresas públicas tienden a organizar sus sitios según su estructura organizacional (Dirección Comercial, Dirección Técnica, Gerencia de Recursos Humanos), lo cual es irrelevante para el usuario.
Navegación principal propuesta:

Desglose funcional:
INICIO
- Estado del servicio en tu zona (mapa interactivo)
- Alertas activas (cortes, emergencias, mantenimiento)
- Accesos rápidos a las 4 tareas más frecuentes
- Últimas actualizaciones / comunicados relevantes
MI CUENTA (requiere autenticación)
- Dashboard de consumo (gráfica de últimos 12 meses)
- Estado de cuenta actual
- Historial de facturas
- Historial de pagos
- Reclamos activos y resueltos
- Datos del contrato y titular
- Configuración de notificaciones
- Delegación de acceso (para propietarios con múltiples inmuebles)
PAGAR
- Pago de factura actual (integración con múltiples medios de pago)
- Pago de deuda acumulada
- Planes de pago
- Program débito automático
- Descargar comprobantes
- Verificar pagos no registrados
REPORTAR
- Reportar falta de servicio
- Reportar avería visible (cable caído, fuga, poste dañado)
- Reportar error en facturación
- Reportar fraude o manipulación de medidor
- Solicitud de nuevo servicio
- Solicitud de cambio de titular
- Reclamo general (con categoría guiada)
CORTES Y MANTENIMIENTO
- Mapa de cortes programados
- Mapa de cortes no programados (en curso)
- Tiempo estimado de restablecimiento
- Suscripción a alertas por zona
- Historial de cortes en tu zona
AYUDA
- Centro de ayuda / FAQ contextual
- Chatbot de primer nivel
- Canales de contacto (teléfono, WhatsApp, presencial)
- Horarios y sedes (con mapa y tiempos de espera estimados)
- Guías y tutoriales
- Glosario de términos de facturación
SOBRE LA EMPRESA
- Misión, visión, valores
- Directorio y organigrama
- Memoria anual y estados financieros (en formatos accesibles)
- Datos abiertos
- Portal de transparencia
- Convocatorias y licitaciones
- Trabaja con nosotros
- Marco regulatorio
IV. DISEÑO DEL MÓDULO DE FACTURACIÓN
La factura es el punto de contacto más frecuente y más frustrante. Aquí se concentra la mayor oportunidad de mejora.
4.1 Comprensión de la factura
Una factura de servicios públicos típicamente tiene entre 15 y 30 líneas de conceptos con nombres crípticos: «cargo por disponibilidad», «contribución a la inversión», «IVA sobre el cargo fijo», «ajuste por inflación tarifaria». El usuario promedio no entiende qué paga ni por qué.
Solución de diseño: Factura visual interactiva

Elementos clave:
- Desglose visual con barras proporcionales, no solo tablas numéricas.
- Comparación temporal (este mes vs. anterior) con interpretación automática del cambio.
- Comparación social (tu consumo vs. el promedio de zona) — un estímulo conductual poderoso que incentiva la eficiencia energética sin imponer.
- Lenguaje traducido: cada línea técnica tiene un tooltip o descripción en lenguaje cotidiano. «Contribución a la inversión» se explica como «Parte de tu pago que financia el mantenimiento y mejora de la red eléctrica de tu zona».
4.2 Historial y tendencias

- Gráficas interactivas con tooltips.
- Anotaciones contextuales automáticas (picos explicados).
- Proyección de próximo mes basada en tendencia.
- Sugerencias de ahorro personalizadas según patrón de consumo.
4.3 Pagos
Principio: Nunca más de 3 clics entre «quiero pagar» y «pago confirmado».
Flujo óptimo:
INGRESO → VER FACTURA → [PAGAR] → SELECCIONAR MÉTODO → CONFIRMACIÓN → COMPROBANTE
1 2 3 4 5
Métodos de pago que deben soportarse:
| Método | Prioridad | Nota |
|---|---|---|
| Tarjeta de crédito/débito | Alta | Checkout integrado, no redirección |
| PSE / Transferencia bancaria | Alta | Dominante en LATAM |
| Billeteras digitales | Media | Nequi, Daviplata, Mercado Pago, etc. |
| Pago en efectivo (código) | Alta | Generar código para pagar en puntos autorizados |
| Débito automático | Media | Suscripción con control del usuario |
| Botón de pago embebido | Alta | Evitar redirecciones a portales bancarios genéricos |
Características críticas:
- Reconocimiento inmediato del pago: el usuario debe ver reflejado el pago en menos de 60 segundos en su cuenta. Si hay demora por conciliación bancaria, mostrar un estado «Pago registrado — verificación en curso».
- Comprobante descargable y enviável: PDF + envío automático por email.
- Pago parcial: permitir abonos cuando el usuario no puede pagar el total, mostrando el impacto (saldo remanente, fecha límite para evitar recargos).
- Alertas de vencimiento: push, SMS y email con días de anticipación configurables.
V. DISEÑO DEL MÓDULO DE RECLAMOS Y REPORTES
Este es probablemente el módulo más crítico para la percepción de la empresa. Un reclamo mal gestionado destruye más confianza que diez facturas mal diseñadas.
5.1 Principios del sistema de reclamos
Principio 1: Nunca pedir información que ya se tiene.
Si el usuario está logueado, el sistema ya sabe su dirección, su contrato, su medidor, su historial. El formulario de reclamo debe venir prellenado.
Principio 2: Categorizar con el usuario, no contra él.
Los formularios de reclamo de empresas públicas típicamente obligan al usuario a elegir entre categorías técnicas que no entiende: «Corte programado / Corte no programado / Falla en acometida / Falla en transformador». El usuario solo sabe: «No tengo luz».
Solución: Árbol de decisión guiado por lenguaje natural.

Principio 3: Dar respuesta inmediata, aunque no sea la solución.
El error más grave: «Su reclamo ha sido registrado. Nos pondremos en contacto.» Sin número, sin plazo, sin expectativa. Esto genera ansiedad y llamadas al call center.
Flujo de respuesta correcto:
RECLAMO REGISTRADO
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Número de gestión: RPT-2026-0047823
Categoría: Corte de servicio — zona residencial
Prioridad: Alta
ESTADO ACTUAL: En revisión
PRÓXIMOS PASOS:
1. Un técnico será asignado dentro de 2 horas
2. Tiempo estimado de solución: 4-6 horas
3. Te notificaremos por SMS cuando se restablezca
¿No se resuelve en el plazo indicado?
[ESCALAR RECLAMO]
SEGUIR EN TIEMPO REAL →
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.2 Seguimiento de reclamos
La pantalla de seguimiento debe funcionar como un tracker de envío (piensa en Rastreo de Correos o seguimiento de pedido de Amazon), no como una tabla de base de datos.

5.3 Escalamiento y garantías
El sistema debe incluir:
- Escalamiento automático: si el plazo de respuesta se cumple sin resolución, el reclamo sube de nivel automáticamente y se notifica al usuario.
- Escalamiento manual: el usuario puede escalar en cualquier momento si siente que el proceso no avanza.
- Registro imborrable: todo reclamo queda en el historial del usuario, con timestamps y responsables. Esto protege al usuario y a la empresa.
- Encuesta de satisfacción post-resolución: breve, opcional, pero presente. «¿Se resolvió tu problema? Sí / No / Parcialmente». Si es «No» o «Parcialmente», se reabre el caso.
VI. TRANSPARENCIA OPERATIVA EN TIEMPO REAL
6.1 Mapa de estado del servicio
Este es el componente estrella de un sitio de servicios públicos bien diseñado. Un mapa interactivo que muestre:

Capas del mapa
| Capa | Contenido | Fuente |
|---|---|---|
| Estado actual | Fallas activas, cortes en curso | SCADA / sistema de monitoreo |
| Mantenimiento programado | Cortes planificados con anticipación | Planificación técnica |
| Historial de fallas | Frecuencia de interrupciones por zona (últimos 12 meses) | Base de datos de reclamos |
| Tiempo promedio de respuesta | Cuánto tarda la empresa en resolver por zona | Métricas internas |
| Calidad del servicio | Indicadores de continuidad y calidad | Reportes regulatorios |
6.2 Dashboard de indicadores públicos
Las empresas públicas están obligadas a reportar indicadores a sus reguladores. El sitio debe exponerlos en formato comprensible:

VII. DISEÑO PARA DIFERENTES TIPOS DE SERVICIO
7.1 Empresa Eléctrica
Prioridades del usuario:
- Reportar cortes y saber cuándo volverá la luz
- Pagar factura
- Entender variaciones en el consumo
- Solicitar conexión o reconexión
Funcionalidades específicas:
- Simulador de ahorro: «Si reemplazas tu refrigerador por uno eficiente clase A, ahorrarías $X al año».
- Alertas de consumo anómalo: «Tu consumo de hoy triplica tu promedio habitual. ¿Querés verificar?»
- Programa de interrupciones voluntarias: para usuarios que desean que se les corte el servicio en horarios pico a cambio de descuentos.
- Tiempo real de restablecimiento: integración con sistemas SCADA para mostrar estimaciones actualizadas.
7.2 Empresa de Agua y Saneamiento
Prioridades del usuario:
- Calidad del agua (¿es potable? ¿hay contaminación?)
- Cortes por mantenimiento
- Detección de fugas en la red domiciliaria
- Facturación por consumo
Funcionalidades específicas:
- Panel de calidad del agua: turbidez, cloro residual, pH — actualizado diariamente por zona.
- Calculadora de fugas: «Si tu consumo nocturno (2-5 AM) es mayor a X litros, podés tener una fuga. Así se verifica.»
- Mapa de obras de saneamiento: qué proyectos están en curso, cuándo beneficiarán a cada zona.
- Consumo vs. ración: en ciudades con restricciones hídricas, mostrar cuota asignada y consumo real.
7.3 Empresa de Transporte Público
Prioridades del usuario:
- ¿Cuándo llega el próximo vehículo?
- ¿Cuánto cuesta el viaje y cómo pago?
- ¿Cuál es la ruta que necesito?
- Reportar irregularidades
Funcionalidades específicas:
- Tiempo real de flota: mapa con vehículos en movimiento y tiempos de llegada a cada parada.
- Planificador de viajes: origen → destino con opciones multimodales, tiempos y costos.
- Recarga de tarjeta inteligente: en línea, con historial de viajes.
- Reporte de conductores: conducción peligrosa, acoso, incumplimiento de rutas.
- Accesibilidad: indicar qué unidades tienen rampa, piso bajo, espacio para silla de ruedas.
7.4 Empresa de Telecomunicaciones
Prioridades del usuario:
- Estado de la conexión (¿está funcionando?)
- Velocidad real vs. contratada
- Facturación y cobros adicionales
- Cambio de plan
- Soporte técnico
Funcionalidades específicas:
- Test de velocidad integrado con historial y comparativa con lo contratado.
- Mapa de cobertura con calidad real (no solo marketing).
- Diagnóstico remoto: el usuario describe el problema y el sistema ejecuta pruebas automáticas en su línea antes de generar un técnico.
- Autogestión de plan: cambio de plan, activación/desactivación de servicios adicionales, sin necesidad de llamar.
- Desglose de consumos: datos, minutos, SMS, servicios adicionales — con gráficos y alertas de límite.
VIII. DISEÑO DE LA EXPERIENCIA MÓVIL
Las empresas públicas en Latinoamérica atienden poblaciones donde el smartphone es el único dispositivo con acceso a internet para un porcentaje significativo de usuarios. El diseño móvil no es secundario. Es primario.
8.1 Principios mobile-first para servicios públicos
- Carga en conexiones lentas: la página principal no debe superar 500KB. Usar lazy loading agresivo. Las imágenes del mapa se cargan bajo demanda.
- Offline para lo esencial: los datos de la cuenta del usuario (número de contrato, último consumo, estado de reclamos) deben cachearse localmente. El usuario puede necesitar consultarlos sin conectividad (irónico, pero real: si se cortó la luz, probablemente también se cortó el router).
- Navegación por gestos: swipe entre facturas, pull-to-refresh para estado de reclamos.
- Touch targets generosos: mínimo 48x48px. Los adultos mayores son un segmento demográfico clave para servicios públicos.
- Contraste alto: no todos los usuarios ven la pantalla en condiciones ideales (interiores oscuros, pantalla rota, luz solar directa).
8.2 Progressive Web App (PWA)
Para la mayoría de empresas públicas, una PWA es más adecuada que una app nativa:
| Característica | PWA | App Nativa |
|---|---|---|
| Costo de desarrollo | Un solo código base | iOS + Android = 2x |
| Actualización | Instantánea | Requiere descarga del usuario |
| Descubrimiento | Link directo, sin store | Requiere aprobación de tienda |
| Notificaciones push | Sí (Android, limitado en iOS) | Sí |
| Acceso offline | Sí (Service Workers) | Sí |
| Uso de cámara/GPS | Sí | Sí |
| Barrera de adopción | Muy baja | Alta (descargar, instalar, crear cuenta) |
Excepción: Si la empresa tiene los recursos y la base de usuarios justifica una app nativa, puede ofrecer ambas. Pero nunca exigir la app nativa para funcionalidades esenciales.
IX. ACCESIBILIDAD UNIVERSAL
Los servicios públicos atienden a toda la población, incluyendo:
- Personas con discapacidad visual (ceguera total, baja visión, daltonismo)
- Personas con discapacidad auditiva (sordera, hipoacusia)
- Personas con discapacidad motora (parálisis, temblores, uso de un solo brazo)
- Personas con discapacidad cognitiva (dificultades de lectura, comprensión)
- Adultos mayores
- Personas con baja alfabetización digital
- Personas en zonas con conectividad precaria
9.1 Estándares técnicos
- WCAG 2.1 nivel AA como mínimo. AAA como objetivo.
- Navegación completa por teclado.
- Labels semánticos en todos los formularios.
- Contraste mínimo de 4.5:1 para texto normal, 3:1 para texto grande.
- Texto resizable hasta 200% sin pérdida de funcionalidad.
- Transcripciones y subtítulos en todo contenido de video.
- Idioma claro: lectura nivel secundario (grado 8-10).
9.2 Lenguaje claro
Esto es particularmente importante en servicios públicos. Ejemplo de transformación:
Antes:
«El usuario podrá solicitar la reconexión del servicio una vez se haya subsanado la causal que motivó la suspensión del suministro, previo pago de los derechos de reconexión establecidos en la resolución tarifaria vigente.»
Después:
«Si te cortaron el servicio, podés solicitar la reconconexión después de resolver el motivo del corte. Tenés que pagar el costo de reconexión (consultá el monto actual aquí).»
X. SEGURIDAD Y PRIVILEGIO DE DATOS
Las empresas públicas manejan datos sensibles: direcciones exactas, identificación fiscal, patrones de consumo (que revelan hábitos de vida), historial de pagos (que revela situación económica).
10.1 Principios de seguridad
- Autenticación robusta: doble factor para acceso a datos de cuenta. El SMS como segundo factor es aceptable, la app autenticadora es preferible.
- Sesiones con timeout corto: 15 minutos de inactividad para cerrar sesión automáticamente.
- Visibilidad parcial de datos sensibles: mostrar solo los últimos 4 dígitos del documento de identidad, enmascarar datos bancarios.
- Registro de accesos: el usuario puede ver cuándo y desde dónde se accedió a su cuenta.
- Consentimiento explícito: antes de usar datos para análisis de consumo o recomendaciones, pedir permiso con explicación clara.
- Cumplimiento regulatorio: Ley de protección de datos local (LGPD en Brasil, LOPD en países hispanohablantes, GDPR si aplica).
10.2 Protección contra fraude
- Alertas de actividad sospechosa: «Se accedió a tu cuenta desde un dispositivo nuevo en una ubicación diferente».
- Verificación para cambios sensibles: cambio de titular, cambio de cuenta bancaria para débito automático requieren verificación adicional.
- Anti-phishing: comunicar claramente que la empresa nunca pedirá contraseñas por email o teléfono.
XI. INTEGRACIÓN CON ECOSISTEMA DIGITAL
11.1 WhatsApp Business API
En Latinoamérica, WhatsApp es el canal digital dominante. La empresa debe ofrecer:
- Consulta de saldo y última factura por WhatsApp.
- Envío automático de factura mensual.
- Recepción de reportes de falla (con geolocalización y foto).
- Estado de reclamo por mensaje.
- Notificación de cortes programados.
Importante: WhatsApp complementa al sitio web, no lo reemplaza. Funcionalidades complejas (cambio de plan, pago con múltiples opciones, gestión de múltiples contratos) siguen en el sitio web o la app.
11.2 Datos abiertos
Las empresas públicas deben publicar datos en formatos abiertos (CSV, JSON, API):
- Tarifas vigentes y su histórico.
- Mapas de red (georeferenciados).
- Indicadores de calidad del servicio.
- Consumo agregado por zona (anonimizado).
- Tiempos de respuesta a reclamos.
- Inversiones en infraestructura.
Esto no es solo transparencia: permite que terceros desarrollen herramientas complementarias (apps de consumo, comparadores de tarifas, mapas comunitarios de fallas).
11.3 API para integración de terceros
- API de consulta de deuda: para que bancos y billeteras digitales muestren la deuda y permitan pagar desde sus plataformas.
- API de estado del servicio: para que aplicaciones de hogar inteligente integren alertas de cortes.
- Webhooks de notificación: para que los usuarios técnicos (administradores de edificios, empresas grandes) reciban alertas programáticas.
XII. GOBERNANZA DEL CONTENIDO
12.1 Problema típico
Los sitios de empresas públicos acumulan contenido sin depurar: comunicados de prensa de 2014, formularios PDF obsoletos, normativas derogadas, enlaces rotos. El sitio se convierte en un vertedero documental.
12.2 Modelo de gobernanza
| Tipo de contenido | Responsable | Ciclo de revisión | Política de eliminación |
|---|---|---|---|
| Datos de tarifas | Gerencia comercial | Mensual (o al cambio) | Versionar, no eliminar |
| Comunicados de prensa | Comunicaciones | Sin revisión | Archivar después de 90 días |
| Formularios y trámites | Atención al usuario | Trimestral | Eliminar obsoletos inmediatamente |
| Marco legal | Jurídico | Semestral | Versionar, mantener vigentes |
| FAQ / Centro de ayuda | Soporte digital | Mensual | Actualizar según consultas reales |
| Datos abiertos | Tecnología | Al actualizarse | Mantener históricos |
12.3 Métricas de contenido
- Páginas con mayor tasa de rebote: probablemente no resuelven la consulta del usuario.
- Búsquedas internas sin resultado: el usuario busca algo que no existe o no encuentra.
- Formularios abandonados: fricción en el proceso.
- Tiempo en página de FAQ: si es muy alto, las respuestas no son claras.
- Contacto post-FAQ: si después de ver una FAQ el usuario llama al call center, la FAQ falló.
XIII. MÉTRICAS DE ÉXITO
Un sitio de servicios públicos se evalúa diferente a un e-commerce o un medio digital. Las métricas correctas son:
13.1 Métricas de servicio
| Métrica | Meta | Por qué importa |
|---|---|---|
| Tasa de autogestión digital | >70% de trámites realizados sin intervención humana | Reduce costos operativos, mejora satisfacción |
| Tiempo promedio de resolución de trámite online | <5 minutos para pagos, <10 minutos para reclamos | Eficiencia del usuario |
| Tasa de abandono en flujo de pago | <10% | Cada abandono = mora potencial |
| % de reclamos resueltos en plazo | >95% | Cumplimiento de servicio |
| NPS (Net Promoter Score) del canal digital | >30 | Percepción de calidad |
13.2 Métricas de transparencia
| Métrica | Meta | Por qué importa |
|---|---|---|
| % de información actualizada | >98% del contenido con fecha de revisión <90 días | Confianza |
| Tiempo de publicación de cortes programados | >48 horas antes del evento | Respeto al usuario |
| Disponibilidad del mapa de servicio | >99.5% uptime | Herramienta crítica |
| Descargas de datos abiertos | Crecimiento trimestral | Uso real de la transparencia |
13.3 Métricas de eficiencia comercial
| Métrica | Meta | Por qué importa |
|---|---|---|
| Mora en facturas pagables online | Reducción >20% vs. solo presencial | Impacto en recaudación |
| Costo por transacción digital vs. presencial | Digital <10% del costo presencial | Justificación de inversión |
| Adopción de débito automático vía web | Crecimiento mensual | Previsibilidad de ingresos |
| Reducción de llamadas al call center | >30% en 12 meses | Descongestión operativa |
XIV. ERRORES FATALES A EVITAR
1. PDF como único canal de información
Publicar la factura, los formularios y la información tarifaria exclusivamente en PDF es una barrera de acceso masiva. El PDF es un formato de archivo, no de lectura web.
2. Requerir presencia física para trámites digitables
Si un cambio de titular, una solicitud de plan de pago o un reclamo puede resolverse digitalmente, no obligar al usuario a ir a una oficina con carpeta y fotocopias.
3. Formularios sin persistencia
Si el usuario llena un formulario de 15 campos y ocurre un error, perder todo el contenido es inaceptable. Los formularios largos deben guardar borradores automáticamente.
4. Ignorar la estacionalidad
Las empresas eléctricas tienen picos de consulta en verano (aire acondicionado) e invierno (calefacción). Las de agua, en sequías. Las de telecomunicaciones, en fines de año. El sitio debe escalar su rendimiento y adaptar su contenido a la estacionalidad.
5. Diseñar solo para el ciudadano «ideal»
El usuario promedio no lee términos y condiciones, no sabe qué es un «kWh», no entiende la diferencia entre «cargo fijo» y «cargo variable». Diseñar para el usuario menos informado no perjudica al usuario más informado; diseñar solo para el informado excluye a la mayoría.
6. Tratar el sitio web como un proyecto y no como un producto
Lanzar el sitio y no actualizarlo durante 3 años es lo más común. Un sitio de servicios públicos necesita iteración continua: analítica, pruebas de usuario, actualización de contenido, parches de seguridad, mejoras de rendimiento.
XV. GOBERNANZA Y ÉTICA DIGITAL
15.1 Conflictos de interés en el diseño
La empresa de servicios públicos tiene un incentivo natural a:
- Hacer difícil la baja o el cambio de titular (retención forzada).
- Ocultar información comparativa de tarifas con competidores (cuando los hay).
- Minimizar la visibilidad de fallas e incumplimientos.
- Maximizar la fricción del proceso de reclamos para desincentivarlos.
El diseño ético exige resistir estos incentivos. Un sitio web que dificulta la baja es un sitio que genera desconfianza. Un sitio que oculta fallas es un sitio que cuando la falla es evidente (y lo será) pierde toda credibilidad.
15.2 Neutralidad algorítmica
Si el sitio incorpora recomendaciones (cambio de plan, sugerencias de ahorro), debe hacerlo de forma transparente:
- «Te recomendamos este plan porque tu consumo promedio es de X kWh/mes.»
- «Esta sugerencia no es pagada por terceros.»
- Permitir al usuario desactivar recomendaciones.
15.3 Inclusión lingüística
En países con población multilingüe (quechua, guaraní, lenguas indígenas, variantes regionales), ofrecer al menos las funcionalidades críticas en los idiomas principales del territorio de concesión.
XVI. HOJA DE RUTA DE IMPLEMENTACIÓN
Fase 1 — Fundamentos (Meses 1-3)
- Rediseño de la arquitectura de información
- Módulo de facturación y pagos
- Módulo de registro y seguimiento de reclamos
- Diseño responsive mobile-first
- Accesibilidad WCAG 2.1 AA
Fase 2 — Transparencia (Meses 4-6)
- Mapa de estado del servicio en tiempo real
- Dashboard de indicadores de calidad
- Portal de datos abiertos
- Centro de ayuda y FAQ dinámico
Fase 3 — Ecosistema (Meses 7-9)
- Integración con WhatsApp Business API
- API pública para terceros
- PWA con capacidades offline
- Notificaciones push y SMS
Fase 4 — Inteligencia (Meses 10-12)
- Analítica predictiva de consumo
- Chatbot con NLP para consultas complejas
- Personalización de contenido por perfil de usuario
- Simuladores y herramientas interactivas
Mejora continua (Permanente)
- Testing de usuario trimestral
- Análisis de métricas mensual
- Actualización de contenido según gobernanza
- Auditoría de accesibilidad semestral
- Escucha activa en redes y encuestas de satisfacción
XVII. CONCLUSIÓN
Diseñar un sitio web para una empresa pública de servicios no es un ejercicio de diseño web convencional. Es un ejercicio de diseño institucional digital. La interfaz es, para millones de personas, la cara más frecuente de su relación con una entidad que administra un bien esencial de su vida diaria.
La electricidad que ilumina su casa, el agua que beben sus hijos, el transporte que los lleva al trabajo, la conexión que los mantiene informados — todo eso pasa por una empresa que, en muchos casos, el usuario no puede elegir ni cambiar. Esa posición de monopolio natural impone una responsabilidad asimétrica: la empresa debe esforzarse el doble de lo que lo haría un competidor en un mercado libre, precisamente porque el usuario no puede irse.
El diseño del sitio web es la expresión más tangible de esa responsabilidad. Cada clic innecesario, cada formulario confuso, cada PDF impenetrable, cada reclamo sin respuesta es una pequeña traición al mandato de servicio público. Y cada experiencia fluida, cada dato transparente, cada problema resuelto en línea sin necesidad de hacer cola es una confirmación de que la tecnología, bien aplicada, puede hacer que las instituciones funcionen como deberían funcionar: para las personas que las sostienen.
