Alguien busca «uñas cerca de mí», mira lo que aparece en el mapa y elige. Esa decisión dura treinta segundos. Beserva fue el trabajo de meter al salón dentro de esos treinta segundos, con un botón de «Reservar» que Google no le deja poner a cualquiera.
Poner un botón de reservar en una ficha de Google no es integrar una API con una clave. Es entrar en un programa cerrado, con su formato, su canal de entrega y su certificación.
El salón, mientras tanto, lleva sus citas en una libreta o en WhatsApp. Así que el problema tiene dos mitades que hay que resolver a la vez: aparecer donde se toma la decisión, y tener detrás una agenda que sostenga lo que ese botón promete. Y una tercera que casi nadie anticipa: los datos que los negocios cargan de verdad no se parecen a los que la especificación pide.
Una traía a la gente desde Google. La otra le daba al salón una casa propia donde recibirla.
El programa Reserve with Google, implementado completo: los feeds que Google exige, entregados por su canal de socios, con certificación superada.
El salón contrataba tener su aplicación en su propia dirección. Pagaba, y no volvía a tocar nada: el alta completa era automática.
Existían dos entornos con credenciales distintas: pruebas y producción. Ese detalle es la prueba del trabajo, porque Google solo entrega las credenciales de producción después de certificar el entorno de pruebas. Hubo revisión externa y se superó.
Un negocio entraba en el feed si tenía dirección completa, horarios cargados y al menos un servicio con alguien del equipo asignado. Lo que no pasaba el filtro no se enviaba: se registraba con su motivo y un enlace para arreglarlo.
Cada reserva que nacía en Google se le informaba de vuelta a Google, incluso cuando el visitante llegaba sin sesión iniciada. Sin ese circuito cerrado, la integración funciona pero nadie puede demostrar que trae negocio.
Cuatro cosas que no aparecen en ninguna documentación y que decidían si la integración llegaba a producción o se quedaba en la demostración.
Google usa el teléfono para casar la ficha del feed con el perfil real del negocio. Sin teléfono no hay emparejamiento, y el envío es inútil. Muchos salones habían dado de alta su WhatsApp en el lugar del teléfono.
Un proceso dedicado recupera el número desde el contacto de WhatsApp del negocio para los centros que tenían el teléfono vacío.
Con espacios, con paréntesis, con guiones, con el prefijo del país puesto a medias: el zoo de formatos que produce un campo de texto libre en México, resuelto por reglas sucesivas hasta el formato internacional.
Los salones ponen tijeras y esmaltes en el nombre del negocio. Esos caracteres rompen validaciones y codificaciones intermedias, así que se filtran antes de emitir la entidad y el servicio.
En el alta se comprueba contra Google que el negocio sea de verdad un salón, barbería o spa. Si no lo es, no se registra: se le explica que necesita un perfil de Google Mi Negocio.
La integración no se cae por el formato del feed. Se cae por los datos reales, y ahí es donde estuvo el trabajo.
Un feed no se acepta a medias. Basta con que unos cuantos registros incumplan para que la corrida se convierta en un problema, y las reglas de aceptación se aprenden a base de rechazos.
Dirección completa, negocio activo, alta voluntaria en el programa, horarios cargados y al menos un servicio publicable. Lo que no cumple, no sale.
Un servicio no es publicable si su descripción es idéntica a su nombre. Google no lo acepta, y esa condición está escrita explícitamente en el filtro.
El negocio solo se emite si al menos uno de sus servicios pasó el filtro: mandar entidades sin ninguna acción asociada es una causa habitual de rechazo.
Cada exclusión se registra con su motivo y un enlace directo a la ficha, y hay un panel para revisarlas. Descartar sin decir por qué convierte el filtro en un agujero negro.
El feed se convierte en una tubería que se puede operar, no en una caja que unos días funciona y otros no.
Dar de alta la aplicación de un salón en su propia dirección toca cinco sistemas externos que no comparten transacción. Y el primer paso gasta dinero de verdad, cada vez que se ejecuta.
Compra del dominio, registro A, generación de ficheros, zona DNS en la nube, servidor web y certificado. El avance se guarda después de cada paso.
Una ejecución interrumpida en el cuarto paso continúa en el cuarto. No vuelve a comprar el dominio, que es justamente lo que no puede repetirse.
El proceso se protege con un bloqueo de fichero, de modo que dos pasadas simultáneas no trabajan sobre la misma alta.
La creación de la zona comprueba si ya existe antes de crearla, y si el registro está puesto lo actualiza en lugar de duplicarlo.
Una transacción distribuida sobre sistemas que no la soportan, con el paso irreversible protegido. El cliente paga y no vuelve a tocar nada.
Un envío periódico a un socio externo es exactamente el tipo de tarea que deja de funcionar sin que nadie se entere, hasta que alguien pregunta por qué ya no entran reservas.
Total, activos, inactivos, fuera del programa, a los que les faltan datos, cerrados y servicios enviados, en una tarjeta a un canal de chat del equipo.
Si la subida al canal de Google devuelve error, se dispara una alerta al canal de los desarrolladores.
Los negocios y servicios excluidos se consultan desde un panel con su motivo. Nadie construye eso para un experimento.
La integración es voluntaria: hay una tarjeta en el panel del salón con su estado, y el feed respeta esa elección.
La integración no fue un cron a ciegas: fue un proceso operado, con gente mirándolo y herramientas para corregirlo.
Las reseñas pasaban por un análisis de toxicidad antes de publicarse, con umbrales propios y una cola de revisión humana para los casos dudosos. No es IA de folleto: es un filtro concreto con la última palabra en manos de una persona.
Una ciudad nueva no se publicaba sola: el sistema creaba el candidato y avisaba al equipo, y solo se convertía en página cuando alguien la validaba a mano. Las combinaciones de ciudad y categoría se emitían únicamente si había negocios reales cerca.
El panel del salón calculaba sus métricas sobre las operaciones reales del negocio. Ni una cifra de ejemplo, ni un gráfico de relleno, que es lo habitual en los paneles que se enseñan en una demostración.
Todo lo de esta lista llegó a producción, y quedó en manos del equipo del cliente en condiciones de seguir creciendo.
Ver todos nuestros serviciosEn abril de 2025 el desarrollo pasó al equipo técnico de Beserva, que continuó desde donde lo dejamos. Nosotros construimos las bases; ellos siguieron edificando.
Un proveedor que se vuelve imprescindible es un problema, no un mérito. Lo sano es que llegue el día en que el equipo del cliente pueda seguir solo.
Lo que se traspasa no es un binario: es el código, los procesos que corren solos y las integraciones con sus credenciales y sus entornos. Otro equipo tiene que poder tomarlo y avanzar.
Este caso salió de una auditoría del código que escribimos, no de un folleto. Lo que no encontramos funcionando, no está en esta página.
Diez meses de trabajo sobre una base heredada, con el aprovisionamiento completo de marca blanca levantado en seis semanas, entregado a su equipo para que siguiera.
Google, marketplaces, pasarelas de pago, mensajería. Integrarse bien con un tercero es un oficio: su formato, su certificación, sus rechazos y sus datos sucios. Es lo que sabemos hacer.