Cómo conseguir que tu empresa apruebe el programa de fidelización: lo que pregunta cada área

Finanzas: cuánto cuesta y qué deuda genera

La primera pregunta de finanzas no es cuánto sale 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 va a tener que cumplir cuando el miembro lo pida. Mientras no se canjea, esa promesa está 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 traerla resuelta.

Lo que finanzas necesita ver es la cuenta completa, no sólo 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 lleva) y lo que cuesta comunicarlo. Del otro lado va lo que se espera mover, y acá 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 suma, y si nadie suma, nadie canjea. Mostrar que el gasto en premios crece sólo 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 da abasto?

Ahí conviene separar dos caminos, porque la respuesta cambia mucho. Si el programa se desarrolla adentro, sistemas va a estimar la primera versión en semanas y va a tener 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 va a 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 dispara (un alta, una compra, una devolución, un objetivo cumplido), recibir las notificaciones de vuelta en un endpoint y dibujar las pantallas con el diseño 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.

Legales: el reglamento y los datos

Legales va a preguntar dos cosas, y ninguna es un trámite.

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

La segunda son los datos personales. El programa va a juntar información de gente (quién compró, qué, cuándo, cómo contactarla) y legales 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 mandan 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 legales y con recursos humanos antes de diseñar la mecánica.

Atención al cliente: quién contesta 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 contesto?

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 participa del diseño desde el principio, el programa sale con las respuestas armadas. Si se entera el día del lanzamiento, el programa sale igual, pero los primeros reclamos los contesta alguien que no sabe cómo funciona.

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

La propia área que impulsa el programa tiene que contestar las dos preguntas que el resto de la empresa no puede contestar 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 afuera del programa por 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 entero. Un piloto acotado le baja el riesgo a cada área a la vez: finanzas ve un costo con techo, sistemas ve una integración chica, legales revisa un reglamento para una sola audiencia y atención 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 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 andando y miembros esperando.

Preguntas frecuentes