Saltar al contenido

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étodoPrioridadNota
Tarjeta de crédito/débitoAltaCheckout integrado, no redirección
PSE / Transferencia bancariaAltaDominante en LATAM
Billeteras digitalesMediaNequi, Daviplata, Mercado Pago, etc.
Pago en efectivo (código)AltaGenerar código para pagar en puntos autorizados
Débito automáticoMediaSuscripción con control del usuario
Botón de pago embebidoAltaEvitar 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

CapaContenidoFuente
Estado actualFallas activas, cortes en cursoSCADA / sistema de monitoreo
Mantenimiento programadoCortes planificados con anticipaciónPlanificación técnica
Historial de fallasFrecuencia de interrupciones por zona (últimos 12 meses)Base de datos de reclamos
Tiempo promedio de respuestaCuánto tarda la empresa en resolver por zonaMétricas internas
Calidad del servicioIndicadores de continuidad y calidadReportes 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:

  1. Reportar cortes y saber cuándo volverá la luz
  2. Pagar factura
  3. Entender variaciones en el consumo
  4. 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:

  1. Calidad del agua (¿es potable? ¿hay contaminación?)
  2. Cortes por mantenimiento
  3. Detección de fugas en la red domiciliaria
  4. 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:

  1. ¿Cuándo llega el próximo vehículo?
  2. ¿Cuánto cuesta el viaje y cómo pago?
  3. ¿Cuál es la ruta que necesito?
  4. 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:

  1. Estado de la conexión (¿está funcionando?)
  2. Velocidad real vs. contratada
  3. Facturación y cobros adicionales
  4. Cambio de plan
  5. 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ísticaPWAApp Nativa
Costo de desarrolloUn solo código baseiOS + Android = 2x
ActualizaciónInstantáneaRequiere descarga del usuario
DescubrimientoLink directo, sin storeRequiere aprobación de tienda
Notificaciones pushSí (Android, limitado en iOS)Sí
Acceso offlineSí (Service Workers)Sí
Uso de cámara/GPSSíSí
Barrera de adopciónMuy bajaAlta (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 contenidoResponsableCiclo de revisiónPolítica de eliminación
Datos de tarifasGerencia comercialMensual (o al cambio)Versionar, no eliminar
Comunicados de prensaComunicacionesSin revisiónArchivar después de 90 días
Formularios y trámitesAtención al usuarioTrimestralEliminar obsoletos inmediatamente
Marco legalJurídicoSemestralVersionar, mantener vigentes
FAQ / Centro de ayudaSoporte digitalMensualActualizar según consultas reales
Datos abiertosTecnologíaAl actualizarseMantener 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étricaMetaPor qué importa
Tasa de autogestión digital>70% de trámites realizados sin intervención humanaReduce costos operativos, mejora satisfacción
Tiempo promedio de resolución de trámite online<5 minutos para pagos, <10 minutos para reclamosEficiencia 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>30Percepción de calidad

13.2 Métricas de transparencia

MétricaMetaPor qué importa
% de información actualizada>98% del contenido con fecha de revisión <90 díasConfianza
Tiempo de publicación de cortes programados>48 horas antes del eventoRespeto al usuario
Disponibilidad del mapa de servicio>99.5% uptimeHerramienta crítica
Descargas de datos abiertosCrecimiento trimestralUso real de la transparencia

13.3 Métricas de eficiencia comercial

MétricaMetaPor qué importa
Mora en facturas pagables onlineReducción >20% vs. solo presencialImpacto en recaudación
Costo por transacción digital vs. presencialDigital <10% del costo presencialJustificación de inversión
Adopción de débito automático vía webCrecimiento mensualPrevisibilidad de ingresos
Reducción de llamadas al call center>30% en 12 mesesDescongestió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.