Cómo lograr que tu empresa apruebe el programa de lealtad: lo que pregunta cada área

Finanzas: cuánto cuesta y qué deuda genera

La primera pregunta de finanzas no es cuánto cuesta la plataforma: es cuánto vale lo que se promete. Cada punto que el programa entrega es una promesa de algo (un descuento, un producto, un premio) que la empresa tendrá que cumplir cuando el miembro lo pida. Mientras no se canjea, esa promesa sigue ahí, y en muchas empresas se registra como un pasivo. Cómo se contabiliza lo define el contador según las normas que aplique la empresa, pero la pregunta va a aparecer y conviene llevarla resuelta.

Lo que finanzas necesita ver es la cuenta completa, no solo la licencia. El costo del programa son cuatro cosas: la plataforma, los premios que se canjean, la operación (quién lo administra y cuántas horas le dedica) y lo que cuesta comunicarlo. Del otro lado va lo que se espera mover, y aquí conviene ser prudente: una hipótesis de cuánto puede crecer la frecuencia de compra o la retención en la audiencia del programa, escrita como hipótesis, con el método para medirla.

El argumento que más ordena la conversación es el del tope. Un programa bien diseñado tiene el costo atado a la actividad: si nadie compra, nadie acumula, y si nadie acumula, nadie canjea. Mostrar que el gasto en premios crece solo cuando crece lo que lo financia cambia la discusión de un gasto fijo a un costo variable.

Sistemas: quién lo integra y quién lo mantiene

El área de tecnología llega con otra pregunta, y es la más razonable de todas: ¿esto es un proyecto más que va a caer sobre un equipo que ya no se da abasto?

Ahí conviene separar dos caminos, porque la respuesta cambia mucho. Si el programa se desarrolla internamente, sistemas estimará la primera versión en semanas y tendrá razón para esa versión; lo que viene después (devoluciones, canjes que fallan a mitad de camino, vencimientos, niveles, auditoría de cada movimiento) es un producto que alguien tendrá que mantener para siempre. Si se integra un motor por API, el trabajo de sistemas se reduce a lo que ya conoce: avisarle al motor los eventos que el producto ya genera (un alta, una compra, una devolución, un objetivo cumplido), recibir las notificaciones de vuelta en un endpoint y diseñar las pantallas con la identidad de la marca.

Las preguntas técnicas que van a llegar son siempre parecidas: dónde corre, cómo se protegen los datos, qué pasa si el motor no responde y cómo se prueba antes de salir. En el caso de Loybox, el motor corre en Google Cloud, con cifrado en tránsito, acceso por roles y copias diarias; las notificaciones salen firmadas, con reintentos y en orden por miembro; y la integración se escribe contra un ambiente de prueba con credenciales propias. Lo importante para la aprobación no es el detalle, es que sistemas vea que hay respuesta para cada una antes de comprometer horas.

Legal: el reglamento y los datos

El área legal va a preguntar dos cosas, y ninguna es un trámite.

La primera es el reglamento del programa. Qué suma puntos y por qué, cuándo vencen, qué pasa con una devolución, qué pasa si el programa cambia o termina. Un programa sin términos y condiciones por escrito es una promesa abierta que cualquier miembro puede interpretar a su favor, y legal lo sabe. Llevar un borrador del reglamento a la primera reunión ahorra la segunda.

La segunda son los datos personales. El programa va a reunir información de personas (quién compró, qué, cuándo, cómo contactarla) y legal va a querer saber qué se guarda, para qué, quién lo ve y cómo se le responde a alguien que pide ver, corregir o borrar sus datos. También va a preguntar con qué consentimiento se le envían mensajes a cada miembro. Si la audiencia son empleados, aparece además la relación laboral: si los premios se parecen demasiado a una parte del sueldo, eso puede tener consecuencias laborales, y se habla con legal y con recursos humanos antes de diseñar la mecánica.

Atención al cliente: quién responde cuando faltan puntos

Es el área que menos se invita a la reunión y la que más sufre si el programa sale mal. Su pregunta es concreta: cuando alguien escriba diciendo que le faltan puntos, ¿cómo lo verifico y qué le respondo?

La respuesta necesita tres cosas. Un historial de movimientos por miembro, donde se vea de dónde salió cada punto y por qué se descontó. Una regla escrita para los casos que se repiten (la compra que no sumó porque todavía no se acreditó el pago, la devolución que restó, el canje que quedó pendiente). Y alguien con permiso para corregir un saldo cuando el error es de la empresa.

Si atención al cliente participa del diseño desde el principio, el programa sale con las respuestas listas. Si se entera el día del lanzamiento, el programa sale igual, pero los primeros reclamos los responde alguien que no sabe cómo funciona.

El área que lo impulsa: para quién es y cómo se sabe si funcionó

La propia área que impulsa el programa tiene que responder las dos preguntas que el resto de la empresa no puede responder por ella.

Para quién es. Un programa para todos los clientes, para el equipo de ventas o para la red de distribuidores son tres programas distintos, con mecánicas distintas. Con los clientes, lo que se premia es la compra y la frecuencia; con el equipo comercial, los objetivos cumplidos y las capacitaciones; con la red de canales, el volumen y la ejecución en el punto de venta. Si la empresa quiere reconocer a más de una audiencia, la decisión de fondo es si se arman sobre la misma base o en herramientas separadas, y esa decisión cambia lo que sistemas tiene que integrar.

Cómo se mide. Antes de lanzar hay que escribir qué número se espera mover y cómo se va a comparar. La forma más honesta es dejar una parte de la audiencia fuera del programa durante un tiempo y comparar cómo se comporta contra la que entró: así lo que cambió se puede atribuir al programa y no a la temporada.

El piloto: cómo pedir menos para conseguir el sí

La forma más corta de destrabar la aprobación es dejar de pedir el programa completo. Un piloto acotado le baja el riesgo a cada área al mismo tiempo: finanzas ve un costo con techo, sistemas ve una integración pequeña, legal revisa un reglamento para una sola audiencia y atención al cliente aprende con un volumen que puede manejar.

Un buen piloto tiene una audiencia (no todas), una mecánica simple (puntos por la acción que más importa, un par de premios que la gente quiera de verdad), un plazo fijo de tres a seis meses y una métrica acordada de antemano con su grupo de comparación. Al final del plazo la discusión ya no es sobre una idea: es sobre un resultado.

Y conviene dejar por escrito desde el principio qué pasa si funciona. Si el piloto sale bien y no hay un camino acordado para ampliarlo, la empresa vuelve a la ronda de escritorios con un programa funcionando y miembros esperando.

Preguntas frecuentes