Changelog¶
Novedades de HybsChat. Usamos versiones por fecha con el formato AAAA.MM.DD: el número de versión que ves abajo (y en tu panel, arriba a la derecha) corresponde a la última actualización publicada.
Versión actual: 2026.10.17.1
En tu panel de HybsChat, la versión aparece como una etiqueta arriba a la derecha. Cuando hay novedades, verás un puntito rojo — al abrir esta página, se marca como visto.
2026.10.17.1 — Clientes con varios servicios: el asistente ya dice cuál falla 🔀¶
- Si un cliente tiene varios servicios a su nombre y solo uno está caído, el asistente lo dice así. Antes miraba únicamente el primero de la lista: con cuatro contratos y uno sin conexión podía responder que estaba todo caído — o que estaba todo bien, según cuál fuera el primero. Las dos respuestas eran falsas.
- Ahora nombra el servicio afectado («el de tal dirección está sin conexión, los otros están funcionando») y el diagnóstico y los pasos valen solo para ese: ya no le pide al cliente reiniciar equipos que están trabajando bien.
- En la ficha del cliente, dentro del chat, tus agentes ven el detalle por servicio en vez de un único semáforo que promediaba todo.
- En el constructor de flujos tienes variables nuevas para armar tu propio mensaje:
{{servicios_total}},{{servicios_caidos}}y{{servicio_caido}}con el nombre del que está sin conexión. El bloque «Estado de conexión» suma la salida Parcial; si no la conectas, esos casos siguen saliendo por Sin conexión como hasta ahora y tus flujos actuales funcionan sin tocarlos. - Aplica a los ISP con Mikrowisp, que es donde una cuenta puede tener varios servicios.
Dónde lo ves: cuando un cliente con más de un servicio consulta por su conexión.
2026.10.16.4 — La conciliación ya no pierde un pago por un dígito 🔢¶
- Si el número de operación se leyó con un dígito cambiado de lugar, igual lo encuentra. Los comprobantes mexicanos traen claves de rastreo de 19 dígitos y la lectura automática a veces invierte dos. Antes ese pago no cruzaba con tu extracto y aparecía como «sin respaldo», aunque el dinero estuviera en tu cuenta.
- Solo cuando es seguro. Se aceptan los mismos dígitos en otro orden —que es lo que pasa cuando la lectura falla— y además tienen que coincidir el monto y la fecha. Dos operaciones distintas nunca son el mismo número reordenado, así que no hay forma de que cruce el pago de una persona con el de otra.
- Si hay dudas, no cruza. Cuando más de un movimiento podría ser, lo deja en «sin respaldo» para que lo revises. Preferimos que mires un pago de más a que demos por bueno el movimiento equivocado.
- En la tabla aparece como «N° de operación mal leído» con el número tal como lo trae tu banco al lado, para que veas la diferencia de un vistazo.
Dónde lo ves: Comprobantes → Conciliar con mi extracto bancario.
2026.10.16.3 — Comprobantes en PDF, incluidos los escaneados 📄¶
- Tus clientes ya pueden mandar el comprobante en PDF. La banca mexicana lo entrega así desde la app —Banamex, BBVA, Santander— y hasta ahora el asistente no lo reconocía: el cliente mandaba su pago y quedaba esperando. Ahora lo lee igual que una captura.
- También los escaneados. Si el comprobante es una foto del voucher dentro de un PDF, se lee la foto en su calidad original, sin perder nitidez por el camino.
- No cambia nada de tu lado. Mismo flujo, mismas validaciones y el mismo aviso en el chat; el asistente simplemente entiende un formato más.
Dónde lo ves: cuando un cliente manda su comprobante como archivo PDF.
2026.10.16.2 — México: la clave de rastreo y los depósitos en ventanilla 🇲🇽¶
- Se toma la clave de rastreo, que es el número que vale para verificar un SPEI en el CEP de Banxico. Antes podía quedarse con el «número de referencia», que no sirve para rastrear el pago.
- Depósitos en ventanilla bien leídos. En el ticket del banco, el número que identifica la operación es el de «AUT»; el «folio» es un contador de la sucursal. Y el nombre que figura como «CLIENTE» es el tuyo —eres quien recibe—, no el de quien depositó: antes se confundía y el pago se rechazaba por «no coincide con el cliente».
- El nombre de quien paga se busca en el «Concepto», que es donde los clientes mexicanos suelen escribirlo cuando el comprobante no trae remitente.
- Las transferencias «en progreso» se marcan como tales. Si el comprobante dice que la operación todavía no se completó, queda anotado en el chat para que no se tome como un pago confirmado.
- También se reconocen los comprobantes de Spin by OXXO, Plata, Nu, Klar, Hey Banco y los folios con letras que usan algunas de esas aplicaciones, que antes se rechazaban por «formato no válido».
Dónde lo ves: cuando un cliente manda su comprobante por WhatsApp.
2026.10.16.1 — Tus avisos ya no quedan escondidos ✉️¶
- Si tu bandeja no tiene el asistente encendido, las conversaciones entran directo en «abiertas», que es donde miran tus agentes. Antes podían quedar en «pendientes» —la cola del asistente— y, con el asistente apagado, ahí no las veía nadie.
- Pasaba sobre todo al sumar un número nuevo: los avisos salían y llegaban bien a tus clientes, pero al entrar a tu panel parecía que no había pasado nada.
- Revisamos todas las cuentas y acomodamos lo que estaba así, incluidas las conversaciones que ya habían quedado en esa cola. Si notaste que te aparecieron conversaciones que no habías visto, es esto.
- La regla ahora es una sola y vale para todos los canales: «pendientes» es del asistente, «abiertas» es de tu equipo.
Dónde lo ves: en tu CRM, en la bandeja de cada número.
2026.10.12.2 — UISP: el cliente paga y se le reconecta solo 🔌¶
- Si usas UISP, ahora el asistente puede reconectar. Cuando tu cliente estaba cortado por mora y manda un comprobante que el bot valida y acredita, el servicio se reactiva en el acto — sin esperar a que pase la tarea automática de UISP ni que alguien lo haga a mano. Es la única integración donde esto es posible hoy.
- El cliente se entera en el mismo mensaje: el asistente le dice que ya le reactivaron el servicio y que reinicie su equipo si no le vuelve en unos minutos. En el chat te queda la nota «🔌 el servicio estaba cortado por mora y se reconectó automáticamente».
- Con tres candados, porque esto toca el servicio de una persona:
- Solo si no le queda ninguna otra factura vencida. Si tenía dos vencidas y pagó una, no se reconecta: UISP lo volvería a cortar esa noche y el cliente vería el internet volver y caerse.
- Solo si el corte fue por pagos. Si lo suspendiste tú por otro motivo —«Suspensión Temporal», «Fuera del País», lo que uses— tu decisión se respeta y el asistente no la toca; te lo avisa en la nota.
- Nunca pone en riesgo el cobro. El pago se acredita primero; si la reconexión fallara, el pago ya está registrado y te queda anotado para revisarlo.
- En el constructor de flujos tienes la variable
reconectadopara armar tu propio mensaje con una Condición. - Necesitas una App Key de tipo Write (la de tipo Read no puede reconectar ni registrar pagos).
Dónde lo ves: en el chat, cuando un cliente cortado manda su comprobante.
2026.10.12.1 — Ya funciona con UISP / UCRM de Ubiquiti 📡¶
- Cuarto sistema soportado. Si facturas con UISP CRM (antes UCRM), el asistente ya puede atender a tus clientes: los identifica, les dice cuánto deben y cuándo les vence, registra sus pagos y cierra la factura, abre tickets y carga los prospectos nuevos.
- Te identifica por el teléfono desde el que escribe tu cliente, sin preguntarle nada. Y si hace falta, por su documento: el asistente encuentra solo el campo donde tú lo guardas (en UISP el documento es un campo personalizado y cada ISP le pone su propio nombre).
- Para conectarlo: Configuración → Sistema ISP → UISP / UCRM (Ubiquiti), el dominio de
tu UISP sin el
/crm, y una App Key que generas en UISP CRM → Settings → Security → App keys. Tiene que ser del tipo Write: una de tipo Read permite consultar la deuda pero no registrar pagos ni abrir tickets. - Dos cosas que UISP no puede hacer, y las decimos de frente: no tiene prórrogas de pago (si tu cliente pide unos días, el asistente le avisa y deja el pedido anotado en su ficha, pero no mueve ninguna fecha), y no guarda las claves del WiFi ni el serial de la ONU, así que esa parte de la ficha del cliente aparecerá vacía — eso vive en el lado de red de UISP.
- Si elegiste otro sistema por error, el panel ahora te lo dice al guardar en vez de aceptarlo en silencio: una dirección de UISP con el tipo equivocado no puede funcionar.
- Funciona con los dos bots: el de flujos y el de IA. En el constructor de flujos, el revisor te avisa antes de publicar lo que UISP no puede cumplir: si pusiste el comprobante en modo «dar unos días» te lo marca como error (porque el servicio se cortaría igual) y te recuerda que el bloque de estado de conexión solo sirve para detectar cortes de zona, no para saber si el problema es el WiFi del cliente.
Dónde lo ves: Panel → pestaña ⚙️ Configuración → Sistema ISP.
2026.10.09.1 — Mercado Pago para México, con OXXO incluido 🇲🇽¶
- Ya puedes cobrar con Mercado Pago en México. El bot le manda a tu cliente un solo link y él elige cómo pagar: tarjeta, transferencia (SPEI), el dinero de su cuenta de Mercado Pago o efectivo en OXXO, PayCash y Tiendas Autorizadas. Cuando el pago entra, la factura se cierra sola en tu sistema y tu cliente recibe la confirmación por el chat.
- OXXO no es una pasarela aparte: viene dentro de ese link. No tienes que contratar nada más ni configurar un segundo cobro. Si te ofrecen «OXXO Pay» por separado, con Mercado Pago ya lo tienes cubierto.
- El link de Mercado Pago vive 3 días, porque pagar en efectivo es un viaje a la tienda y no un clic. Los links de tarjeta de otras pasarelas siguen durando 30 minutos.
- El pago en efectivo tarda 1 o 2 días hábiles en acreditarse y el bot se lo avisa al cliente cuando le manda el link, para que nadie espere la reconexión en el acto. Nosotros seguimos revisando ese cobro durante 8 días: si tu cliente paga el tercer día, igual lo detectamos y cerramos la factura.
- Para activarlo solo necesitas tu access token de Mercado Pago México (Tus integraciones → tu aplicación → Credenciales). No hay que configurar ningún webhook, y el dinero entra directo a tu cuenta: nosotros no intermediamos los fondos en ningún momento.
Verifica tu cuenta antes del primer cobro
Toca Probar conexión y te decimos de qué país es tu cuenta y en qué moneda va a cobrar. Una cuenta de otro país no puede cobrar en pesos mexicanos, y eso no se nota hasta el primer pago.
Dónde lo ves: Panel → pestaña 💳 Cobros → 💳 Cobros automáticos → «Agregar/configurar Mercado Pago».
2026.10.08.7 — Pago en persona: Caja Vecina y efectivo 💵¶
- Nueva sección «Pago en persona» en las formas de pago del bot. Es la vía del cliente que no usa banca en línea: cargas el lugar y qué tiene que decir o dar ahí, y el bot se lo repite tal cual cuando dice que no tiene tarjeta, que quiere pagar en efectivo o que pregunta dónde pagar presencialmente.
- Para Chile hay dos botones listos: Caja Vecina y ServiEstado. Con un clic queda cargado «ve a cualquier Caja Vecina, pide pagar el convenio de tu empresa y da tu RUT». Necesitas tener convenio de recaudación con BancoEstado para que te lo reciban; el panel te lo aclara.
- El bot ya no confunde un lugar con una cuenta. Antes, al cargar algo sin número de cuenta, se descartaba y el bot no lo ofrecía nunca; ahora las cuentas y los lugares van en bloques separados y el cliente ve las dos vías, cada una con lo suyo.
- El agente también puede enviarlo desde la ficha del cliente, con el botón «Enviar formas de pago»: el lugar sale con su instrucción en vez de con una cuenta vacía.
- El asistente aprendió a leer el voucher de Caja Vecina, ServiEstado y Servipag (papel de punto de pago, con «Convenio» y «Rut cliente»): reconoce a tu empresa como quien recibe y al cliente como quien paga, así que el comprobante se valida y el pago se registra igual que una transferencia.
Dónde lo ves: Panel → 🤖 Bot → Entrenar al bot → paso Cobros → 🏦 Formas de pago → 💵 Pago en persona.
2026.10.08.6 — Los medios de pago, como son en tu país 🔍¶
- Corregimos lo que el panel y el bot prometían sobre Mercado Pago. Fuimos a su catálogo oficial, país por país, y ajustamos los textos: en México el link incluye efectivo en OXXO, PayCash y Tiendas Autorizadas; en Argentina, Rapipago y Pago Fácil; en Colombia, Efecty y PSE; en Uruguay, Abitab y Redpagos; en Brasil, boleto y Pix; en Perú, pago en agentes de BCP, BBVA u otros bancos.
- En Chile, Mercado Pago no tiene pago en efectivo — son tarjetas, dinero en cuenta y transferencia con Fintoc. El panel decía «efectivo en Servipag» y el bot se lo repetía al cliente. Ya no: ahora el tab lo aclara y te sugiere pedirnos Webpay o Caja Vecina si lo que necesitas es que tu cliente pague en una caja.
- El bot dice los medios reales de tu país. El aviso de «el pago en efectivo tarda 1 o 2 días hábiles en acreditarse» aparece solo donde ese efectivo existe de verdad.
Dónde lo ves: Panel → pestaña 💳 Cobros, y en el mensaje que el bot le manda a tu cliente con el link de pago.
2026.10.08.5 — PayPal ya cobra 💙¶
- PayPal pasó de «en evaluación» a funcionando. Lo pidió un ISP de México y ya se puede configurar en el tab Cobros: tu cliente paga con su cuenta PayPal o con cualquier tarjeta internacional —sin crearse una cuenta— y el dinero entra directo a tu cuenta de PayPal.
- Disponible para 🇪🇨 Ecuador, 🇲🇽 México, 🇪🇸 España y 🇵🇦 Panamá. PayPal cobra en dólares, pesos mexicanos, euros y reales, así que no aparece donde se factura en soles o en pesos argentinos, chilenos y colombianos: preferimos no ofrecerte algo que fallaría al cobrar. Para Ecuador y Panamá es la primera pasarela disponible.
- Solo necesitas el Client ID y el Secret de tu aplicación de PayPal, y elegir si son de pruebas o de producción. Nada de webhooks: cuando tu cliente aprueba el pago nosotros le preguntamos a PayPal y lo cobramos en ese momento; y si cerró el navegador antes de volver, un proceso nuestro lo completa igual.
- El link de PayPal vence en 3 horas, que es lo que dura una orden suya. Si tu cliente cancela en la pantalla de PayPal, ve un aviso de que no se le cobró nada y su factura sigue pendiente.
Dónde lo ves: Panel → pestaña 💳 Cobros → 💳 Cobros automáticos → «Agregar/configurar PayPal». La guía está en Cobros del bot.
2026.10.08.4 — El catálogo completo de pasarelas 🗂️¶
- Sumamos al tab Cobros todas las pasarelas que podemos integrar, cada una con la bandera de los países donde opera: PayU, BBVA, OXXO Pay, PagoFácil, Wompi, ePayco, Webpay, Flow, Khipu, BancoEstado (Caja Vecina), Siro, Cuenta Digital, Cobro Digital, Authorize.net, PixelPay, ATH Móvil y, para Ecuador, Payphone, Datafast y PlacetoPay.
- Primero ves las de tu país; las demás quedan en el «ver también las que no operan en tu país». Pasa el mouse por cada una y te dice qué medios de pago trae.
- Todavía no se pueden activar, y por eso están marcadas así: existen para que veas que tu pasarela local está contemplada y para que nos digas cuál necesitas. La que pide un ISP es la que desarrollamos — así entraron Culqi y el pago con QR.
- Si en tu país ninguna está lista todavía, el tab te lo dice y te recuerda lo que ya funciona: tu cliente paga como siempre, manda la foto del comprobante por el chat, y el asistente la lee y registra el pago en tu sistema.
Dónde lo ves: Panel → pestaña 💳 Cobros → 💳 Cobros automáticos → «Otras pasarelas que podemos desarrollar».
2026.10.08.3 — PayPal a la vista, y Ecuador en el mapa 🇪🇨¶
- PayPal ya aparece en Cobros con las banderas de los países donde sirve: Ecuador, México, España, Panamá y Costa Rica. Va marcado En evaluación, porque todavía no se puede activar — preferimos decírtelo antes que dejarte guardar unas llaves que el cobro automático aún no sabe usar, y que tu cliente toque el link y no pase nada.
- Si cobras por PayPal, escríbenos y dinos qué parte de tus cobros pasa por ahí. Con ese dato entra en la cola de desarrollo: así salieron Culqi y el pago con QR.
- Si en tu país todavía no hay ninguna pasarela que puedas activar, el tab te lo dice con nombre y apellido («PayPal sirve ahí, pero aún no está lista») en vez de quedar en blanco.
- Mercado Pago: la moneda no se elige. La define el país de tu cuenta, y cobrar en otra te la rechaza. Ahora lo dice el formulario, y Probar conexión te confirma de qué país es la cuenta y en qué moneda va a cobrar antes del primer pago.
Dónde lo ves: Panel → pestaña 💳 Cobros → 💳 Cobros automáticos.
2026.10.08.2 — Cobros: solo las pasarelas de tu país 🏳️¶
- Cada pasarela con las banderas de los países donde opera, y el tab lista solo las que sirven donde están tus clientes. Si tus clientes son de México ya no ves Izipay ni Culqi (son de Perú), ni un Mercado Pago rotulado «Argentina». Si igual quieres verlas todas, hay un enlace al final.
- Mercado Pago habla de los medios de TU país. En México, el mismo link incluye OXXO y 7-Eleven; en Argentina, Rapipago y Pago Fácil; en Perú, agentes y bodegas. OXXO no es una pasarela aparte: es uno de los medios de ese link.
- Si en tu país todavía no tenemos pasarela, el tab te lo dice en vez de quedar vacío, y te recuerda que tus clientes pueden pagar como siempre y mandar la foto del comprobante por el chat: el asistente la lee y registra el pago en tu sistema.
- El bot ahora dice la vigencia real del link y los medios reales. Un link de tarjeta dura 30 minutos; uno de Mercado Pago dura 3 días, porque se puede ir a pagar en efectivo a una tienda — y el bot avisa que ese pago puede tardar 1 o 2 días hábiles en acreditarse. Antes decía «expira en 30 min» y «aceptamos Yape y Plin» con cualquier pasarela y en cualquier país.
Dónde lo ves: Panel → pestaña 💳 Cobros → 💳 Cobros automáticos.
2026.10.08.1 — Tus contactos, con el nombre que tienes en tu sistema 📇¶
- La cartera de tu sistema, dentro de la agenda del CRM. Si usas Mikrowisp o WispHub, ahora puedes traer el nombre, el documento y el estado del servicio de cada cliente a los contactos del CRM. Se crea el contacto del cliente que nunca te escribió, y al que hoy aparece como «Cliente 946595725» se le pone su nombre real.
- Buscas por nombre y lo encuentras. También puedes escribirle primero tú a un cliente, sin tener que pedirle el número a nadie.
- Antes de aplicar, puedes ver qué cambiaría. Un botón corre la simulación y te dice cuántos contactos crearía y cuántos renombraría, con ejemplos y sin tocar nada.
- No borra ni une contactos, y el nombre que el cliente tenía en su WhatsApp queda guardado en su ficha, en Nombre en WhatsApp.
- Se sincronizan los clientes activos y suspendidos; los de baja no. Y si lo dejas activado, se repite una vez por semana para que los clientes nuevos aparezcan solos.
Dónde lo ves: Panel → pestaña 👥 Equipo → al final, 📇 Contactos con los datos de tu sistema. La guía completa está en Contactos con los datos de tu sistema.
2026.10.07.3 — Las etiquetas ya aparecen en la barra lateral 🏷️¶
- Todas las etiquetas visibles para filtrar. Las etiquetas que crea HybsChat (pago-pendiente, aviso-automático, corte-programado, nuevo-cliente, soporte-tecnico, reactivacion, promesa-de-pago) y las que creas desde Panel → Equipo ahora quedan activadas en la barra lateral del chat desde que nacen. Antes se creaban ocultas y había que entrar a Ajustes → Etiquetas y activarlas una por una.
- Se activaron en todas las cuentas las que ya existían ocultas. Si prefieres ocultar alguna, puedes hacerlo en Ajustes → Etiquetas.
Dónde lo ves: en el chat, barra lateral izquierda → Etiquetas.
2026.10.07.2 — Comprobantes de «pago de servicios» bien leídos 🧾¶
- Recibos de pago de servicios (Banco Pichincha, Produbanco, agentes, ventanilla). El bot ahora entiende que «Titular» y «Cuenta contrato» son el cliente, que la empresa está en «Empresa o servicio» y que el monto del pago es el «Monto», sin la comisión ni el IVA del banco. Antes leía al cliente como destinatario y le decía que había pagado a otra cuenta.
- Si el OCR confunde los campos, el bot busca el nombre de tu empresa en el texto del comprobante antes de rechazarlo. Si no lo encuentra, pide la captura completa en vez de acusar un pago a otra cuenta.
- La factura la decide tu sistema. Al reportar un pago o dar una prórroga, el bot usa la factura pendiente real del cliente aunque el modelo se equivoque de número. Antes una prórroga podía fallar en silencio con «la factura no existe».
Dónde lo ves: en el chat cuando un cliente manda un comprobante, y en Panel → Comprobantes.
2026.10.07.1 — El bot ya no manda respuestas sin sentido 🧯¶
- Tope de creatividad. El control «Creatividad» del wizard ahora va de 0 a 1. Con valores más altos, el modelo empezaba bien la respuesta y a mitad la terminaba en otros alfabetos y palabras inventadas. Si tenías un valor mayor, se aplica 1 automáticamente. Para un bot que consulta tu sistema y registra pagos, lo recomendado es entre 0.3 y 0.5.
- Red de seguridad. Antes de enviar cada respuesta, el bot revisa que sea texto normal. Si detecta otro alfabeto o tokens sin sentido, vuelve a generar la respuesta en modo preciso y, si vuelve a fallar, deriva al cliente a un asesor con una nota privada que explica el motivo. El cliente nunca ve el texto roto.
Dónde lo ves: Panel → 🤖 Bot → Entrenar al bot → Ajustes → «Creatividad»; y en la nota privada del chat si el bot tuvo que derivar.
2026.10.06.6 — Prospectos sin pedir documento, y tickets del bot solo si los activas 🧭¶
- Clientes nuevos. Si no tienes el complemento de consulta de documento, el bot ya no pide DNI a un prospecto: pide su ubicación (la de WhatsApp o un enlace de Google Maps), verifica cobertura, pide nombre y dirección, y crea la solicitud de instalación en tu sistema. El documento solo se pide cuando tu sistema lo exige para la solicitud (Mikrowisp).
- Tickets del bot, opt-in para todos. El interruptor de Ajustes ahora aplica también a WispHub. Sin él, el bot no abre tickets aunque tu sistema lo permita; tus agentes siempre pueden desde la ficha. Cuando está activo, el bot usa solo los asuntos que existen en tu sistema y nunca abre tickets por pagos o comprobantes.
- RUC de persona natural (Perú). Si un cliente se identifica con su RUC, el bot deriva el DNI que contiene y lo encuentra.
Dónde lo ves: en el chat con prospectos, y en Panel → 🤖 Bot → Entrenar al bot → Ajustes → «El bot abre tickets en tu sistema».
2026.10.06.5 — Comprobantes que el bot no pudo validar llegan a Pagos; prórrogas visibles 📎¶
Dos huecos entre el bot y tu equipo, cerrados:
- El cliente manda un comprobante, el bot no logra validarlo y el cliente no vuelve a escribir. Antes esa conversación se quedaba en pendientes y nadie la veía. Ahora, a los minutos que configuraste en «Pasar a abiertas» (mínimo 30), pasa a abiertas con la etiqueta pago-pendiente, derivada a tu equipo de Pagos y con una nota que explica qué no se pudo confirmar. Se revisan los comprobantes de las últimas 24 horas.
- Prórroga otorgada por el bot a pedido del cliente. Queda una nota privada con los días y la fecha, y la etiqueta promesa-de-pago, para que cobranzas la filtre sin abrir cada chat. La conversación sigue en pendientes porque no hay nada que hacer.
Los comprobantes que el bot sí valida siguen igual: se registra el pago, deja la nota y pasa la conversación a Pagos.
Dónde lo ves: en el CRM, en abiertas con la etiqueta pago-pendiente, y en las notas privadas de cada conversación.
2026.10.06.4 — Las pendientes que ya no esperan nada se resuelven solas 🧹¶
El bot atiende en la cola de pendientes y nunca cierra; los avisos automáticos de tu sistema también nacen ahí. Si el cliente no contesta, esas conversaciones se quedaban en pendientes para siempre: medimos casi 7.000 acumuladas en toda la plataforma.
Ahora, cuando el último mensaje es del bot o de un aviso y el cliente lleva 48 horas sin escribir, la conversación se marca como resuelta. Las que tienen al cliente esperando respuesta no se tocan. Si el cliente vuelve a escribir, la conversación regresa a pendiente y el bot la retoma. El plazo lo puedes cambiar, o apagarlo con 0.
Dónde lo ves: Panel → 🤖 Bot → Entrenar al bot → Ajustes → «Resolver las pendientes que ya no esperan nada». La limpieza del acumulado se hace de a poco, unas trescientas por ISP cada quince minutos.
2026.10.06.3 — Notas de «mensaje no entregado» para todos 📝¶
Cuando Meta rechaza un aviso automático (por ejemplo, por un problema de pago de tu cuenta de WhatsApp Business), HybsChat deja una nota privada en la conversación explicando el motivo. En diez ISP que habían pasado por una baja y una reactivación, ese seguimiento había quedado apagado sin que nadie lo viera. Corregido: vuelve a funcionar para todos, y una reactivación ya no lo apaga.
Dónde lo ves: en el chat, como nota privada bajo el mensaje fallido, con un retraso de hasta diez minutos respecto al rechazo de Meta.
2026.10.06.2 — México: documentos con letras, y sin volver a pedir datos al cliente reconocido 🇲🇽¶
- Los documentos mexicanos tienen letras: clave de elector, CURP, RFC. El bot los recortaba a solo números y tu sistema respondía «no existe» aunque el cliente estuviera cargado. Ahora los acepta completos, en el bot con IA y en los flujos.
- Cuando el bot ya reconoció al cliente por su WhatsApp, no vuelve a pedirle documento ni celular para abrir un ticket ni para consultar su cuenta: actúa directo con su ficha.
Dónde lo ves: en el chat, con clientes de México y en cualquier gestión de un cliente ya reconocido.
2026.10.06.1 — Al resolver, el bot vuelve a atender de verdad 🔁¶
Cuando un agente resolvía una conversación que el bot había derivado, la memoria de esa derivación no se borraba: si el cliente volvía a escribir y la conversación regresaba a pendiente, el bot seguía callado. Pasaba sobre todo en WhatsApp por QR, donde la misma conversación puede reutilizarse durante días. Corregido: al resolver, o al devolver una conversación a pendiente, el bot arranca de cero y atiende.
Dónde lo ves: en cualquier conversación que un agente resolvió y el cliente retomó.
2026.10.06 — Tickets en Mikrowisp, si tú lo activas 🎫¶
Si usas Mikrowisp, ahora puedes dejar que el bot y tus agentes abran tickets de soporte en tu sistema. Viene apagado: lo enciendes en el entrenador, paso Ajustes, y eliges a qué departamento de Mikrowisp van.
- El bot abre un ticket cuando el cliente lo pide o cuando una falla de su servicio no se resolvió con los pasos básicos. Primero identifica al cliente; abre un ticket por problema: si ya tiene uno abierto, le da ese número. Deja una nota privada en el chat con el número y el detalle.
- Tus agentes lo abren desde la ficha del cliente, con el motivo y la descripción, y ven los tickets recientes del cliente ahí mismo.
Un detalle de Mikrowisp: su API exige fecha y turno de visita al crear un ticket. Se registra el día de hoy y el turno según la hora, y el contenido aclara que son orientativos. Por eso la función es opcional: si tu operación agenda visitas con otro criterio, déjala apagada.
Dónde lo ves: Panel → 🤖 Bot → Entrenar al bot → Ajustes → «Abrir tickets en Mikrowisp». Requiere Mikrowisp; WispHub ya tenía tickets desde la ficha.
2026.10.05.5 — WhatsApp por QR: una conversación por atención, como en el canal oficial 🎫¶
En el canal por QR, cada contacto tenía una única conversación para siempre: al resolverla, el siguiente mensaje la reabría con el mismo agente, equipo y etiquetas del ciclo anterior. Consecuencias: el bot quedaba fuera desde el primer contacto humano, y tu equipo perdía el «una conversación por atención» que sí tiene en el canal oficial.
Ahora funciona igual que el oficial: al resolver una conversación, el próximo mensaje del cliente abre una conversación nueva, limpia, que el bot atiende si está encendido. Las conversaciones sin resolver siguen acumulando los mensajes en el mismo hilo. Aplicado ya a todos los números por QR.
Además, mientras una conversación está en pendiente (turno del bot), un agente o equipo que haya quedado asignado de un ciclo anterior ya no lo bloquea.
Dónde lo ves: en el CRM, en las bandejas de WhatsApp por QR. Resuelve las conversaciones al terminar: es lo que arranca el nuevo ciclo.
2026.10.05.4 — Mikrowisp: clientes con varios números en el mismo campo, ya se encuentran 📇¶
Si en tu Mikrowisp un cliente tiene dos números en el campo móvil («2217457471,2271059836»), la búsqueda de Mikrowisp no lo encuentra por ninguno de los dos, y ni el bot ni la ficha del agente lo reconocían. HybsChat ya mantenía un índice de tu cartera para este caso, pero dejaba fuera a los clientes sin documento cargado, que en México son casi todos.
Ahora el índice incluye a todos los clientes, el bot y la ficha lo consultan como último recurso, y se construye solo al activar el bot en un ISP nuevo con Mikrowisp, sin esperar al cron semanal. También se corrigió un caso en que el cliente tenía el número solo en el campo teléfono y no en móvil.
Dónde lo ves: en el chat, cuando el bot reconoce al cliente por su WhatsApp sin pedirle nada; y en la ficha del cliente dentro del CRM.
2026.10.05.3 — El bot también identifica por el celular registrado 📱¶
Cuando un cliente escribe desde un número distinto al que tiene en tu sistema, el bot ya lo reconocía solo por documento. Ahora también puede preguntarle con qué celular registró su servicio y buscarlo por ahí. Si ese número tiene varias cuentas, pregunta a nombre de quién está antes de dar cualquier dato.
En México el orden se invierte: primero el celular registrado y, solo si no aparece, el INE. La razón es práctica: la mayoría de los ISP mexicanos no cargan el INE en su sistema, así que pedirlo primero no identificaba a nadie. En los demás países sigue el documento primero, con el celular como alternativa.
Dónde lo ves: en el chat, cuando el bot no reconoce al cliente por su número de WhatsApp.
2026.10.05.2 — El bot se retira en cuanto un agente responde 🤫¶
Antes el bot seguía contestando en una conversación aunque un agente ya hubiera respondido, si nadie se la había asignado. Ahora, en cuanto una persona de tu equipo escribe en la conversación, la abre o la pospone, el bot se retira y no vuelve a hablar ahí. Vale para todos los canales, incluido WhatsApp por QR cuando el agente responde desde el celular.
Lo que no cambia: cuando el cliente contesta a un aviso automático de tu sistema (recordatorio de pago, corte) o manda su comprobante, el bot lo atiende como siempre.
Para devolverle una conversación al bot después de que un agente la tomó, resuélvela: cuando el cliente vuelva a escribir, el bot la atiende de nuevo.
Dónde lo ves: en el CRM, en cualquier conversación donde un agente haya intervenido.
2026.10.05.1 — Facebook Messenger e Instagram, ya disponibles 💬📸¶
Meta aprobó los permisos de HybsChat para mensajería, así que desde hoy puedes conectar tu página de Facebook y tu cuenta de Instagram profesional y atenderlas desde el mismo CRM, con tu equipo y con el bot. Son canales oficiales, no consumen los números de WhatsApp de tu plan y no se cobran aparte.
- Se conectan en dos minutos con tu inicio de sesión de Facebook.
- El bot responde ahí igual que en WhatsApp: identifica por documento, consulta el estado del servicio, recibe comprobantes y deriva a tus agentes. Viene apagado por bandeja; lo enciendes tú.
- Meta solo permite responder dentro de las 24 horas del último mensaje del cliente, y no hay plantillas ni campañas en estos canales.
Dónde lo ves: Panel → Configuración → tarjeta Conecta un canal → Facebook Messenger o Instagram. Guía completa en Facebook Messenger e Instagram.
2026.10.05 — WhatsApp por QR: el bot ya no contesta en grupos ni encima del agente 📵¶
Tres mejoras para quienes usan el canal WhatsApp por QR con el bot encendido:
- Grupos de WhatsApp fuera. Si tu número está en grupos (del barrio, de ventas, de trabajo), esos mensajes entraban a tu bandeja y el bot con IA les contestaba uno por uno, gastando tu cuota de OpenAI. Ahora los grupos no entran a HybsChat. Aplicado ya a todos los números conectados.
- Si respondes desde el teléfono, el bot se calla. Antes el bot no se enteraba de que un agente había contestado desde el celular y seguía hablando encima. Ahora, en cuanto un humano responde en una conversación que el bot venía atendiendo, el bot se retira hasta que la resuelvas.
- Identificación por documento: no insiste en bucle. Si el documento no aparece dos veces seguidas, el bot deja de pedirlo y ofrece pasar con un asesor que busque por nombre o contrato. Esto aplica a todos los canales.
Dónde lo ves: en el chat con tus clientes. No hay nada que configurar.
2026.10.04.1 — El bot responde una sola vez cuando llegan dos mensajes seguidos 🧵¶
Cuando un cliente mandaba la foto del comprobante y, dos segundos después, un «ya pagué», el bot procesaba los dos mensajes a la vez y respondía dos veces, a veces contradiciéndose (uno pedía el DNI, el otro ya hablaba del pago). Ahora los mensajes de una misma conversación se atienden en orden: el segundo espera al primero y arranca sabiendo lo que ya se dijo.
También en prórrogas:
- Los días los decides tú. El bot a veces otorgaba más días de los configurados en Cobros. Ahora el valor configurado es el máximo; el bot solo puede dar menos si el cliente pide menos.
- Prórroga con comprobante solo si la activaste. Si en Cobros tienes apagada la prórroga que acompaña al comprobante pero encendida la prórroga a pedido, el bot ya no extiende el servicio por cada comprobante que no pudo validar: lo deja para el asesor, y solo da plazo si el cliente lo pide expresamente.
Dónde lo ves: en el chat, cuando un cliente escribe varios mensajes seguidos o manda un comprobante; en Panel → 🤖 Bot → Entrenar al bot → Cobros están los dos ajustes de prórroga.
2026.10.04 — Comprobantes de Yape y Plin: el nombre recortado ya no rechaza el pago 🧾¶
Yape y Plin muestran al titular recortado en la pantalla de confirmación: «Flor Yesenia Gutierrez Ccasani» aparece como «Flor Gut», y el celular de destino solo deja ver los últimos tres dígitos («*** *** 833»). El bot comparaba ese recorte con el titular completo que configuraste en Cobros, no coincidía, y trataba el comprobante como si el dinero hubiera ido a otra cuenta. En el último mes pasó con 28 comprobantes de 3 ISP distintos.
Ahora el bot reconoce el nombre recortado (cada palabra leída es el comienzo de una palabra del titular) y acepta los últimos tres dígitos del celular enmascarado si coinciden con tu Yape o Plin. Los dos modos del bot, IA y flujos, usan la misma regla.
Además, cuando el destinatario de verdad no coincide con tus cuentas, el bot lo dice con claridad y pregunta a qué número se pagó, en vez de confundir al destinatario con quien pagó.
Dónde lo ves: en el chat, cuando un cliente manda su comprobante de Yape o Plin. No tienes que cambiar nada en Cobros.
2026.10.03.2 — Avisos desde tu sistema: respuestas claras cuando algo no se puede enviar 📨¶
Cuando tu sistema (Mikrowisp, WispHub, Wimovil, Wispro) manda un aviso por HybsChat y no se puede entregar, ahora la respuesta dice el motivo real en vez de un error genérico:
- Teléfono imposible (más de 15 dígitos, un local sin país que no se puede resolver): se
rechaza con
invalid_phoney el número tal como llegó, para que lo corrijas en tu sistema. - Plataforma momentáneamente sin respuesta: se reintenta solo y, si persiste, responde
chatwoot_unavailablecon indicación de reintentar en 30 segundos. Antes podía terminar en un contacto duplicado o en un error sin explicación. - Cuenta suspendida o dada de baja: responde
tenant_suspendedde inmediato, sin tocar tu sistema ni intentar el envío.
Dónde lo ves: en la respuesta que recibe tu sistema al llamar al gateway de avisos
(/isp-in), y en el registro de rechazos que revisa el soporte de HybsChat. Si tus avisos
salen bien, no cambia nada.
2026.10.03.1 — Mikrowisp: el pago llega con banco, N° de operación y detalle 🧾¶
Cuando el bot (o un agente desde la ficha) marcaba una factura como pagada en Mikrowisp, el pago quedaba registrado solo como «HybsChat (bot)», sin número de transacción y sin descripción. Ahora se registra tal como lo leyó del comprobante: la forma de pago es el banco o billetera (Yape, Plin, BCP…), la transacción es el número de operación del comprobante, y en las notas del pago va el detalle: cliente, medio, monto, N° de operación, fecha y destinatario. Si el comprobante es de otro día, también se registra esa fecha. Desde la ficha, el N° de operación que escribas a mano manda sobre el leído.
Dónde lo ves: en tu Mikrowisp → la factura → pestaña de pagos (forma de pago, transacción y descripción de la operación). En HybsChat nada cambia: la nota privada en el chat sigue igual.
2026.10.03 — El entrenador ya muestra todo lo que guardaste 💾¶
Cinco ajustes del entrenador del bot se guardaban bien pero, al volver a abrir o refrescar la pantalla, aparecían con su valor por defecto como si no se hubieran guardado: «Permitir que el bot envíe archivos» (Multimodal) y, en Ajustes, «Cliente sigue identificado (horas)» y los tres campos de «Pasar a abiertas si el cliente deja de responder» (minutos, departamento y etiqueta). El bot sí los aplicaba; era solo la pantalla la que no los leía. Corregido: lo que ves es lo que está guardado.
Dónde lo ves: Panel → pestaña 🤖 Bot → Entrenar al bot → pasos Multimodal y Ajustes.
2026.10.02.6 — Rescate de conversaciones: ya puedes elegir el departamento 🛟¶
En Ajustes del entrenador, la opción «Pasar a abiertas si el cliente deja de responder» tenía un desplegable de departamento que salía vacío aunque tuvieras departamentos creados: no se podía derivar la conversación rescatada a nadie. Corregido; ahora lista tus departamentos de Chatwoot (y si no tienes, te manda a crearlos en el paso «Equipos»).
Dos mejoras de paso: la etiqueta que elijas (por ejemplo cliente-esperando) se crea sola en tu Chatwoot si no existe, así puedes filtrar por ella desde el primer rescate; y con esperas largas (hasta 120 minutos) la ventana de rescate se amplía para que siga habiendo conversaciones que rescatar. Los textos de la opción quedaron más cortos.
Dónde lo ves: Panel → pestaña 🤖 Bot → Entrenar al bot → paso Ajustes → Pasar a «abiertas» si el cliente deja de responder.
2026.10.02.5 — Sube los archivos del bot desde el entrenador 📎¶
En el paso Multimodal del entrenador, la opción «¿El bot puede enviar archivos?» te mandaba a cargarlos en otra pestaña del panel. Ahora la Biblioteca de medios está ahí mismo: subes el catálogo de planes, un instructivo o una promo (JPG, PNG, WebP, PDF o MP4), le pones nombre y, para el bot por IA, una línea que le diga cuándo enviarlo («si preguntan por planes»). Ves tu cuota, la lista y puedes borrar.
Es la misma biblioteca de siempre: lo que subas aquí aparece también en el panel, en Bot → Biblioteca de medios, y sirve igual para los bloques «Enviar archivo» de tus flujos.
Dónde lo ves: Panel → pestaña 🤖 Bot → Entrenar al bot → paso Multimodal → ¿El bot puede enviar archivos?
2026.10.02.4 — El paso «Cobros» del entrenador, más corto y en orden 💳¶
El paso de cobros del entrenador del bot tenía mucho texto y las tarjetas en un orden que no ayudaba: primero los links de pago y el QR (que solo existen en Perú) y recién después las formas de pago, que son la base de todo. Lo reordenamos y recortamos:
- Primero tus formas de pago, después los comprobantes, las prórrogas y, al final, el cobro online. Cada opción tiene una línea de explicación, no un párrafo.
- Si tu empresa no es de Perú, no ves tarjetas de pasarelas ni de QR que no puedes usar (salvo que ya tengas una pasarela activa). Para Chile, cada forma de pago pide el RUT del titular y el tipo de cuenta.
- Todo lo que configurabas sigue igual y en el mismo lugar: no hay que volver a cargar nada.
Dónde lo ves: Panel → pestaña 🤖 Bot → Entrenar al bot → paso Cobros.
2026.10.02.3 — Identificación por RUT en Mikrowisp (Chile) 🪪¶
Mikrowisp busca el documento tal cual lo escribiste en la ficha del cliente: si lo cargaste
como 4664374-7 y el cliente lo dicta como 46643747 (o con puntos, o con la K en
minúscula), no lo encontraba. Y el bloque «Entrada» de los flujos rechazaba cualquier RUT con
guion o con K, así que un cliente chileno no podía ni escribirlo.
Ahora la búsqueda prueba las formas en que un RUT puede estar cargado (con guion, con puntos, con K mayúscula o minúscula) y encuentra al cliente con cualquiera de ellas. En los flujos, la validación «DNI» acepta también RUT con guion. Para los demás países no cambia nada.
Un recordatorio que vale para todos: el bot y la ficha identifican por el móvil cargado en tu sistema. Si un cliente no tiene móvil en Mikrowisp, no hay forma de reconocerlo por su WhatsApp; la primera vez se busca por documento y HybsChat recuerda el par teléfono → documento para la próxima.
Dónde lo ves: No hay nada que configurar. Lo ves en la ficha del cliente en Chatwoot (búsqueda por documento) y en las respuestas del bot cuando pide el RUT.
2026.10.02.2 — Montos sin centavos para Chile y Paraguay 🪙¶
Si facturas en pesos chilenos o guaraníes, tu sistema (Mikrowisp, por ejemplo) muestra 15.000, pero su API nos entregaba 14999.95, y así lo veía tu agente en la ficha del cliente y tu cliente en el bot: un número que no existe en su banco.
Ahora los montos se escriben como en tu país: redondeados al peso y con punto de miles (14999.95 → 15.000). Aplica a la ficha del cliente en Chatwoot (deuda, facturas, pagos, botones de cobro), a lo que el bot le dice al cliente (deuda, factura, QR y link de pago, en los tres modos) y a la nota del comprobante. Para el resto de los países no cambia nada: se siguen mostrando dos decimales.
Lo que se envía a tu sistema o a la pasarela de pago no se toca: sigue siendo el monto exacto.
Dónde lo ves: No hay nada que configurar. Lo ves en Chatwoot, en la pestaña de la ficha del cliente, y en las respuestas del bot.
2026.10.02 — Formas de pago para Chile: RUT y tipo de cuenta 🇨🇱¶
En Chile una transferencia no se puede hacer sin el RUT del titular y el tipo de cuenta (corriente, vista, RUT, ahorro). Hasta ahora las formas de pago solo tenían banco, titular y número de cuenta, así que el bot le daba al cliente una cuenta a la que no podía transferir.
Si tu empresa es de Chile, cada forma de pago tiene ahora dos campos más: el RUT del titular y el tipo de cuenta. El bot los incluye cuando el cliente pregunta dónde pagar, y también salen en el texto de formas de pago que tu agente envía desde la ficha del cliente. El RUT se valida al escribirlo: si el dígito verificador no cuadra, te lo avisa antes de guardar.
Para las empresas de otros países no cambia nada: esos campos no aparecen.
Dónde lo ves: Panel → pestaña 🤖 Bot → paso Cobros → Formas de pago (solo cuentas de Chile).
2026.09.24.2 — Los flujos ya no derivan a departamentos que no existen 🏷️¶
Cuando creabas un flujo desde una plantilla, los bloques de «pasar a un agente» venían con departamentos genéricos —fallas, asesores, ventas, pagos— que casi ningún Chatwoot tiene: los tuyos se llaman soporte técnico, pagos y facturación, comercial, atención al cliente. Al derivar, el bot no encontraba ese departamento y la conversación quedaba sin asignar a nadie, esperando en una cola que nadie mira.
Ahora la plantilla nace con tus departamentos reales, tomados de tu Chatwoot. Si tienes configurado a qué equipo va cada tipo de consulta, se respeta; si no, se busca por nombre.
Y en el editor ves cuál está mal. Si un bloque apunta a un departamento que ya no existe —porque lo borraste o le cambiaste el nombre—, aparece marcado con un aviso en vez de figurar como si fuera válido. Desde ahí puedes elegir otro, crearlo con + o actualizar la lista con ↻.
Y no tienes que rehacer nada: ya corregimos los flujos que tenías. Revisamos los flujos publicados de todas las cuentas y cambiamos esos departamentos genéricos por los tuyos, tal como los tienes en Chatwoot. Donde alguno apuntaba a un equipo que no correspondía —fallas técnicas yendo al área comercial, por ejemplo— quedó apuntando al que corresponde.
Un caso no se pudo corregir solo: si todavía no creaste departamentos en tu Chatwoot, el flujo conserva los nombres de la plantilla hasta que tengas los tuyos. Los creas en la pestaña 👥 Equipo, o desde el mismo bloque del flujo con el botón +.
Dónde lo ves: Panel → pestaña 🤖 Bot → Constructor visual de flujos. Abre tu flujo y mira los bloques «Pasar a agente humano»: ahí están los departamentos, ya con los nombres de tu Chatwoot. Si alguno quedara señalado con un aviso, es que ese equipo ya no existe y conviene elegir otro.
2026.09.22.6 — Las conversaciones que el cliente deja a medias ya no se pierden 👀¶
Tu bot atiende en pendientes y tus agentes trabajan en abiertas. Si un cliente escribe, el bot lo atiende y el cliente se va sin resolver nada, esa conversación se queda en la cola del bot: no la ve nadie hasta que se cierra sola por inactividad.
Ahora lo configuras en la pestaña 🤖 Bot, en Ajustes, y decides las tres cosas:
- Cuánto espera tu bot a que el cliente vuelva. Viene en 0, apagado: hay equipos que quieren verlo todo a los 5 minutos y otros que prefieren la bandeja despejada.
- A qué departamento se deriva. Si eliges uno, la conversación entra en su cola y desde ese momento la atiende una persona: tu bot deja de responder en ella. Si la dejas sin asignar, cualquier agente la ve y tu bot sigue contestando si el cliente vuelve.
- Con qué etiqueta queda marcada, para filtrarlas en Chatwoot y ver cuántas rescataste.
Solo rescata al cliente que quedó esperando. Si el último mensaje es tuyo —un aviso de cobranza, el acuse de un comprobante— no hay nada que atender y la conversación no se toca. Probándolo en una cuenta real, de 11 candidatas por tiempo solo 4 eran clientes esperando respuesta; las otras 7 eran avisos salientes que solo habrían ensuciado la bandeja.
Y solo mira las últimas 2 horas: la idea es que tu agente alcance al cliente mientras todavía espera, no rescatar conversaciones de anteayer.
Dónde lo ves: Panel → pestaña 🤖 Bot → Ajustes: los minutos de espera, el departamento al que se deriva y la etiqueta.
2026.09.22.4 — Tu bot ya no dice que hizo algo que no puede hacer ⚠️¶
Un cliente pedía cambiar la contraseña de su WiFi y el bot respondía «ya la cambié», con detalle y todo: «el servicio se cortará un minuto y volverá solo». No la había cambiado: tu bot no tiene forma de tocar la configuración del equipo del cliente. Puede consultar tu sistema, cobrar, derivar y reiniciar la ONU — nada más.
El daño no era solo la contraseña. El cliente intentaba conectarse con una clave que no existía, el bot le reiniciaba el equipo para «arreglarlo» —cortándole el servicio de verdad—, le hacía revisar cables, y recién después lo pasaba a un asesor. Lo encontramos en tres cuentas.
Ahora, ante un pedido que requiere tocar la configuración (contraseña o nombre del WiFi, cambio de plan, reconexión, cambio de fecha de pago, baja), el bot toma el dato, dice que lo gestiona tu equipo —con el plazo que tengas cargado en tu información, si lo indicas— y lo deriva. Nunca afirma haberlo hecho.
Y los datos que el cliente dicta se copian tal cual. En este caso la contraseña terminaba
en punto (Akira@Rika22#.) y el bot la repitió sin el punto, así que el cliente no coincidía
con la que después se configuró. Ahora la repite entre comillas, con su puntuación, y pregunta
si es exactamente así antes de pasarla a tu equipo.
Si ofreces el cambio de contraseña como servicio, conviene que en tu información diga el plazo real (por ejemplo «dentro de 24 horas»): el bot lo usa al responder.
Dónde lo ves: No hay nada que configurar: se nota en las respuestas de tu bot. Si pides el cambio de contraseña como servicio, el plazo lo cargas en 🤖 Bot → Bot AI conversacional, en la información que le das a tu bot.
2026.09.22.3 — Si cargas los teléfonos con el 0 adelante, ya reconocemos a tus clientes 🇪🇨¶
En Ecuador y Venezuela los teléfonos se cargan con el cero delante (0939066720), y WhatsApp
los entrega con el código del país y sin ese cero (593939066720). Nosotros buscábamos solo
esta última forma: no coincidía con ninguna ficha, y el cliente que te escribía aparecía como
desconocido aunque lo tuvieras cargado. Tu agente tenía que buscarlo a mano en tu sistema en
cada conversación.
Ya probamos las dos formas, en los dos lugares donde hacía falta: la consulta directa a tu sistema y el índice interno que usamos para las carteras grandes (ese índice quedaba completamente sin usar por este motivo).
Lo verificamos con clientes reales de un ISP ecuatoriano: los que antes no aparecían, ahora salen con su nombre. No tienes que cambiar cómo cargas los teléfonos ni volver a cargar nada.
Dónde lo ves: No hay nada que configurar. Lo ves en la ficha del cliente, dentro de la conversación: aparece con su nombre en vez de pedirle el documento.
2026.09.22.1 — El interesado que ya diste por perdido ahora sí queda registrado ✅¶
Tres arreglos en la captación de interesados, todos del mismo problema: el bot juntaba los datos y después no hacía nada con ellos.
- Ahora sí los registra en tu sistema. Si tienes cargado un guion de contratación que pide varios datos (referencias del sector, color de la vivienda, una foto del domicilio), el bot los seguía pidiendo sin registrar nunca la solicitud: quedaba todo en la conversación. Ahora registra en cuanto tiene nombre, documento y dirección, y el resto lo pide después o se lo deja a tu asesor, que recibe la conversación completa.
- Dejó de preguntar lo que ya le dijiste. A quien abría con «quiero contratar internet», el bot le preguntaba igual «¿ya eres cliente o quieres contratar?». Un mensaje menos por cada interesado.
- Y no te pide permiso para algo que no puede hacer aunque no tengas cargadas tus zonas de cobertura. Este arreglo salió en la versión anterior a medias: funcionaba solo si tenías el mapa configurado.
También corregimos algo que afectaba a todos: cuando el bot no encontraba un documento, la instrucción interna le decía que registrara al interesado incluso en las cuentas que no tienen la captación activa — una herramienta que no existía ahí. Ahora en esas cuentas deriva a tu equipo comercial, que es lo que corresponde.
Dónde lo ves: Panel → pestaña 🤖 Bot → Bot AI conversacional, donde activas la captación de interesados. Las solicitudes que registre el bot te llegan a tu sistema de gestión.
2026.09.21.7 — Menos preguntas para registrar a un interesado 📝¶
Afinamos la captación de interesados, que ahora acompaña al orden nuevo (cobertura → datos → planes):
- Ya no te pide permiso para algo que no puede hacer. Si tu cuenta no tiene la consulta de documento por RENIEC, el bot dejó de pedir autorización para verificar la identidad — consultaba, no podía, y terminaba pidiendo el nombre igual. Ahora te lo pide directo: un paso menos para el interesado.
- Al registrar la solicitud, ahora sí le muestra los planes. Antes la conversación se cerraba con «un asesor te contactará» y el interesado se quedaba sin ver un solo precio.
- Y ya no dice «un asesor validará la cobertura» cuando el bot acaba de confirmarla con tu mapa. Ahora cierra con que un asesor lo contacta para coordinar la instalación.
Dónde lo ves: Panel → pestaña 🤖 Bot → Bot AI conversacional, en la captación de interesados.
2026.09.21.6 — Cobertura primero, después los datos, al final los planes 📍¶
Si tienes cargadas tus zonas de cobertura, tu bot ahora atiende a un interesado en el orden que tiene sentido para un ISP:
- Primero la cobertura. Le pide la ubicación y valida si llegas a su zona — antes de pedirle un solo dato.
- Después sus datos. Recién con la cobertura confirmada le pide nombre y dirección.
- Al final los planes, con tus velocidades y precios.
Antes era al revés: le pedía documento y dirección, y la cobertura quedaba para el final. El interesado daba todos sus datos para enterarse recién ahí de que todavía no llegas a su zona, y tu asesor recibía una solicitud que no se podía instalar.
Y si no hay cobertura, ya no le muestra precios. Le dice con amabilidad que todavía no llegas, sin prometer instalación, y registra su interés para cuando amplíes.
Un detalle que veníamos arrastrando: aunque tuvieras tus planes cargados, el bot tenía prohibido dar precios y mandaba todo a un asesor. Ahora sí los ofrece — lo que sigue confirmando un asesor es la fecha y el costo de instalación, que es lo que corresponde.
No tienes que configurar nada: si ya cargaste tus zonas en el mapa, tu bot ya atiende así.
Dónde lo ves: Panel → pestaña 🤖 Bot → 📍 Verificación de cobertura. Ahí cargas tus zonas en el mapa; con eso el bot ya atiende en este orden.
2026.09.21.5 — El bot reconoce a tu cliente aunque su número esté cargado de otra forma 🌎¶
Seguimos con lo de ayer, que se quedaba corto en tres puntos:
- Cuando el cliente tiene dos números en la misma ficha. El listado que usa el bot para desempatar entre varias cuentas todavía buscaba con el código de país pegado. Ahora busca igual que la búsqueda principal.
- El nombre del cliente en tu bandeja. El contacto de WhatsApp se quedaba sin nombre aunque el cliente estuviera en tu sistema. Ahora aparece con su nombre completo desde el primer mensaje, que es lo que ve tu agente cuando toma la conversación.
- Si cargas los teléfonos con el 0 adelante. En Ecuador (
0992185891) y Venezuela (5804126556956) la comparación era demasiado estricta y descartaba al cliente correcto por culpa de ese cero. Ya no.
Esto último también vale si usas Mikrowisp o Wispro, no solo WispHub.
Nada que configurar: tus teléfonos se quedan como están.
Dónde lo ves: No hay nada que configurar. Lo ves en la conversación: el contacto aparece con el nombre del cliente desde el primer mensaje.
2026.09.21.4 — Tu bot vuelve a reconocer a tus clientes por su número 📱¶
Si usas WispHub, esto te cambia la atención. WhatsApp entrega siempre el número con el
código del país (51987654321), y en tu sistema los clientes suelen estar cargados sin él
(987654321). Tu bot buscaba tal cual llegaba, no encontraba a nadie, y terminaba pidiéndole
el DNI a todo el mundo — incluso a quien ya tienes registrado hace años.
Ahora prueba también sin el código de país. Medido en un ISP real: de 0 clientes identificados pasó a 20 de cada 25.
Para tus clientes significa que el bot los saluda por su nombre y ya sabe cuál es su servicio desde el primer mensaje, sin hacerles buscar el documento. Y si tienes varios números de WhatsApp, funciona igual en todos: la identificación no depende del número por el que te escriban.
No tienes que hacer nada ni cambiar cómo cargas los teléfonos.
Dónde lo ves: No hay nada que configurar. Lo ves en la conversación, y funciona igual por cualquiera de tus números de WhatsApp.
2026.09.21.3 — Las averías ya no son todo o nada 🎯¶
Cuando declaras una avería, ahora eliges qué alcance tiene, porque casi nunca se cae la red entera:
- Un sector — un poste caído, una fibra robada, un puerto de tu OLT quemado. Tu bot avisa solo a los clientes que de verdad están sin señal. Quien te escriba por una factura, o por cualquier otra cosa, no recibe ningún aviso de corte.
- Toda tu red — un tramo troncal. Tu bot avisa a cualquiera que escriba.
Y si tienes tu OLT conectada, lo distingue solo. Si las caídas se concentran en uno o dos puertos, lo trata como un sector; si están repartidas por tu red, como una avería general. Por muchos clientes que tenga el puerto, un solo puerto es un sector: un puerto quemado con 60 clientes ya no hace que tu bot le avise a los otros 1.400 que están navegando sin problemas.
Para declarar un sector por tu cuenta no necesitas saber qué puerto es: tu bot mira el equipo de cada cliente que escribe y le avisa solo si es uno de los afectados.
Toda avería se cierra sola a las 12 horas. Si la declaras un viernes, arreglas el corte y te olvidas de darla por resuelta, tu bot no puede quedarse todo el fin de semana diciéndole a tus clientes que hay una avería. Si el corte sigue, se vuelve a declarar sola o la reactivas con un clic.
También: el tab de Campañas volvió a cargar normalmente. Abrirlo dos veces seguidas podía mostrarte un error que no era tal.
Dónde lo ves: Panel → pestaña 📊 Resumen → 🔧 ¿Se te cayó la red? Avisar de una avería. Ahí eliges el alcance cuando declares el corte.
2026.09.21.2 — Cuando se te cae la red, tu bot deja de hacer preguntas 🔧¶
Nuevo: el botón de avería, arriba de todo en tu Resumen. Cuando se corta una fibra, lo activas y tu bot cambia de comportamiento con todos los que escriban:
- Les avisa que hay una avería, sin pedirles el DNI ni hacerles revisar el router.
- Etiqueta cada conversación como
averia, así tus agentes ven juntos a todos los afectados. - Las deriva a soporte.
Puedes indicar la zona y escribir tu propio mensaje. Si lo dejas vacío usamos uno que explica el corte sin prometer horarios que después no se cumplen. Cuando se restablece, un botón lo apaga y tu bot vuelve a atender normal.
Y si tienes tu OLT conectada, se da cuenta solo. Cada 5 minutos miramos cuántos equipos se quedaron sin señal óptica en las últimas 2 horas. Si son muchos a la vez, la avería se declara sola — justo en los primeros minutos, que es cuando te llegan todos los mensajes y a veces ni te enteraste todavía. Solo contamos las caídas recientes: un equipo apagado hace una semana no es un corte.
Además, tu bot dejó de dar un consejo que no servía. Cuando la fibra que llega al domicilio está cortada, ya no le pide al cliente que revise el router, los cables o las luces: le dice claro que el problema no está en su casa y lo pasa a soporte como avería. Antes le decía «tu fibra está cortada» y en la misma frase «verifica las luces de tu equipo».
Ahora distinguimos tres situaciones que antes se trataban igual: la fibra cortada (es la red), el equipo sin energía (es un corte de luz en la casa) y el equipo que no responde por causa desconocida.
Dónde lo ves: Panel → pestaña 📊 Resumen → 🔧 ¿Se te cayó la red? Avisar de una avería.
2026.09.21.1 — Tu bot acepta comprobantes que antes rechazaba 🧾¶
Los comprobantes sin número de operación ya sirven. Muchos bancos y casi todas las transferencias no imprimen un número de operación, y tu bot los rechazaba aunque leyera bien el importe, la fecha y quién pagó. Ahora los acepta: reconoce el pago por su combinación de cliente, importe, fecha y banco.
En los datos se veía el problema del lado de tu cliente: el mismo comprobante enviado cuatro veces seguidas, rechazado las cuatro, sin que nadie le dijera qué faltaba. Ahora el primero se procesa y, si lo reenvía, tu bot le responde que su pago ya está registrado.
La protección sigue intacta: el importe se compara con tu factura, la fecha tiene que ser reciente, y si configuraste a quién deben pagarte, eso se valida igual. Lo único que cambia es cómo reconocemos que dos comprobantes son el mismo pago.
Y los comprobantes argentinos dejaron de fallar por el formato. Los identificadores de las transferencias en Argentina son códigos largos con letras y números, y nuestra verificación estaba pensada para los formatos peruanos: los daba por inválidos. Lo mismo pasaba con los códigos largos de Mercado Pago. Afectaba a ISP de los dos países.
Si usas comprobantes por WhatsApp, deberías ver bastantes menos rechazos esta semana sin tocar nada.
Dónde lo ves: Panel → pestaña 🧾 Comprobantes. Los que antes se rechazaban por no traer número de operación ahora aparecen validados.
2026.09.20.3 — El panel te dice qué significa «modo prueba» 🧪¶
En Cobros, una pasarela en modo prueba se veía con las etiquetas «TEST» y «ACTIVA» una al lado de la otra, que juntas dan a entender que está cobrando. Es lo contrario: en modo prueba tu bot no le ofrece pagos a tus clientes, justamente para que puedas configurarla tranquilo sin exponerlos.
Ahora te lo dice con todas las letras, y te deja un botón para pasar a producción ahí mismo, sin volver a cargar tus llaves.
Y la ficha muestra el dato correcto de cada pasarela. Antes mostraba siempre «Shop ID»,
que es de Izipay, así que una cuenta de Culqi bien configurada aparecía con un ? y parecía
incompleta. Ahora cada una muestra lo suyo: Izipay su Shop ID, Culqi su llave pública.
Dónde lo ves: Panel → pestaña 💳 Cobros → 🤖 Pagos por el chat, en la tarjeta de cada pasarela.
2026.09.20.2 — Tú eliges qué forma de pago ofrece tu bot 🎛️¶
Si tienes activas las dos formas de cobro —el link de pago y el código con QR—, ahora decides tú cuál ofrece tu bot cuando un cliente quiere pagar. Lo eliges en el asistente de tu bot → paso Cobros:
- El link de pago, si tus clientes suelen pagar con tarjeta o Yape.
- El código con QR, si la mayoría paga en efectivo o desde su billetera.
Tu bot ofrece la que elegiste, y la otra solo si tu cliente la pide. Nunca las dos en el mismo mensaje, para no confundirlo.
Antes lo decidía el bot según lo que fuera entendiendo de la conversación, y no tenías forma de saber qué iba a recibir tu cliente. Esa decisión es tuya: conoces a tus clientes mejor que nosotros.
Si tienes una sola forma activa no cambia nada, y la opción ni siquiera aparece: no hay nada que elegir.
Dónde lo ves: Panel → pestaña 🤖 Bot → Bot AI conversacional, donde eliges qué forma de pago ofrece primero.
2026.09.20.1 — Ya puedes cobrar con QR desde Yape o Plin, y en agentes de banco 🧾¶
Tu bot ahora le manda a tu cliente un código con su QR, y tu cliente elige cómo pagarlo:
- Escanea el QR con Yape, Plin o la app de su banco.
- Paga en efectivo dictando el código en cualquier bodega o agente: BCP, BBVA, Interbank, Full Carga.
- Lo ingresa en su banca móvil, en «Pago de servicios → PagoEfectivo».
En los tres casos su factura se marca como pagada en tu sistema automáticamente, igual que con el link de pago.
Hasta hoy, el cliente sin tarjeta tenía que ir a tu oficina o mandarte una foto del comprobante para que alguien la revisara a mano. Es el grupo que más trabajo te daba y el único que no tenía ninguna opción automática.
Le llega un solo mensaje con el QR y el código juntos. Y puede reenviárselo a un familiar para que se lo pague desde otro teléfono — el QR ya lleva el monto de la factura adentro.
Lo activas en el asistente de tu bot → paso Cobros → «Pago con QR o en agentes». Viene apagado: el monto mínimo es S/ 6 y la comisión del efectivo la fija Culqi y no es la misma que la de tarjeta, así que conviene que la confirmes con tu ejecutivo antes de encenderlo. Por ahora funciona con Culqi.
Cuándo llega el QR y cuándo solo el código. El QR viaja junto al código siempre que tu pasarela esté con sus llaves de producción. Si estás probando con llaves de prueba, tu cliente recibe solo el código: el QR que devuelve el modo de pruebas trae un importe que no es el de la factura, y preferimos no mandarlo antes que mandarte uno equivocado.
Ahora sabes qué medios de pago acepta tu cuenta de Izipay. En Cobros → Probar conexión te decimos exactamente qué tiene habilitado tu tienda: tarjetas, Yape, Plin, QR. Si te falta alguno, el trámite es con tu ejecutivo de Izipay —se habilitan de su lado, no desde aquí—. Antes solo decía «conexión OK» y no había forma de saberlo.
Y si tu pasarela está en modo prueba, el asistente te lo dice. Antes avisaba que «no tienes ninguna pasarela activa» a quien tenía una configurada y en pruebas, y te mandaba a configurarla de nuevo. Ahora te explica que mientras esté en pruebas tu bot no le ofrece pagos a tus clientes, y te lleva directo a pasarla a producción.
Dónde lo ves: Panel → pestaña 💳 Cobros → 🤖 Pagos por el chat.
2026.09.19.1 — Cobrar con Yape y tarjeta por Culqi, y tu factura se cierra sola 💳¶
Culqi ya cobra de verdad, con Yape y con tarjeta. Lo probamos de punta a punta con un ISP: tu cliente toca el link, paga con Yape o con su tarjeta, y el cobro llega a tu cuenta de Culqi. Si tenías Culqi configurado y nunca te funcionó un cobro, esta es la razón y ya está resuelto.
Configurar tu pasarela volvió a funcionar. El botón de guardar en Cobros no hacía nada al tocarlo — ni guardaba ni avisaba del error. Si intentaste conectar Izipay o Culqi y te quedaste con la sensación de que la pantalla no respondía, no era tu navegador. Ya funciona, y «Probar conexión» ahora te dice si la llave está mal y cuál de las dos revisar.
Cuando te pagan por la pasarela, tu factura queda PAGADA. Antes se registraba una promesa de pago a tres días y alguien de tu equipo tenía que cerrarla a mano. No tiene sentido: el dinero ya entró y la pasarela lo confirmó. Ahora la factura se marca como pagada en tu sistema, con el origen del cobro y el número de operación. Si por algo no se puede cerrar, se registra la promesa como antes y queda anotado el motivo — nunca se pierde.
Podés configurar la pasarela sin que tus clientes la vean. El modo prueba ahora hace lo que promete: mientras esté activado, tu bot NO le ofrece el link de pago a nadie, así podés cargar tus llaves de prueba, cobrarte a vos mismo y revisar que todo esté bien antes de abrirlo. Al pasar a producción, el bot empieza a ofrecerlo solo. La pantalla de pago también te recuerda, mientras estés en prueba, qué tarjeta y qué número de Yape usar.
Un detalle de Yape que conviene saber: aparece como medio de pago a partir de S/ 6. Por debajo de ese monto, el cobro va con tarjeta. Es un límite de Culqi, no nuestro.
Dónde lo ves: Panel → pestaña 💳 Cobros → 🤖 Pagos por el chat, en la tarjeta de Culqi.
2026.09.18.4 — Teléfonos con cero adelante, y avisos que no salían¶
El cero de adelante ya no rompe el aviso. Si en tu sistema los teléfonos están guardados como los tipeó un operador —0980887727 en vez de +593980887727— el aviso fallaba en silencio. Ese cero es el prefijo de larga distancia nacional y no forma parte del número internacional; ahora se descarta solo. Eran cientos de avisos al mes que no llegaban.
Cuando algo falla, ahora se dice por qué. Si tu sistema de WhatsApp rechaza un contacto, el motivo exacto queda registrado en vez de un mensaje genérico. No lo ves tú, pero es lo que nos permite arreglarte un problema en minutos en vez de en meses.
2026.09.18.3 — «Mensajes del mes» ya muestra un número de verdad¶
En Recursos del plan siempre hubo un contador de «Mensajes del mes». Mostraba 0 para todo el mundo, desde siempre: nadie lo llenaba.
Ahora lo llena la medición diaria. Muestra todos los mensajes que le salieron a tus clientes este mes, por cualquier canal. Cuáles te cobra Meta y cuáles no lo desglosa el bloque de arriba.
Dónde lo ves: Panel → pestaña 📊 Resumen → 💬 Mensajes de este mes.
2026.09.18.2 — Ajustes internos¶
Mejoras en las herramientas de administración de HybsChat. No cambia nada de lo que ves en tu panel.
2026.09.18.1 — Ya puedes ver cuántos mensajes mandas (y cuánto te van a costar)¶
Desde el 1 de octubre, Meta cobra los mensajes de servicio: todo lo que el bot o un agente le escribe a tu cliente dentro de las 24 horas siguientes a que él te escribió. Hasta ahora eso era gratis e ilimitado.
En tu Resumen hay un bloque nuevo que te lo muestra antes de que llegue la factura:
- Cuántos te cobra Meta este mes, y cuánto suman en dólares
- Cuántos NO te cuestan nada — los que salen por WhatsApp con QR, Telegram o el chat de tu web
- Qué parte escribe el bot y qué parte tu equipo
- Quién de tu equipo escribe más
- Una proyección al cierre del mes, al ritmo que llevas
Por qué el número importa. Varios mensajes cortos seguidos cuestan lo mismo que varios mensajes. Un «hola», un «dime», un «ya reviso» y un «listo» son cuatro cobros donde cabía uno. Y cada conversación que el bot resuelve solo cuesta menos de la mitad que una que termina en un agente.
Dos aclaraciones para que el número se entienda. Las notas internas no se cuentan: no salen a WhatsApp y Meta no las cobra. Y el costo es una estimación — la tarifa la fija Meta y cambia según el país.
Dónde lo ves: Panel → pestaña 📊 Resumen → 💬 Mensajes de este mes.
2026.09.17.20 — «Solo recibir» ahora de verdad no toca nada¶
Los tres modos del bloque de comprobantes son:
| Modo | Qué hace el bot |
|---|---|
| Pago directo | Marca la factura pagada en tu sistema |
| Pago con promesa | Reporta el pago y le da días de plazo al cliente |
| Solo recibir | Lee el comprobante y te deja la nota. Nada más |
El bot por flujos siempre respetó el tercero. El bot por IA no: en «solo recibir» igual reportaba el pago a tu sistema, y la factura te quedaba en revisión — un pendiente que nunca pediste.
Corregido. Ahora en ese modo el bot no acredita, no reporta y no crea prórrogas. Lo que sí hace, que es lo que prometía el nombre: guarda el comprobante, extrae los datos y deja una nota clara en la conversación, con el monto, el número de operación y el aviso de que tu sistema quedó intacto. Al cliente le dice que lo recibió y que un agente lo valida — no que quedó registrado, porque no quedó.
2026.09.17.19 — El bot por IA aprende lo del bot por flujos¶
Todo lo que se corrigió hoy probando el bot por flujos con un ISP en vivo tenía su versión gemela en el bot por IA. Se llevó allá.
Las prórrogas automáticas ahora cuentan. Cuando el bot por IA daba un plazo junto a un comprobante, lo creaba en tu sistema sin mirar tu tope ni anotarlo. O sea: el cliente al que le permitías una prórroga por mes recibía una por cada comprobante que mandara, y el contador que ves en la ficha no la registraba. Ahora respeta el tope y queda contada, venga por donde venga.
El plazo ya no depende de que el reporte funcione. Estaba al revés: si el reporte a tu sistema fallaba —la foto no se pudo subir, tu sistema no respondió— el cliente se quedaba sin prórroga. Es justo cuando más falta hace, porque nadie va a acreditarle nada en el acto.
«Reportado» significa reportado. Un comprobante se marcaba como reportado con que el OCR lo diera por bueno, aunque el envío a tu sistema hubiera fallado. Ahora se marca sólo cuando de verdad entró.
Cuando paga un familiar, el bot lo resuelve en el chat. Si el comprobante está bien de monto y de cuenta pero figura a nombre de otra persona, el bot pregunta una vez si el pago es suyo. Si el cliente dice que sí, queda registrado y la nota al agente dice quién pagó — antes esa confirmación no cerraba nada y el comprobante seguía figurando como rechazado, listo para que alguien lo acreditara por segunda vez.
2026.09.17.18 — Los comprobantes del bot por flujos ya figuran como reportados¶
En la pestaña Comprobantes, los que el bot por flujos había reportado a tu sistema aparecían igual con el aviso de no reportado.
El riesgo era concreto: lo leías, ibas a tu sistema a cargar el pago a mano, y le cobrabas dos veces al mismo cliente.
Ahora la ficha se marca cuando el reporte de verdad entró. Si falló, sigue diciendo «no reportado» — que ahí es justamente lo que corresponde hacer.
2026.09.17.17 — Ya puedes ver (y corregir) las prórrogas que dio el bot¶
Si pusiste un tope de prórrogas por cliente, el bot lo cuenta con su propio registro. Hasta ahora ese registro no se veía desde ningún lado: el cliente leía «ya tienes una prórroga activa este mes», ibas a tu sistema, no encontrabas ninguna, y no había manera de saber de dónde salía.
Ahora la ficha del cliente lo dice:
Prórrogas: 1 de 1 este mes · la última el 17/09 por 3 días, desde el bot. El bot no le va a dar otra.
Y trae un botón Liberar cupo.
Para qué sirve. Las prórrogas se crean en tu sistema, pero tu sistema no nos deja leerlas de vuelta. Así que si anulas una por tu cuenta —el cliente terminó pagando, se la diste por error, o estás probando el bot— nuestro contador se queda con la cuenta vieja y no tiene cómo enterarse. El botón es esa manera.
Liberar el cupo no toca tu sistema y no otorga nada. Sólo le borra al bot el recuerdo de las prórrogas que ya le dio a ese cliente, para que pueda darle otra. Queda una nota en la conversación con quién lo hizo: habilitar una prórroga más sobre una deuda sin cobrar tiene que poder rastrearse.
2026.09.17.16 — Tu equipo ya ve qué opciones le ofreció el bot al cliente¶
En Telegram y en el chat de tu web, el menú del bot le llega al cliente como botones. Pero en tu bandeja aparecía solo la pregunta: el agente que recibía la conversación no sabía entre qué opciones había elegido.
Ahora, junto al menú queda una nota interna con la lista:
🔘 Opciones que vio el cliente: · 💰 Consultar deuda · 💳 Solicitar QR · 📸 Enviar comprobante de pago
Es una nota privada: tu cliente no la ve.
2026.09.17.15 — Lo que tu cliente elige se lee bien en el chat¶
Cuando el cliente tocaba un botón en Telegram o en el chat de tu web, en tu bandeja aparecía un código interno —opt_cliente— en vez de lo que realmente eligió. Un agente que abría la conversación no entendía nada.
Ahora se lee tal cual: «👤 Soy cliente».
2026.09.17.14 — Cada comprobante dice a qué factura corresponde¶
En la pestaña Comprobantes varios registros no decían contra qué factura se habían validado, así que no había forma de cruzarlos ni de saber cuál quedaba saldada. Ahora todos la traen, incluidos los que quedan pendientes de tu revisión.
Y cuando el cliente debe varias facturas y paga una, se anota exactamente la que pagó, no la primera de la lista.
2026.09.17.13 — Botones de verdad en Telegram y en el chat de tu web 🔘¶
Hasta ahora, fuera de WhatsApp los menús del bot salían como una lista numerada y el cliente tenía que escribir 1, 2… Funcionaba, pero se siente viejo y se presta a que escriban cualquier otra cosa.
Ahora en Telegram y en el chat de tu web las opciones llegan como botones: el cliente toca y listo. Lo mismo para la pregunta de si registrar un pago hecho por otra persona.
Tus flujos no cambian: las mismas opciones que ya tienes se dibujan como botones solas.
En WhatsApp sigue igual (ya usaba las listas nativas de Meta) y en el WhatsApp por QR se mantiene el menú numerado, que es lo que ese canal admite.
Versiones anteriores¶
- Septiembre de 2026 — 80 versiones
- Agosto de 2026 — 77 versiones
- Julio de 2026 — 22 versiones