Sistemas de facturación para ISP: de qué se componen

El abonado solo ve una línea de la facturación: «se cobrará tanto tal día». Por dentro es el sistema más crítico del operador: deja entrar a la gente en la red, mide el consumo, cuenta el dinero y responde ante contabilidad por cada céntimo. Un operador sobrevive a la caída de su web, pero un fallo de facturación significa que miles de abonados se quedan sin red o la usan gratis. Veamos de qué se compone este sistema, conocido en el sector como sistema automatizado de facturación.

El recorrido del abonado por la facturación

Cuando el router del abonado establece la conexión, el equipo del operador pregunta a la facturación si debe dejarlo entrar y a qué velocidad. El lenguaje clásico de este diálogo es RADIUS, y la respuesta depende del saldo y el plan. Luego la red envía contadores: cuántos bytes pasaron, cuánto duró la sesión. La facturación los convierte en cargos y cierra el periodo en la fecha de cobro. Un pago desde el área del cliente va en sentido inverso: dinero abonado, bloqueo retirado, velocidad restablecida, todo sin intervención humana.

Módulos de un sistema moderno

Alrededor del núcleo suelen vivir bloques afines: inventario técnico de cables y puertos, avisos de cobro, integración con mapas de cobertura. Cuanto mayor es el operador, más se parece la facturación a un kit en el que cada módulo se puede sustituir.

En caja, SaaS o desarrollo propio

Las redes pequeñas empiezan con sistemas en caja: lo instalas en tu servidor, das de alta los planes y a trabajar. La ventaja es el control y el precio único; el inconveniente, que actualizaciones y copias de seguridad corren de tu cuenta. Los sistemas en la nube se encargan de la operación a cambio de una cuota por cuenta: para una red de unos miles de abonados suele salir más barato que el sueldo de un administrador. El desarrollo propio conviene a operadores con un modelo no estándar: operadores virtuales, proveedores con tarificación diaria, servicios en los que la facturación es el producto. Es el camino más caro, sin los límites de una arquitectura ajena.

En qué fijarse al elegir

• Compatibilidad con tus equipos. La autorización y la recogida de contadores deben funcionar con tus modelos concretos de switches y BRAS, no «en general».
• Rapidez del bloqueo. Cuánto pasa entre el saldo cero y el corte real: las horas de diferencia son tráfico regalado.
• Recálculos. Cambio de plan con fecha retroactiva, devoluciones, pago prometido: en estos escenarios fallan más los sistemas en caja.
• API abierta. El área del cliente, el sitio y la app móvil vivirán más si se construyen sobre una API en vez de dentro de una plantilla ajena.
• Margen de carga. Un sistema ágil con mil abonados puede pararse con cincuenta mil el día del cobro masivo.

La migración es un gasto aparte. Dejar un sistema antiguo arrastra el historial de saldos, los periodos abiertos y los pagos prometidos. Un buen contratista empieza por inventariar estos cabos sueltos; uno malo, por enseñar un panel bonito. Planifica que los dos sistemas funcionen en paralelo al menos durante un periodo de facturación: cotejar los cargos con abonados reales descubre lo que ninguna prueba mostrará.

Errores habituales de implantación

• Facturación después de la red. Primero se construye la red y luego se añade la facturación. Debe ser al revés: el diseño de autorización y registro dicta la elección de equipos.
• Planes «como los del vecino». El sistema admite planes flexibles, pero se introducen tres líneas. Después, cada promoción se convierte en recálculos manuales.
• Un servidor para todo. Base de datos, RADIUS y área del cliente en una sola máquina funcionan hasta el primer día de cobro masivo. Separa al menos la base con antelación.
• Sin entorno de pruebas. Las actualizaciones van directas a producción, y el primer error de tarificación cuesta más que un banco de pruebas en toda su vida.
• Copias sin prueba de restauración. Se hacen copias durante años y la primera restauración se intenta en plena avería. Haz un simulacro de restauración cada trimestre.

El denominador común de estos errores es ver la facturación como un programa, cuando es un proceso. El dinero de los abonados pasa por ella sin parar, así que trátala como una caja registradora y no como un sitio web.

Si eliges un sistema para una red en crecimiento, mira más allá de la lista de funciones y hazte dos preguntas: cómo sobrevive al día de cobro y qué tan fácil es sacar los datos al migrar. Lo demás se puede añadir, pero estas dos propiedades las fija la arquitectura. Sobre la infraestructura relacionada escribimos aparte: el repaso de los tipos de servidores en la red te ayuda a ver dónde encaja la facturación en este panorama.