Dejamos de personalizar nuestro motor de reservas, con una excepción

Durante años, el «sí» parecía la respuesta segura.

En noviembre mandé una propuesta llena de «noes».

Y fue la más honesta que había escrito en mucho tiempo.

Un alojamiento rural quería renovar su web, con motor de reservas y gestor de canales. Después de una llamada, les mandé lo que llamé la propuesta más sincera que podíamos hacerles. Un servidor dedicado. El motor de reservas en su última versión oficial, igual para todos y sin cambios a medida que impidieran futuras actualizaciones. Y una lista clara de lo que iba a funcionar de forma distinta que antes.

Les expliqué el motivo sin rodeos: cualquier personalización del motor de reservas nos volvería a dejar atascados.

Algunas cosas que nos habían dicho que eran imprescindibles pasaron a ser un simple «no es posible» en esa lista. Otras cambiaban de funcionamiento. Los bonos regalo se seguirían vendiendo igual, pero se canjearían al final del proceso de pago, como cualquier código de descuento.

Pocos días después les mandamos el presupuesto.

Cómo un producto vuelve a ser un montón de proyectos

Cada personalización parece pequeña cuando la aceptas. Un campo por aquí, una norma especial por allá, un proceso distinto para los bonos de un cliente.

Luego el producto avanza y ese cliente se queda atascado en una versión antigua, porque su norma especial se rompería con la actualización. Ahora mantienes dos productos. Luego, tres.

Es como esas cocinas en las que cada cajón tiene su truco: levántalo un poco, empuja a la izquierda y tira. Al dueño le vale. Para cualquier otro es una pesadilla para siempre.

Ese «volver a quedarnos atascados» de mi propuesta no era teórico. Es así como un producto se convierte poco a poco, otra vez, en un montón de proyectos a medida.

Cada personalización que vendes hoy es una actualización que no podrás hacer mañana.

La única excepción, con su precio

Decirle que no a un cliente que paga todavía me resulta incómodo. Empezamos con 300 € en 2014 y, durante mucho tiempo, el «sí» parecía lo seguro. Una parte de mí teme que el cliente se vaya. Otra se pregunta si suena arrogante.

Pero creo que la alternativa es peor: decir que sí y, meses después, tener que explicarle por qué su motor no puede recibir las mejoras que tienen todos los demás. Eso no es dar servicio. Es una trampa con una buena factura al principio.

Y sí, incluso aquí hubo una excepción. El cliente no quería que los huéspedes perdieran el saldo sobrante de un bono en temporada baja. Acordamos hacerlo posible con un pequeño añadido, y le dijimos claramente que habría que coordinarse en cada actualización para que siguiera funcionando.

Esa es la versión honesta de una excepción: pequeña, con nombre y con su coste por escrito.

La pregunta de fondo sigue ahí. Si un alojamiento necesita algo, probablemente otros también. Entonces no es una personalización: es una petición de función, y o va en el producto para todos o no va. La web puede ser a medida. El servidor puede ser dedicado. Pero el motor es el mismo para todos.

No tenemos un gran equipo para mantener veinte versiones del mismo motor. Tenemos a Yeray, a mí y un producto que queremos seguir mejorando. Crecer sin prisas solo funciona si el producto sigue siendo lo bastante ligero como para poder llevarlo.

Antes pensaba que decir que sí a cada petición era dar un buen servicio.

Ahora creo que el buen servicio es decirle al cliente, antes de que firme, lo que no vamos a hacer.

P. D.: Escribir «no es posible» en una propuesta es mucho más fácil que decir «se rompió con la actualización» por teléfono. He probado las dos cosas.