Un integrador de sistemas vende un proyecto. Define el alcance, lo construye, instala el hardware, entrega un dashboard y factura. Después sale a buscar el siguiente.
Ese modelo paga las cuentas. También pone un techo a cuánto puede crecer, porque vende, entrega y vuelve a empezar. Nada de lo que entregó el trimestre pasado le está pagando este trimestre. Sus ingresos dependen por completo del próximo contrato firmado, y el trabajo que ya hizo queda en la cuenta de un cliente sin aportar nada a sus libros.
Hay otra forma de hacerlo. En lugar de vender el proyecto y desentenderse, sigue entregando valor después de la instalación y cobra por ello todos los meses. La construcción pasa a ser la puerta de entrada, no el negocio completo. Este artículo trata sobre cómo dar ese giro: qué empaquetar en servicios continuos, los cambios contractuales y operativos que conlleva, por qué la retención se vuelve la cifra que importa, y cómo un equipo pequeño puede entregar servicios recurrentes sin montar un departamento.
Por qué el modelo de proyecto limita el crecimiento
Un proyecto puntual tiene un final limpio. Se cobra la factura y la relación se apaga hasta que el cliente necesita otra cosa. Quizá le llamen en dieciocho meses. Quizá no.
El problema es que cada proyecto parte de cero en costos. Hay que levantar infraestructura nueva, asumir un soporte nuevo, aprovisionar dispositivos nuevos. Reconstruye una versión del mismo montaje para cada cliente y lo factura una sola vez. No hay acumulación. Diez proyectos entregados son diez trabajos terminados, no diez fuentes de ingreso.
También vuelve su negocio frágil de una forma que es fácil ignorar cuando hay trabajo de sobra. Cuando las ventas bajan, los ingresos se cortan casi de inmediato, porque el trabajo entregado el año pasado hoy no genera nada. Siente cada hueco en el calendario.
Los servicios recurrentes cambian la forma de los ingresos. El cliente que le paga cada mes por mantener su despliegue en funcionamiento es un cliente que sigue pagando mientras el equipo funcione. Veinte de esos son una base sobre la que puede planificar.
Qué empaquetar en servicios continuos
El giro empieza con una pregunta: qué necesita el cliente después de que el sistema está en marcha y que estaría dispuesto a pagarle por gestionar? Más de lo que la gente cree.
El monitoreo es lo obvio. Alguien tiene que vigilar si los dispositivos están reportando, si las baterías se están agotando, si los datos se quedaron en silencio. El cliente no quiere hacerlo. Usted sí puede, y puede cobrar por ello.
El mantenimiento cubre el desgaste lento que tiene todo despliegue. Actualizaciones de firmware, reemplazo de sensores muertos, reajuste de umbrales de alerta a medida que cambia la operación del cliente, limpieza de las canalizaciones de datos. Sin alguien encima, un sistema que funciona se degrada hasta quedar a medias en uno o dos años.
El acceso a la plataforma es el núcleo recurrente. El cliente paga por los dashboards, la gestión de dispositivos, el almacenamiento y las alertas que sostienen su operación día a día. Eso no es un entregable puntual. Es un servicio que consume de forma continua, y es justo cobrarlo así.
Los niveles de soporte le permiten ajustar el precio a la necesidad. Un cliente pequeño quizá solo quiera soporte por correo en horario laboral. Un cliente que opera infraestructura crítica quiere un número de teléfono que alguien conteste a las dos de la madrugada. Venda eso como niveles distintos en lugar de una única promesa que no podrá cumplir a cualquier precio.
Los informes cierran el círculo. Un resumen mensual o trimestral que muestre el tiempo de actividad, los incidentes atendidos y las tendencias en los datos le recuerda al cliente por qué está pagando. También saca a la luz lo siguiente que necesita, y de ahí salen los ingresos por expansión.
No tiene que ofrecer todo esto de golpe. Elija los dos o tres que encajen con lo que sus clientes ya piden y construya a partir de ahí.
Los cambios en contratos y SLA que conlleva
Vender un proyecto y vender un servicio son compromisos distintos, y el papeleo tiene que reflejarlo.
Un contrato de proyecto tiene un alcance, un precio y una fecha de fin. Un contrato de servicio tiene un plazo, una cuota recurrente, un mecanismo de renovación y una descripción de lo que va a seguir haciendo. Ya no promete algo terminado. Promete un comportamiento continuo, y el cliente le exigirá que lo cumpla.
Ahí entran los acuerdos de nivel de servicio. Un SLA establece lo que el cliente puede esperar: objetivos de tiempo de actividad, en cuánto tiempo responde a un incidente, en cuánto lo resuelve y qué pasa si no lo cumple. Redactar uno le obliga a ser honesto sobre lo que realmente puede entregar. Prometa un 99,99 por ciento de tiempo de actividad sobre una infraestructura que no controla y será usted quien cargue con ese fallo cuando ocurra.
Este es el momento de tener cuidado con lo que se compromete frente a lo que su proveedor de plataforma se compromete con usted. Si revende una plataforma gestionada, su tiempo de actividad se apoya en el de ellos. El SLA que ofrece al cliente debe quedar dentro de las garantías que tiene del proveedor, nunca por encima.
La estructura de precios también cambia. Pase de una tarifa fija de proyecto a un cargo recurrente, normalmente mensual o anual, a menudo escalonado por nivel de soporte o por tamaño. Incorpore condiciones de renovación y una ruta clara para que el cliente crezca hacia un nivel superior a medida que suma sitios o dispositivos.
El músculo operativo que tiene que desarrollar
Aquí está la parte que asusta a los integradores, y conviene tomarla en serio. Los servicios recurrentes implican obligaciones recurrentes. El cliente espera que el sistema siga funcionando, y esa expectativa corre todos los días, no solo en la entrega.
El miedo es que esto signifique contratar un equipo de operaciones que no puede costear. No tiene por qué. El truco está en desarrollar el músculo a base de repetibilidad y herramientas, no de plantilla.
Estandarice lo que entrega. Si cada cliente recibe una construcción a medida ligeramente distinta, dar soporte a veinte son veinte trabajos diferentes. Si reciben variaciones de la misma solución estándar, dar soporte a veinte se parece más a dar soporte a uno con casos particulares. La uniformidad es lo que permite que un equipo pequeño lleve una cartera grande.
Automatice la vigilancia. No puede pagarle a una persona para que mire dashboards fijamente. Configure alertas que le avisen cuando algo va mal, para que su gente responda a las excepciones en lugar de vigilarlo todo a mano. La plataforma hace la vigilancia; su equipo hace las reparaciones.
Apóyese en la plataforma para la carga operativa pesada. El tiempo de actividad, el escalado, el almacenamiento y los parches de seguridad son trabajo a tiempo completo si la infraestructura es suya. Si opera sobre una plataforma gestionada, ese trabajo le corresponde al proveedor, y su equipo se mantiene centrado en la relación con el cliente y en la solución.
La retención se vuelve la cifra que importa
En el mundo de los proyectos, la métrica son las ventas cerradas. Cuántos contratos firmó, de qué tamaño. Una vez que pasa a servicios recurrentes, la métrica se invierte. El número que decide si el negocio crece es si sus clientes actuales siguen pagando.
Una base recurrente tiene fugas. Los clientes se van cuando el sistema deja de aportar valor, cuando el soporte se siente flojo o cuando nadie les recuerda lo que están recibiendo. Cada cliente que se marcha son ingresos que tiene que reponer antes de poder crecer, lo que significa que la fuga marca en silencio su techo.
Por eso los informes y los niveles de soporte importan más allá de lo que cobra por ellos. Son lo que mantiene a un cliente renovando. Un cliente que ve un informe mensual con los incidentes que detectó y el tiempo de actividad que sostuvo es un cliente que renueva sin pensarlo. Un cliente que no sabe nada de usted en un año es un cliente comparando precios en la renovación.
Vigile la retención como antes vigilaba su cartera de ventas. Es el indicador anticipado de si el modelo está funcionando.
Cómo fijar el precio y plantear el cambio a clientes existentes
Sus clientes actuales son el punto de partida más fácil, y el más incómodo, porque están acostumbrados a pagarle una sola vez.
Plantéelo como mantener el sistema en buen estado, no como un cargo nuevo por lo mismo. La versión honesta es: usted lo construyó, hoy funciona, y sin atención continua se va a degradar. El servicio lo mantiene operativo y mantiene a alguien responsable cuando deja de estarlo. La mayoría de los clientes entiende que el mantenimiento cuesta; simplemente nunca se lo ofrecieron como una opción clara.
Fije el precio en función del valor de tener el despliegue en marcha, no de las horas que dedica. Si la operación del cliente depende del sistema, una cuota mensual que garantice que sigue activo es barata frente al costo de que falle. Ancle la conversación ahí.
Empiece con un cliente de confianza. Ofrézcale un nivel de servicio, entréguelo bien y use lo que aprenda para afinar la propuesta antes de llevarla al resto.
Cómo lo entrega un equipo pequeño
La razón por la que esto solía ser difícil para los integradores es que los servicios recurrentes parecían exigir operar una plataforma, y operar una plataforma es un segundo negocio.
Una plataforma gestionada elimina eso. TagoIO le da dashboards, gestión de dispositivos, almacenamiento, alertas y APIs sobre la conectividad, con el tiempo de actividad, el escalado y la seguridad resueltos por usted. Está certificada en ISO 27001 y alineada con GDPR, lo que importa cuando empieza a comprometerse por escrito con clientes en cuanto a tiempo de actividad y datos. Su equipo entrega el servicio; la plataforma carga con el peso operativo por debajo.
TagoRUN va un paso más allá con marca blanca y reventa. Opera la plataforma bajo su propia marca, con su propio dominio, y cada cliente vive en su propio tenant. Vende el acceso a su plataforma de marca como el producto recurrente, fija sus propios precios y niveles, y gestiona a cada cliente desde un solo lugar. Eso es lo que hace que los servicios recurrentes sean entregables por un equipo pequeño: una plataforma, una consola, muchos tenants que pagan, sin una persona dedicada a cada uno.
La construcción sigue importando. Es cómo gana al cliente y demuestra la solución. Pero deja de ser el negocio completo y se convierte en el inicio de una relación que le paga cada mes que funciona.
Elija una solución repetible, empaquete los servicios alrededor de ella y ofrézcala a un cliente de confianza. El modelo se demuestra a sí mismo a partir de ahí.
