Caso de estudio
Turismo Salinas
Cada reserva empezaba de cero en un chat. La página no vino a quitar ese chat: vino a entregarle la conversación ya resuelta.
Turismo · Reservas
- Cliente
- Turismo Salinas
- Entrega
- Semana y media
- Equipo
- 2 fundadores
- Fase
- 1 de 2 — pagos pendientes

Todo el negocio cabía en tres apps ajenas
Antes del proyecto, Turismo Salinas no tenía sitio web. La operación completa —catálogo de viajes, fechas, precios, dudas, cierre— pasaba por Facebook, Instagram y WhatsApp.
El problema no era la falta de clientes, era el arranque de cada conversación. Quien preguntaba no sabía qué viajes existían ni cuándo salían, así que cada chat empezaba desde el principio: qué hay, para cuántas personas, en qué fecha, cuánto cuesta. El mismo trabajo repetido en cada mensaje, y ninguna forma de que alguien explorara la oferta por su cuenta.
Semana y media, y sin pasarela de pagos
El proyecto entero se hizo en semana y media de inicio a fin, entre dos personas. Y el cobro seguía —y sigue— ocurriendo por WhatsApp: no había pasarela de pagos que integrar en esta fase.
Eso descartaba de entrada un checkout tradicional. Cualquier flujo que terminara en un botón de «pagar» habría sido una mentira.
No pelear contra el WhatsApp: alimentarlo
En vez de tratar el chat como el enemigo a eliminar, lo tratamos como el paso final del embudo. La página lleva al visitante por la historia del destino, deja que compare viajes y elija fecha y número de personas, y arma con todo eso un mensaje de WhatsApp ya redactado y completo. El cliente llega al chat con la reserva puesta; el operador ya no pregunta, confirma.
La segunda decisión fue sobre cómo construirlo: nada de plantillas ni de bloques prearmados que cualquiera puede montar en una tarde. Todo desde cero, con una sola regla de oro que usamos para resolver cada discusión de diseño — que sea intuitivo. Si una pantalla necesitaba explicación, estaba mal.
Y dejamos los pagos en línea fuera a propósito, para la fase dos. Meterlos con calzador en semana y media habría producido un checkout a medias en un negocio que aún cobra por chat.
Plataforma propia, reservas que llegan armadas y base lista para pagos
Turismo Salinas dejó de depender de tres plataformas ajenas para enseñar lo que vende. Hoy tiene catálogo propio con storytelling visual, exploración libre de viajes y un flujo que convierte la duda en una solicitud de reserva completa.
Está construido en Next.js con Framer Motion y Tailwind, y la arquitectura de reservas quedó preparada para conectar la pasarela de pago sin rehacer el flujo.
¿Tu proyecto se parece a este?
Hablas directo con quien programa, y en la primera llamada te decimos si tiene sentido hacerlo y cuánto tarda de verdad — incluso cuando la respuesta es que no.
Cuéntanos tu caso