199 publicaciones en agosto de 2026.
Regenerada con scripts/generar-novedades.mjs. Entra el trabajo de prospección del 27 al 29 y todo lo de Comercia 24 de estos dos días: presupuestos modelo, las dos formas de contratar con la implantación solo en la mensu…
De 469 a 600 entradas.
Estaba deshabilitado al editar: solo se podía poner al crear la ficha. La intención era buena -el teléfono es único por organización y es la clave con la que se reconocen las llamadas y los WhatsApp entrantes- pero dejab…
Ahora se escribe, y si la ficha ya tenía número se avisa de que lo que llegue del viejo dejara de asociarse. Un choque con otra ficha se explica en castellano en vez de soltar el error de la clave única.
Si el presupuesto lleva introducción, esa es la que se manda: está escrita para ese cliente y dice mejor lo que se le quiere contar que ninguna frase hecha. Sin introducción, el texto generico de siempre.
Manda igual lo escrito a mano en el dialogo de envio, que sigue siendo lo primero. El orden es: mensaje a mano > introducción > texto generico.
Arrastrar solo servía para cambiar de etapa; dentro de una, el orden lo decidía la base de datos. El orden de una columna es de quien la lleva: arriba lo que hay que atender hoy.
- Una raya azul marca en que hueco va a caer, según se suelte en la mitad de arriba o la de abajo de una tarjeta. Arrastrar a ciegas era soltar y ver. - Al soltar se renumera la columna entera, no solo la tarjeta movida: si no, dos acabarian compartiendo posición y el orden volvería a ser el que quisiera la base de datos.
El epigrafe y lo seleccionado pasan a rojo, y la línea que separa el epigrafe de la lista a negro. El rojo de lo seleccionado es solo de Favoritos: sirve para distinguir la misma pantalla alcanzada por el atajo de la alc…
La estrella se repetía en las cuatro filas sin decir nada que el epigrafe no dijera ya. Cada favorito lleva ahora el icono de su entrada del menu, que es como se reconoce la pantalla de un vistazo.
Una lista corta de atajos bajo la Guía de implantación, propia de cada persona: dos comerciales de la misma empresa viven en pantallas distintas.
Se marcan con la estrella de la barra superior, no con un formulario: se pulsa desde la pantalla en la que ya estas. El nombre lo saca del propio menu, así que el favorito se llama igual que la entrada que ya conoces, y en una pantalla que no está en el menú la estrella no se pinta -no habría nombre que darle-.
La columna sacaba total_cents, que es el pago único. Un presupuesto de pura cuota -1.208,79 EUR al año- aparecía a 0,00 EUR en la lista: parecía que no valía nada.
Borrar era definitivo y además silencioso hacia abajo: líneas, bloques e historial de envios cuelgan con ON DELETE CASCADE, así que con el documento se iba la prueba de que se había enviado y de que el cliente lo había r…
- Borrar pasa a marcar (deleted_at). Las filas hijas siguen enganchadas, de modo que recuperar devuelve el presupuesto entero, con sus envios. - Vista de papelera con recuperar y borrar-para-siempre, y pg_cron purga cada noche lo que lleve más de 30 días. - Lo que el cliente YA ha abierto no se edita ni se borra: el documento existe fuera de esta pantalla.
Dos huecos que se notaron el mismo día que un envio se bloqueo sin avisar:
- "Enviado" en la columna Estado solo dice que se ordeno el envio. Un correo bloqueado o rebotado se leía exactamente igual que uno entregado y abierto. La columna nueva cuenta lo más avanzado que se sepa -visto, entregado, salido- y un fallo manda sobre todo lo demas, que es lo único que exige hacer algo.
El webhook de Brevo solo anotaba "entregado" y "abierto" en los envios de presupuesto. Un blocked, un hard_bounce o un spam se descartaban en silencio: la fila seguía diciendo "Enviado", sin error, aunque el correo no hu…
Caso real: oriberehabilitacio@gmail.com, evento "blocked" cuatro segundos después del envio, descartado. Ahora queda como fallido y con el motivo.
Se elegía de uno en uno y el modal se cerraba tras cada elección: montar un presupuesto de seis modulos eran seis viajes de abrir, buscar y cerrar.
De paso, la línea en blanco que estorbaba delante de lo recien elegido se descarta si no tenía concepto.
canPay miraba total_cents, que es solo la implantación. En un presupuesto de pura suscripción -sin implantación- valía cero, así que el botón de pagar no aparecía nunca: el cliente aceptaba la anualidad de 1.208,79 EUR y…
La pasarela solo aceptaba tarjeta, así que anunciar Klarna en la propuesta habría sido prometer algo que el cobro no podía cumplir.
Con red: si la cuenta de Stripe no tiene Klarna activado, crear la sesión falla y no se podría cobrar NADA. Ante ese error concreto se reintenta con tarjeta sola, como funcionaba hasta ahora.
El logo de la marca iba al lado del titular y sin encoger, así que en 375px el h1 se quedaba en 74 pixeles: el asunto salía partido en tres líneas y pisado por el logo. En móvil el logo pasa arriba, como un membrete.
En la barra superior no cabian logo, botón y referencia: la referencia se cae -está repetida en el recuadro 'Para', que es donde se busca- y el botón se queda en 'PDF'. Y la hoja pierde margen interior, que en 375px se comía casi una quinta parte del ancho.
Seis columnas no entran en 390px. Como la tabla es w-full no desplazaba, se encogía: la descripción acababa en una columna de dos dedos con una palabra por línea.
El texto propuesto se guardaba en email_message en cuanto abrias el modal de envio, y a partir de ahi era indistinguible de uno escrito a mano: el presupuesto quedaba congelado con la redacción de aquel día y ninguna mej…
Ahora solo se guarda si lo has tocado tu. En blanco, se compone al vuelo con el texto del momento.
Los precios viven en la propuesta, donde van con su contexto: que entra en cada opción, que no, y que pasa a partir del segundo año.
De paso, el impreso decía lo contrario que la propuesta web -"el pago inicial es el mismo en ambas"- y calculaba el ahorro sin descontar la implantación que el anual se salta. Dos cifras distintas para lo mismo según se mirase el PDF o el enlace.
Una columna entera de rayas ocupa ancho y no cuenta nada. El pie ajusta su colSpan en consecuencia, que si no se descuadraba la tabla al ocultarla.
El detalle cuenta QUE se compra y las tarjetas COMO se paga. Sin nada que los separase, las tarjetas parecían la última fila de la tabla.
Además, cada fila de la tabla es un modulo entero con su texto y su imagen, no un renglon: pasa a respirar como tal. Y otro escalon de aire entre fichas.
Implantación, mes y año son del mismo rango. Uno iba en negrita y los otros en gris pequeno, así que la cuota -que suele ser lo que de verdad se cobra- parecía una nota al pie.
De paso, el precio unitario en blanco se pinta como raya y no como 0,00 EUR: un cero al lado de '39,00 EUR/mes' se lee como que eso es gratis.
Es una promesa economica que sale impresa en la propuesta, así que vive en cada presupuesto y no escrita a fuego: hay ofertas donde no aplica, y una rebaja prometida por descuido es una rebaja que hay que dar.
Se dice con su cifra y no solo con el porcentaje: un "33% menos" obliga al cliente a hacer la cuenta, y el importe ya hecho es lo que se recuerda. Aparece en las dos tarjetas, porque la rebaja le toca a las dos cuotas.
El salto entre lo presupuestado y lo que solo se ofrece no es el de un modulo al siguiente: es otra categoría de cosa y necesita leerse así.
Tres cosas de la propuesta que ve el cliente:
- El pie con Subtotal / IVA / PAGO INICIAL sobraba habiendo cuotas: ese total es solo la implantación y repetía -contradiciendola- la cuenta de las dos tarjetas de contratación. Se queda solo cuando se paga una vez. - Los modulos iban pegados.
Se llamaba "No en anual" -decía lo que NO pasa- y solo aparecía si el presupuesto ya tenía precio anual. Quien monta la implantación la pone antes que las cuotas, así que la casilla no estaba cuando hacía falta y más tar…
Donde se lee entero -los totales del editor y la propuesta del cliente- va el nombre completo. En la columna de cada línea va "Implantación" a secas: es un campo de 7rem y además esa misma casilla sirve para un hardware…
El panel de importes era un desglose del pago único con las cuotas de nota al pie: en un presupuesto de suscripción coronaba la pantalla con cuatro filas de 0,00 EUR y dejaba en gris pequeno la cifra que decide la venta.
Solo hay dos maneras de contratar, y ahora se pintan como lo que son: dos facturas distintas, cada una con su base y su IVA. La mensual lleva el cargo inicial; la anual se paga entera y se lo ahorra.
Pago único, mes y año son tres conceptos del mismo rango y se pintaban como uno grande y dos notas al pie: en un presupuesto de suscripción eso dejaba la cifra que decide la venta en letra pequena y coronaba la pantalla…
Y el fondo del asunto: el modelo es implantación + cuota mensual, O anualidad sin implantación. El código hacía lo contrario y lo decía en voz alta -"el pago inicial es el mismo en ambas"-, sumando el alta a las dos.
Una plantilla era una cabecera de textos más una lista de ids del catálogo con cantidad. La línea de presupuesto, mientras tanto, aprendio a ser opcional, a llevar cuota mensual, imagen, enlace, sección y descripción.
En vez de perseguir a c24_quote_lines campo a campo, un modelo pasa a ser un presupuesto con is_template. Así se edita con el editor entero y sacar un presupuesto de el es duplicarlo, que ya estaba escrito.
El catálogo se llena de variantes del mismo servicio y rehacerlas era copiar y pegar ocho campos. La copia se lleva imagenes y margen, nace desactivada -el presupuestador con IA lee el catálogo- y abre su ficha.
Arrastra los dos sitios que llamaban a esa entrada por su nombre viejo: el aviso del editor de presupuestos y la ficha de la Guía.
Los tres puntos iban en gris claro y sin caja: en una tabla llena de texto pasaban por adorno. Borde, fondo propio y glifo mayor, y marcado mientras el desplegable está abierto para saber de que fila cuelga.
Las videollamadas no se podían quitar de la agenda: viven en `meetings` y solo el modal de evento tenía botón de borrar.
El desplegable no decía el número, así que había que elegir a ciegas y esperar a que cargara la lista para saber si esa vía traía diez fichas o veinte mil.
Los recuentos llevan los mismos filtros que la lista menos la vía, que es lo que se está eligiendo. De paso, los cinco que hace esta pantalla comparten un solo sitio donde se aplican los filtros y van en paralelo.
De los 80 municipios de Valencia se perdieron tres —Xirivella, Catarroja y Algemesi— sin que nadie lo dijera. Los tres dieron 502 en prospecting-search (Outscraper rechazando el arranque por ritmo), pero como el siguient…
Ahora la vuelta devuelve los que no salieron y se les da una segunda pasada tras un minuto de respiro. Si el corte fue general —sin saldo, dos fallos seguidos, botón de parar— no hay reintento, porque insistir contra un proveedor caido no arregla nada, y los municipios que ni se llegaron a intentar cuentan como pendientes.
La landing existía y respondía 200 desde hace semanas, pero se enlazaba desde un solo sitio en toda la web: un enlace de texto en mitad de /inmobiliarias/. Si no tecleabas la URL, no llegabas.
Entra en el desplegable Sectores detras de Inmobiliarias (mismo público), en el menu móvil, en el pie y en el catálogo como "14 · Demuestra 24".
"Buscar correos en 3 webs" al lado de mil fichas parece un error. El 3 no cuenta lo que se ve: cuenta lo que no tiene correo, tiene web y no se ha mirado nunca.
En los enlaces mailto es corriente encontrar espacios codificados (mailto:%20info@empresa.com) y, como el patron acepta % para no perder direcciones raras, ese %20 se colaba pegado al nombre.
Ahora el correo se descodifica, se recorta y se comprueba que lo que queda es de verdad un correo; si no lo es, se descarta y se sigue buscando en la pagina.
Exportar un CSV para volver a subirlo a mano es un paso de más y una copia que envejece. La API v2.3 de emBlue admite alta de contactos y gestión de grupos, así que se sube directo lo que cumple el filtro.
Va en el servidor —la clave no puede viajar al navegador y son miles de contactos en tandas— y lee la agenda CON la sesión de quien pulsa, para que sea el RLS quien decida que contactos son suyos.
No es lo mismo preparar un envio de correo que una tanda de llamadas: el filtro nuevo separa "con email", "con teléfono" y "con teléfono y sin email", que son tres listas de trabajo distintas.
El CSV se lleva TODO lo que cumple el filtro, no las cien filas que se ven: exportar la pagina sería una trampa silenciosa, te llevas un recorte creyendo que llevas la lista. Sale con punto y coma y BOM, que es lo que hace que Excel en español lo abra en columnas y sin destrozar acentos.
Al guardar se leía la actividad del formulario de busqueda, y en un barrido ese campo no se rellena: 2.088 contactos —los 1.537 arquitectos de Barcelona y 551 de Madrid— entraron con la actividad vacía y no había forma d…
La actividad viaja ahora con la busqueda hasta el guardado. Las 2.088 fichas ya están reparadas en la base.
Se creo con un `create table as`, que no hereda las politicas: 935 fichas con nombres, telefonos y correos servidas por la API a cualquiera con la clave pública.
Llevabas 3.117 leads pagados para 734 contactos guardados: uno útil por cada 4,2. El motivo estaba a la vista: Valdetorres de Jarama, 4.500 habitantes, costo 410 leads; Madrid capital, 302.
Dos cambios: el tope pedido pasa a ser proporcional a los habitantes —entre 30 y 500, del orden de habitantes/100— y los sinonimos, que son una consulta de pago cada uno, solo se usan en municipios de más de 50.000 habitantes, donde de verdad destapan negocios distintos.
Si Outscraper deja de responder —saldo agotado, clave caducada, servicio caido—, el barrido seguía intentandolo municipio tras municipio: setenta y ocho errores seguidos y una hora perdida para acabar donde empezo.
Dos fallos consecutivos se leen como lo que son, un problema del proveedor y no de ese pueblo, y el barrido se detiene diciendolo. Un fallo suelto no cuenta: puede ser una consulta con mala suerte.
Ir de uno en uno son cinco clics por pueblo y estar pendiente de cuando acaba cada busqueda: con ochenta municipios nadie lo hace, y el plan se queda de adorno.
En la lista de extracciones, cada actividad lleva ahora "Barrer los N que quedan": lanza las busquedas en cadena, guarda lo aprovechable de cada municipio y lo va tachando. Arriba se ve por cual va, cuantos contactos lleva guardados y hay botón de parar —lo barrido hasta ahi se conserva—.
El botón contaba las webs revisadas, pero no si estaban saliendo correos: media hora mirando un contador sin saber si merece la pena seguir.
Quedan 1.036 fichas sin correo que si tienen web. El botón de rastreo trabajaba de 500 en 500 y sin memoria: cada pasada volvía a visitar las mismas webs muertas, así que no se terminaba nunca.
Ahora recorre todo el filtro hasta acabarlo y sella cada web visitada —encuentre correo o no—, de modo que la siguiente pasada solo mira lo que nunca se ha mirado. El botón dice cuantas quedan antes de pulsarlo.
El rastreo de webs solo miraba los descartados. Un negocio con móvil se guardaba al momento y se quedaba sin correo para siempre, aunque su web lo tuviera a la vista: guardarlo por el teléfono no es renunciar al correo,…
Ahora se rastrea la web de todo el que no traiga email. Si ya estaba guardado se le añade el correo a su ficha; si estaba fuera por no tener móvil, con el correo ya entra. El resumen distingue ambos casos.
Al rastrear solo el trozo de los descartados, la tabla de la pantalla se reescribía con ese trozo: de 300 resultados pasaban a verse los 40 que se estaban rastreando.
La fila del plan quedaba enganchada después de usarse: si luego se escribía otro municipio a mano, la busqueda tachaba la fila anterior. Se suelta al terminar la busqueda y al elegir municipio a mano.
La busqueda "no terminaba": antes de guardar nada se visitaba la web de cada negocio buscando su email. Son 300 peticiones a servidores ajenos, muchas lentas y muchas caidas —a tres por minuto, una hora larga—, y mientra…
Ahora se guarda de inmediato lo que ya tiene email o móvil, y solo después se miran las webs de los que se quedaban fuera, por si esconden un email; lo que aparezca se guarda también. El resumen lo dice: "ya está todo guardado, puedes seguir a lo tuyo".
Un negocio con fijo y sin email no se puede prospectar: no se le escribe ni se le manda un WhatsApp. Pero la mayoría tiene web y ahi suele estar el correo, así que antes de dar una ficha por perdida se mira.
El botón trabaja sobre lo que haya filtrado —actividad, provincia, estado— y no consume saldo de leads, solo tiempo. Si el email encontrado ya lo tiene otra ficha, el candado de la base lo rechaza y se cuenta aparte: significa que era la misma empresa por duplicado.
El guardado automático solo deja pasar lo que tenga email o móvil, pero "Guardar los marcados" guardaba lo que estuviera marcado —y después de una busqueda viene todo marcado—, así que colaba justo lo que el automático a…
La regla pasa a vivir dentro de importLeads, que es por donde entran todos: da igual desde donde se llame.
El saldo se descuenta al buscar, no al guardar, pero guardar dependía de pulsar un botón: una busqueda de 410 leads en Valdetorres se pago y se perdio entera por cambiar de pestaña.
Ahora, al terminar cualquier busqueda, se rastrean los emails que faltan y se guarda lo aprovechable —con email o con móvil— sin preguntar. La tabla sigue debajo para revisar lo que ha entrado y el botón manual queda para marcar algo suelto.
Se descargaba la agenda entera para comparar en memoria: 27 consultas por importación con 26.719 filas, y un tope de 50.000 a partir del cual dejaba de mirar y empezaba a colar duplicados en silencio.
Ahora pregunta solo por los emails y telefonos del lote. Para poder comparar telefonos escritos de cinco maneras distintas, contactos_google lleva una columna con los nueve digitos finales, indexada.
Revisar 400 fichas a mano para acabar marcandolas casi todas no es trabajo, es un peaje. Con "Guardar automaticamente", al terminar la busqueda se rastrean los emails que faltan, se aparta lo que no sirve y se guarda el…
Solo entra quien tenga email o teléfono móvil: sin una cosa ni otra no hay forma de llegar a ese negocio, y ocupa sitio y saldo. Al final se dice lo que ha pasado —cuantos con email, cuantos con móvil, cuantos descartados y cuantos ya se tenían—, que es lo único que hay que mirar.
Leía la tabla `organizations`, que por RLS solo deja ver la propia. En la pantalla que existe precisamente para gobernar todas las empresas, el desplegable ofrecía una —o ninguna— y no había forma de asignar el paquete a…
Ahora usa la misma RPC de administración que la pantalla de modulos.
Un lead de formulario generaba dos oportunidades. La buena la crea form-submit; la segunda nacía del aviso "Nuevo lead" que la propia plataforma se manda por correo: ese aviso volvía a entrar por la bandeja como si fuera…
Ahora todo correo que sale lleva la cabecera X-phoneIA-Auto, y el webhook de entrada ignora lo que la lleve —o venga de una dirección desde la que escribe la plataforma—. Se registra igual, con estado "propio", para poder auditarlo, pero no abre ticket, ni resume, ni crea nada.
Los desplegables se construian con los valores distintos de las primeras 2.000 filas. Con 26.719 contactos esa muestra deja fuera provincias enteras: el filtro no ofrecía Sevilla porque no salía en las primeras 2.000, y…
Ahora salen de una vista que cuenta en la base, y cada opción lleva cuantos hay: "Madrid (3.146)".
Son dos proyectos Supabase distintos y 26.719 filas no pueden pasar por la mano de nadie. El script las mueve en lotes y resuelve por el camino lo que alli no estaba guardado: la actividad (vive en otra tabla), la provin…
Entran a contactos_google y como "nuevo": material de prospección en frio, no cartera. Cada fila recuerda su id anterior, así que repetir el traspaso a medias no duplica nada.
La provincia se conoce al extraer —la busqueda se lanza siempre sobre un municipio del padron del INE, que la lleva—, pero se guardaba solo la ciudad y después no había forma de pedir "los arquitectos de Madrid" sin ir m…
Ahora se sella al guardar, hay filtro propio en la pestaña y se ve bajo la ciudad cuando dicen cosas distintas. Con su indice, para que filtrar no recorra la tabla entera.
Un negocio sacado de Google Maps no es un contacto del CRM: nadie ha pedido nada, nadie ha hablado con el y vienen por decenas de miles.
Ahora van a `contactos_google`, con su estado propio (sin tocar, contactado, descartado, pasado) y su pestaña para revisarlos, filtrarlos por actividad o ciudad, descartar lo que no encaja y pasar al CRM —de uno en uno o en bloque— solo lo que interese. Al pasarlo se crea el contacto de verdad y queda anotado a cual corresponde, para no volver a ofrecerlo.
La lista de municipios por barrer vivía en otra pestaña: para trabajarla había que ir, elegir uno, volver, buscar y acordarse de volver otra vez. Ahora está debajo del formulario, desplegada de entrada.
Al pulsar un municipio sube arriba con su actividad, y al terminar la busqueda queda tachado sin tener que marcarlo a mano —antes solo se tachaba si se importaban contactos, así que un municipio barrido sin resultados se quedaba pendiente para siempre.
Se creaba en la pantalla de municipios, el aviso duraba tres segundos y el plan vivía en otra pantalla, dentro de una pestaña sin ninguna señal de que hubiera algo dentro. Quedaba guardado y parecía perdido.
Ahora al crearlo se va derecho a verlo, y la pestaña Extracciones lleva el número de municipios que quedan por barrer.
Se escribía a mano, y eso invita a teclear "arquitecto" hoy y "Arquitectos" manana: dos planes que buscan lo mismo, no se agrupan y no se pueden comparar.
Ahora se elige de la lista, con una salida —"Otra (escribirla)"— para lo que todavía no este dado de alta.
Se cerraba con cualquier scroll, y la tabla de contactos tiene scroll horizontal: al pulsar el botón el navegador desplaza la columna fija para dejarlo a la vista, eso dispara un scroll inmediato y el menu moría antes de…
Ahora el scroll lo RECOLOCA en vez de cerrarlo, que además es lo que hay que hacer con un menu que vive fuera de la tabla: si la fila se mueve, el menu la sigue.
El selector solo aparecía si ya había algun prompt guardado, y los prompts solo se pueden guardar desde otra pantalla: quien no supiera de antemano que existen no llegaba a saberlo nunca.
Ahora el bloque está siempre, y vacio dice que se pueden guardar. Además se guarda el encargo que se acaba de escribir sin salir del dialogo, que es cuando uno sabe que merece la pena guardarlo.
Lo que se le cuenta a la IA se escribía a mano cada vez y se perdía al cerrar el dialogo: cada comercial acaba hablandole distinto al mismo modelo y el encargo que funciono bien ayer no está guardado en ninguna parte.
Ahora se escriben una vez en Comercia 24 · Prompts y se eligen de una lista. Se guardan por USO —presupuestos, email, WhatsApp, Secretaria— y no por pantalla, para que el mismo texto valga en el dialogo de presupuestar y en lo que venga después sin mover nada.
Escribir "el modulo de secretaria" y esperar que la IA adivine a que artículo se refiere funciona hasta que hay dos parecidos.
Marcar artículos ya es decir lo que quiere, así que con algo marcado no hace falta escribir nada.
Se llamaba pipeline igual que Oportunidades, siendo otra cosa: aquel es el embudo de la venta y este es por donde entra lo que trae la IA. Dos pipelines en el mismo menu obligan a recordar cual es cual.
El nombre cambia en el menu, en la cabecera de la pantalla, en la guía y en los enlaces que la mencionan. La ruta /app/pipeline-leads/ se queda como estaba: cambiarla rompería los enlaces ya repartidos.
Pipeline Leads, Contactos, Oportunidades, Eventos: de donde entra el lead, con quien se habla, que se le vende y cuando se le ve.
Se llamaban actividades en un sitio y eventos en otro siendo la misma tabla. Además el tipo iba pegado al título y se leía de corrido —"Tarea Activar demo, grabar video"—: ahora el icono acompaña al título y la palabra b…
Vivian solo en Eventos, una pantalla aparte donde había que volver a elegir de que oportunidad se trataba. El resultado previsible es que no se apuntaban: quien acaba de hablar con el cliente está mirando la oportunidad,…
Ahora se apunta donde se decide: tipo (llamada, reunión, demo, seguimiento, tarea), cuando —manana a las 10 por defecto, que es lo que se pone nueve de cada diez veces— y notas. Se listan por fecha, se marcan hechas con una casilla y las que se pasaron de fecha salen en rojo. Es la misma tabla que Eventos, no una copia, así que aparecen igual en la agenda.
La IA ya sabía montar el presupuesto con el catálogo, pero había que entrar al editor y teclear otra vez el nombre y el correo del cliente teniendo su ficha abierta al lado, y el documento no quedaba atado a nadie.
Ahora se le señala el contacto —desde su fila en Contactos o desde la ficha de la oportunidad— y se le cuenta en una línea que necesita. Los datos salen de la ficha, el presupuesto nace atado al contacto y a la oportunidad, y el origen se hereda de como llego ese cliente.
Para saber si a este cliente ya se le había llamado había que salir de la oportunidad e ir a la ficha del contacto, en otra pantalla: justo cuando se está decidiendo si moverla de fase.
La ficha muestra ahora, al lado de los datos, la línea de tiempo completa —llamadas, WhatsApp, correos recibidos y presupuestos enviados con su apertura— y desde ahi se puede escribir un email o un WhatsApp y agendar una videollamada.
Al cliente que abría el presupuesto y tenía dudas solo le quedaba contestar al correo y esperar. Ahora, justo después del precio —que es cuando más ganas tiene de hablar— se le ofrece elegir día y hora en la agenda publi…
Solo aparece si hay donde reservar de verdad: agenda abierta y algun servicio activo. Un enlace a una agenda cerrada es peor que ninguno, porque el cliente pulsa, no puede y ya no vuelve a intentarlo. Tampoco se imprime: en papel un enlace no lleva a ninguna parte.
Se podía copiar y se podía abrir, pero no leer: para dictarla por teléfono o comprobar que era la de esta empresa había que pegarla antes en algun sitio.
Dos cosas que se leen mal en el tablero:
- Una columna con quince oportunidades obliga a hacer scroll para ver si está la que se busca. Cada tarjeta lleva ahora un botón que la deja en una línea con el nombre del contacto, que es por quien se pregunta ("como va lo de Raquel"). Se recuerda por embudo y por navegador, como las etapas plegadas: es cosa de cada uno, no del embudo.
Se creaba a mano en el embudo, tecleando otra vez el mismo cliente, el mismo nombre y el mismo importe, y después nada decía que fueran lo mismo: al cerrar el trato no se sabía que presupuesto lo cerro.
Ahora hay un botón en el presupuesto que la crea ya rellena —cliente, título e importe— en la primera etapa abierta del embudo por defecto, y la deja atada. Si ya existe, el botón lleva a ella; el enlace abre su ficha aunque viva en otro embudo. Desde la oportunidad se ven sus presupuestos con número, importe y estado.
La empresa se tecleaba a mano en cada presupuesto teniendo la ficha del contacto delante, y la ciudad no se guardaba en ninguna parte.
El selector de contactos también los enseña y los busca. Entre dos personas del mismo nombre, lo que las distingue es para quien trabajan.
Un presupuesto con dos correos en cola sigue siendo un borrador —no ha salido nada todavía—, pero leer solo "Borrador" hace pensar que se olvido de enviarlo. Ahora, debajo del estado, dice a que hora sale.
Es lo que el cliente lee como título de la propuesta: una frase entera, no un hueco entre dos campos cortos. Cliente, origen y validez se eligen de una lista y caben de sobra en la línea de arriba.
El origen del contacto dice como entro su ficha en el CRM, no como llego este encargo: un cliente que entro hace un año por un formulario puede volver hoy por recomendacion.
Al elegir contacto se propone el suyo, para no teclearlo casi nunca, pero manda lo que se ponga en el presupuesto. Si se deja vacio, el cuadro de mandos sigue cayendo al origen del contacto.
El grafico contaba source_channel del presupuesto, que dice siempre "manual" porque lo escribe el editor: medía como se tecleo el documento, que no es una pregunta que nadie se haga.
Mostraba cinco presupuestos inventados esperando aprobacion, porcentajes de captacion que nadie había medido y una "actividad en directo" escrita a mano.
Ahora todo sale de c24_quote_drafts y c24_quote_sends: presupuestos del mes, enviados, abiertos por el cliente, aceptados, tasa de cierre e importe cerrado; los que faltan por enviar; de que canal vienen; los envios programados; el reparto por etapa (cada tarjeta filtra la lista) y los ultimos envios y aperturas reales. Si un envio fallo, se avisa arriba en vez de callarlo.
Vivía dentro de la celda, y el contenedor que da scroll horizontal a la tabla lo cortaba por abajo. Ahora se dibuja en el body con coordenadas fijas, se voltea hacia arriba si no cabe debajo y se cierra al hacer scroll.
Cinco botones repetidos en cada línea convertian la tabla en una pared de palabras de colores y se comian el ancho de los datos.
Con nueve columnas, la columna de Historial, Reactivación, Reseña, Editar y Borrar quedaba fuera de la vista en un portátil, y había que descubrir que la tabla se desplaza en horizontal para poder borrar un contacto.
Ahora esa columna va pegada al borde derecho: se queda quieta mientras el resto de la tabla se desplaza por debajo.
El recuadro del destinatario y la primera ficha seguían demasiado cerca: la cabecera y el contenido se leían como una sola masa. La separación sube otro paso, y la introducción también se despega del recuadro.
Iban demasiado juntos y la parte alta de la propuesta se leía como un bloque apretado: titular, recuadro del cliente y primera ficha casi pegados.
"Validez (días)" no cabía en su columna, la etiqueta partía en dos líneas y su campo quedaba un renglón por debajo de los otros dos.
Estaba en el título y otra vez a un palmo, a la derecha, partido en dos líneas por el ancho. A la derecha se queda solo el estado, que es el dato que sí falta en el título.
Cada pantalla resolvía la vuelta a su manera —un botón propio, ninguno, o el del navegador—, así que cerrar un presupuesto o un contacto era distinto según dónde estuvieras.
Ahora la barra superior lleva un «← Volver» que aparece solo donde hay algo por encima. Sube un nivel de la ruta en vez de usar el historial: "atrás" devuelve al sitio anterior, que puede ser cualquiera —un enlace de un correo, otra sección—, mientras que subir un nivel siempre lleva a la lista de la que salió el documento, que es lo que uno espera al cerrarlo.
El número se asignaba al enviarlo, para que un borrador descartado no dejara huecos en la serie. Pesa más lo otro: hace falta poder citar un presupuesto por teléfono antes de mandarlo, y una lista con guiones no se puede…
Ahora lo recibe al crearse, borradores incluidos, y los que ya existían sin número lo han recibido por orden de creación. El precio, asumido: un borrador descartado deja su número sin usar.
En la lista, un borrador salía con un guion en la columna Nº y eso no explica nada: parece que falta un dato o que algo no se ha guardado.
Ahora pone "al enviar", con el motivo completo al pasar el ratón: el número se asigna al enviarlo para que los borradores descartados no dejen huecos en la serie.
Estaban repartidos: el número en el título y el estado en una fila suelta debajo, en inglés ("draft", "viewed").
El estado pasa a castellano —Borrador, Enviado, Visto, Aceptado— y cuando aún no hay número se explica por qué: se asigna al enviarlo, para que los borradores descartados no dejen huecos en la serie.
Al pulsarlo salía un cuadro vacío hasta escribir algo, y cuando no recuerdas el nombre exacto —que es cuando más falta hace— no había nada donde mirar.
Ahora al abrirlo lista los últimos veinticinco contactos, con un rótulo que recuerda que escribiendo se busca entre todos. Los últimos primero, porque el contacto que se busca suele ser reciente.
La tabla de importes aparecía pegada a la última imagen de las fichas, sin aire ni titular, así que parecía parte del último artículo en lugar del resumen de todo lo presupuestado.
Ahora la separa una línea con espacio generoso y la encabeza "Detalle económico", que además avisa al lector de que a partir de ahí se habla de dinero. Mismo rótulo en el impreso.
Iban al final del todo, detrás de las condiciones y de los bloques de cierre, donde se leen ya de salida. Ahora van justo después del precio y de las tarjetas de contratación: el cliente acaba de ver lo que cuesta y de e…
Y con rótulo que no pasa desapercibido: "Opcionales" en grande dentro de un recuadro con borde discontinuo, que dice sin leer que eso es aparte de lo contratado.
Con el filtro en "Activos" y dos presupuestos aceptados, la pantalla decía "Aún no hay presupuestos" y ofrecía crear el primero. El trabajo estaba ahí; lo que fallaba era el mensaje.
Dos cambios. Los aceptados entran en "Activos": un presupuesto aceptado sigue siendo trabajo vivo hasta que se ejecuta y se cobra, y lo que hay que apartar es lo que ya no lleva a ninguna parte —rechazado, caducado, descartado—.
Estaban entre la tabla de importes y la elección de forma de pago, o sea en medio de la parte que el cliente lee para decidir.
Y las fichas de artículo dejan de repetir el precio junto al título: el importe de cada concepto está en la tabla, y tenerlo en dos sitios obliga a leer dos veces la misma cifra y a cuadrarlas de cabeza. Arriba se cuenta qué es; abajo, cuánto cuesta.
A 4xl, un asunto normal —"Presupuestos desde planos y estancias con IA"— ocupa tres líneas y empuja todo lo demás fuera de la primera pantalla. Baja un paso: sigue leyéndose como titular y cabe en una o dos líneas.
"Para Fulano · su email · REF" iba en una línea gris pequeña bajo el titular y se leía como un pie de foto. Es lo primero que comprueba quien recibe el documento —que es para él— y merece verse.
Ahora va en su propio recuadro, con la empresa en grande, la persona debajo y el email y la referencia en pequeño al lado. Si no hay empresa, manda el nombre de la persona.
La validez son dos dígitos y el asunto es una frase, pero repartían el ancho a partes iguales: el asunto salía cortado a media palabra y al lado medio campo vacío para escribir "30".
Ahora la validez ocupa lo que necesita y el resto se lo queda el asunto, que además es lo que el cliente ve como titular de la propuesta.
Al permitir enviar a varias personas dejé un enlace único para todas, y con eso "lo abrió" no dice quién: tres personas de la misma empresa compartían dirección y la propuesta saludaba siempre al destinatario principal.
Ahora cada envío tiene su enlace. La apertura se sella en el envío que la provocó —así se ve que el gerente lo abrió y el administrador no— y la propuesta recibe a quien la abre por su nombre, no por el del contacto de la cabecera.
Un presupuesto se manda casi siempre a más de una persona de la misma empresa —quien decide, quien firma, quien lo revisa— y hasta ahora había que enviarlo tres veces a mano, sin saber después quién había recibido qué.
El diálogo de envío admite ahora varios destinatarios: se añaden por contacto del CRM, que es lo que hace que el envío quede en SU ficha, o como email suelto para quien no está dado de alta. Cada uno recibe el mismo correo y deja su propia fila con sus horas de salida y apertura, así que se ve quién lo abrió y quién no.
El mensaje con el que salía un presupuesto estaba escrito dentro del servidor: no se veía antes de enviar y no había forma de cambiar una coma. Se enviaba a un cliente un texto que nadie había leído.
Ahora el diálogo de envío trae el asunto y el mensaje, ya redactados con los importes de ese presupuesto —o con el lenguaje de novedades si es de ese tipo—, y se pueden corregir. Se propone escrito y no en blanco porque es más fácil retocar una frase que enfrentarse a un cuadro vacío con el cliente esperando.
Cuando la función de vistas previas no responde, el navegador suelta "Failed to send a request to the Edge Function" en mitad del formulario, que parece que se ha roto algo y que el enlace se ha perdido.
No se pierde: el enlace se guarda igual y lo único que falta es la miniatura. El aviso ahora dice eso, y que se puede reintentar más tarde.
La ficha de cada artículo puede apuntar a su página: la ficha en la web, una demo, un vídeo. En la propuesta sale como tarjeta —imagen, título y dominio— y no como una dirección suelta, para que se entienda adónde lleva…
La miniatura no es una captura de pantalla: eso exige un navegador en el servidor y un servicio de pago. Es la imagen que la propia página publica para cuando la comparten (og:image), que es exactamente una vista previa hecha por su dueño y sale gratis.
Nueve columnas en una fila dejaban el concepto —lo que más se lee y lo que más se corrige— en un campo de tres centímetros con el nombre cortado, y la tabla solo cabía con barra horizontal.
Ahora cada línea es una tarjeta de dos filas: arriba el concepto a todo ancho con su descripción debajo, y abajo los importes con su etiqueta encima. Se acabó la barra horizontal y cada campo se entiende sin mirar la cabecera de la tabla.
El "si además quieres…" de cualquier presupuesto: un concepto con su precio que se ofrece pero no entra en la cifra. Meterlo dentro infla el número que decide la venta; dejarlo fuera del documento pierde la oportunidad.
Una casilla en la línea la marca como opcional. Deja de contar en el pago único y en las dos cuotas, se ve atenuada en el editor con un "no suma", y bajo los totales aparece cuántas hay para que no se cuelen sin darse cuenta.
Dos cosas que hacían el formulario incómodo justo en lo que más se usa.
El precio se reformateaba en cada tecla: escribías el primer dígito, el campo se convertía en "5,00" y el cursor saltaba al final, así que el importe acababa metido en los decimales. Ahora el texto se lleva aparte del valor y solo se formatea al salir del campo.
NUMERACIÓN. El número era fijo —PRE-26-0001, reiniciando cada año— y quien viene de otro programa llega con una serie empezada que necesita continuar, no volver al 1 con otro formato.
La serie sigue viviendo en su tabla de contadores, que no tiene políticas a propósito: se toca solo a través de funciones controladas, nunca desde el navegador. Y el número se sigue asignando al enviar, no al crear, para que los borradores descartados no dejen huecos.
Seis se quedaban cortas para contar un producto con capturas de cada función. El tope pasa a doce, en el catálogo y en la ficha de cada línea del presupuesto.
Sigue habiendo tope, y no por límite técnico: una propuesta con ocho artículos a doce fotos son casi cien imágenes, y eso ya no es una propuesta, es un catálogo que nadie baja entero. En el impreso se siguen llevando solo las dos primeras de cada artículo.
Un artículo se vende de una de estas maneras: pago único por unidad, cuota sin alta, o alta más cuota. El formulario solo enseñaba la primera —"Precio (€) *", obligatoria— y escondía las otras dos bajo "Cuotas (opcional)…
Ahora los tres importes están juntos y los tres son opcionales: pago único, al mes y al año. Se valida que haya al menos uno, porque un artículo sin ningún precio no se puede presupuestar.
Iba en el gris más oscuro de la escala, que sobre blanco se lee como negro puro y pesa más que el titular de la propuesta. Baja un par de pasos: sigue mandando sobre el texto de venta, sin competir con lo de arriba.
Un encabezado y un subtítulo para anunciar lo que ya se ve: las fichas dicen por sí solas lo que son, y ese rótulo solo alejaba del contenido a quien viene a leerlo.
En el impreso se mantiene: allí los encabezados son el esqueleto del documento y sin él las fichas quedarían colgando entre los datos del cliente y el detalle económico.
Brevo rechazaba el alta con "invalid event of transactional webhook email channel": para CREAR el webhook espera los eventos en camelCase (hardBounce), pero cuando luego los ENVÍA los manda en snake_case (hard_bounce).
Queda dicho en un comentario junto a la lista, porque las dos listas conviven en el repo y parecen la misma cosa escrita de dos maneras.
En el rastro del último intento no hay ningún envío registrado: hay un rechazo por sesión y una llamada que se quedó a medias. La sesión caduca cada hora y el botón no lo contaba, así que parecía que no hacía nada.
Ahora se comprueba la sesión antes de llamar al servidor y, si ha caducado, se dice —con el aviso de que el presupuesto está guardado y solo hay que volver a entrar—. Cualquier otro fallo del servidor se muestra con su mensaje en vez de quedarse en silencio.
El cliente contesta al correo de la propuesta y su respuesta cae en la Bandeja como un email más: "de acuerdo, adelante" sin decir con qué.
Ahora, si quien escribe tiene un presupuesto enviado en los últimos noventa días, el ticket abre con una nota: número, importe, cuotas si las hay, estado y el enlace a la propuesta. Se busca por su email y se coge el más reciente, que es a lo que se contesta el 99 % de las veces.
El logotipo estaba en la franja superior del sitio, que es el marco de la herramienta. Un presupuesto es un papel con membrete: el titular a la izquierda y la marca de quien lo envía a la derecha, dentro de la propia hoj…
La referencia vuelve a la barra, que es de donde salió.
El diagnóstico lo destapó: los presupuestos se enviaban desde crm@iacontac.es —el remitente por defecto del servidor, de otro producto— aunque la organización tenga puesto el suyo en Ajustes.
Ahora el envío usa el from_email y el reply-to de la organización, como ya hacía el módulo de Atiende, y solo cae en el del servidor si no hay ninguno.
Cuatro cosas de la cabecera y del cuerpo de la propuesta:
· Fuera el "PRESUPUESTO" en pequeño sobre el titular. Decía dos veces lo mismo y le robaba tamaño a lo que sí importa. · El titular crece: es lo primero que se lee y ahora se lee como un titular. · Arriba a la derecha va el logotipo de la organización, no el nuestro: quien recibe la propuesta la recibe de su proveedor, no de la herramienta con la que se hizo.
Para saber si los avisos de entrega y apertura llegarán hay que mirar el panel de Brevo, y para eso hace falta la clave.
Así que pregunta el servidor, que ya la tiene, y devuelve solo las respuestas: qué proveedor hay configurado, si la clave sigue siendo válida, desde qué dirección se remite y si el webhook que rellena "entregado" y "abrió email" está dado de alta apuntando aquí. La clave no sale de la función.
ENVÍOS. "Le envié el presupuesto y dice que no le llega" no se podía responder: no quedaba rastro. Y si el servidor no tenía proveedor de correo configurado, la aplicación decía "marcado como enviado" y se quedaba tan an…
Cada envío deja fila con sus cuatro horas: cuándo se ordenó, cuándo salió de verdad, cuándo lo entregó el proveedor y cuándo lo abrió el cliente. Si falla, se ve el motivo —"no hay proveedor de email configurado"— en vez de un "hecho" que no es verdad.
Dos cosas que se echaban en falta en cuanto pasas del primer presupuesto.
Las líneas se suben y se bajan con las flechas de su fila. El orden importa más de lo que parece: un presupuesto se lee de arriba abajo y lo que va primero es lo que se entiende como principal, con lo accesorio detrás. Hasta ahora el orden era el de tecleo, y para colarte una línea en medio había que borrar y rehacer.
La galería recortaba cada imagen para llenar un alto fijo. Con fotos de producto se nota poco; con una captura de pantalla —que es justo para lo que se añadió pegar con ⌘V— se pierde lo único que había que leer: el titul…
Ahora ninguna imagen lleva alto fijo: se muestran a su proporción real, con tope de altura y sobre fondo claro, así que conviven una foto vertical y una captura apaisada sin deformarse ni perder nada.
Seis campos de cliente en dos columnas ocupaban media pantalla para algo que casi siempre llega relleno desde el contacto y no se vuelve a tocar: había que hacer scroll para llegar a las líneas, que es donde se trabaja.
Ahora arriba solo está lo que se usa: el contacto, el asunto y la validez, en una fila. Los datos copiados se resumen en una línea —empresa, nombre, email, teléfono, dirección— y los seis campos se despliegan solo al pulsar "Editar datos", ya en tres columnas.
Los datos del cliente se tecleaban a mano en cada presupuesto teniendo la ficha del contacto a un clic, con lo que eso trae: el mismo cliente escrito de tres maneras y un presupuesto que no se puede relacionar con nadie.
Ahora la cabecera empieza por el contacto: lo eliges con el buscador de siempre y sus datos se copian al presupuesto. Copia y no vínculo vivo, porque un presupuesto es un documento y debe conservar los datos con los que se emitió aunque después cambie el domicilio o el nombre fiscal; y como es copia, se puede ajustar para ese presupuesto sin tocar la ficha del contacto.
Con Módulos, Comercia 24, Atiende 24, Cita 24, Sectores y tres enlaces sueltos más, la barra iba justa de ancho y empujaba a los botones de la derecha.
Los tres pasan a un desplegable "Novedades" con el mismo patrón que Módulos y Sectores: se abre al pasar por encima, el propio rótulo sigue llevando a /novedades/ de un clic, y cada entrada lleva su icono y una línea de qué es. Se abre alineado a la derecha por ser el último de la barra, para que no se salga de la pantalla.
Los bloques obligaban a maquetar cada presupuesto a mano: para diez presupuestos parecidos, diez veces el mismo trabajo. Ahora la propuesta se monta con lo que se ha presupuestado, sin tocar nada.
El artículo del catálogo gana un texto de venta —lo que le contarías al cliente— distinto de la descripción corta que acompaña al concepto en la tabla. Con eso y su galería, la propuesta imprime primero la ficha de cada artículo, uno a uno, y después el detalle económico: importes, totales y las dos formas de contratar.
Una página de novedades como la de presupuestaIA: qué salió, qué día y por qué, con filtro por módulo y RSS. 469 publicaciones desde el 21 de mayo.
El contenido no se escribe aparte, se genera del historial de git: los mensajes de commit de este repo ya están redactados en castellano y explicando el motivo del cambio, así que son la fuente. Un changelog mantenido a mano se desincroniza en una semana; este se regenera con `node scripts/generar-novedades.mjs`, que escribe también el RSS.
Un artículo puede venderse de tres maneras a la vez —alta que se paga una vez, cuota mensual, cuota anual— y no son el mismo número con descuentos: el precio anual lleva su rebaja dentro y no es el mensual por doce.
El presupuesto deja de tener un total y pasa a tener una entrada y dos formas de pagar la cuota. En la propuesta salen las dos, una al lado de la otra, con el equivalente mensual del anual y el ahorro calculado; el cliente pulsa la que quiere y queda registrado qué eligió. El pago inicial es común a las dos, así que la comparación no queda contaminada.
El catálogo admite dos caminos —subir la tarifa en PDF o dar de alta el artículo a mano— pero el alta manual solo tenía nombre, precio y descripción.
Ahora cada artículo tiene galería (hasta cuatro imágenes, pegando, arrastrando o eligiendo archivo). La primera es la portada, y es la que se copia a la línea cuando insertas el artículo en un presupuesto: la portada se deriva de la galería en vez de guardarse aparte, para que no haya dos sitios que puedan discrepar sobre cuál es la imagen del artículo.
El módulo sabía sumar pero no vender: catálogo, líneas, descuentos e IVA, y de ahí a una tabla en blanco y azul. Faltaba justo lo que hace que una propuesta se lea y se acepte.
· Imagen por artículo del catálogo y por línea del presupuesto. Al insertar un artículo, su imagen viaja con él y se puede cambiar solo para ese presupuesto. · Bloques de contenido alrededor de las líneas: portada, texto, imagen suelta y galería, colocables antes o después de los importes y reordenables. · Las imágenes entran pegando (⌘V), arrastrando o eligiendo archivo.
El selector de contacto solo enseña el nombre, así que para escribirle a alguien desde una oportunidad había que irse a Contactos y buscarlo a mano.
Debajo del selector van ahora su email y su teléfono, en enlaces mailto: y tel:, más un "ver ficha" que abre Contactos prefiltrado (el ?q= que ya usan los enlaces "Ver contacto en el CRM"). Si el contacto no tiene ninguno de los dos, lo dice en vez de dejar el hueco mudo.
Reemplaza los conmutadores de mostrar/ocultar de 212d42e. Esconder una etapa la sacaba del tablero, y lo que hace falta es lo contrario: que siga estando, ocupando lo mínimo, para no perderla de vista ni tener que ir a b…
Cada cabecera lleva ahora un « que pliega su columna a una franja de 40px con el fondo tintado del color de la etapa, su punto, el número de oportunidades dentro y el nombre en vertical. Un clic en la franja la devuelve a su ancho. La franja sigue aceptando que le sueltes tarjetas encima, así que mover una oportunidad a una etapa plegada no obliga a desplegarla antes.
"Ventas Directas" tiene 13 etapas, siete de ellas llamadas "Nueva etapa" y vacías, así que el tablero obliga a desplazarse en horizontal para llegar a las columnas que de verdad se miran.
Una fila de conmutadores encima del tablero, uno por etapa, con su color y el número de oportunidades que contiene. Al apagarlo, la columna desaparece del tablero; el conmutador se queda tachado para que se vea que hay algo escondido, y un enlace "Mostrar todas" lo revierte.
form_submissions.contact_id es ON DELETE SET NULL. Al borrar del CRM la ficha de un lead, su envío queda marcado como procesado pero apuntando a nadie, y la columna Contacto CRM lo pintaba igual que un fallo de verdad: "…
processed_at los separa sin ambigüedad, porque se escribe en la misma sentencia que contact_id: - contacto vivo -> verde con su nombre - procesado sin ficha -> ámbar "Contacto borrado" - sin procesar -> gris "Sin procesar" (esto sí es un fallo) - processing_error -> rojo "Error"
La columna Envíos pintaba el número en azul, pero era un <span>: parecía un enlace y no llevaba a ninguna parte. No había forma de leer lo que había escrito la gente sin entrar en la base de datos.
Ahora el número abre los envíos de ese formulario: una fila por envío, con una columna por cada campo del formulario y la fecha, más el contacto del CRM al que fue a parar (o el error, si falló). Los formularios editados dejan envíos antiguos con claves que ya no existen; esas columnas se añaden al final para que ningún dato recibido quede oculto.
Un iframe no se ajusta a su contenido, así que quien incrusta /f/<slug> tiene que ponerle una altura a mano. Como el formulario no decía cuánto medía, en presupuestaIA.es conviven 39 landings con cinco alturas distintas…
Además no hay una altura correcta: cambia con el ancho (en móvil las etiquetas parten en dos líneas), al aparecer mensajes de validación y al pasar a "gracias". Ahora se publica por postMessage en cada cambio, con un ResizeObserver.
La oportunidad solo nacía por dos vías: correos detectados como lead de portal inmobiliario, o la Secretaria IA registrándola mientras conversa.
Ahora, si el correo es comercial, no es de portal y no es spam, se crea la oportunidad en el embudo del canal email (o el de por defecto), se registra en la línea de tiempo del lead y se avisa al equipo. Solo si el contacto no tenía ya una oportunidad abierta; si después contesta la Secretaria, encuentra esa y la avanza en vez de duplicarla.
Portado del módulo equivalente de iacontac, en producción allí desde 2026. Busca negocios por actividad × municipio vía Outscraper, enriquece sus emails y los pasa al CRM como contactos sin duplicados, con venta por paqu…
Lo que no se ha simplificado, porque tiene motivo:
Dos cosas confusas en el modal de conocimiento:
- El botón decía "Cancelar" junto a "Añadir". En un diálogo que ya ha escrito en la base de datos, "Cancelar" se lee como "deshaz lo añadido", que no es lo que hace. Ahora dice "Salir". - Con un lote en marcha el botón estaba deshabilitado, pero la ✕ y Esc sí cerraban... y el bucle seguía pidiendo páginas en segundo plano contra un modal ya cerrado.
Al cortar el último trozo, cut valía clean.length, así que i volvía a quedarse en clean.length - overlap y la condición del while seguía siendo cierta para siempre: la función empujaba el mismo trozo de 200 caracteres ha…
Consecuencia real: bot-ingest nunca ha podido ingerir una URL ni un texto manual de más de 1200 caracteres. Cada invocación moría con "Memory limit exceeded" (o "CPU Time exceeded") y devolvía 546, sin insertar nada. Las FAQs sí funcionaban porque no pasan por el troceador.
El modal de "+ URL" mandaba una sola dirección por vez, así que sembrar el conocimiento de una web entera eran veinte aperturas de modal.
Ahora acepta una lista pegada (una por línea) y lanza una petición a bot-ingest por cada una, no un único lote: la función aborta con 502 al primer fetch fallido, y así una página caída no tumba las demás. Se muestra el progreso mientras van entrando y, al terminar, cuáles no entraron.
widget.js pide name, welcome_message, primary_color, position y avatar_url con la anon key, pero la única política de public.bots era "for all to authenticated" con aislamiento por organización: el widget nunca recibía n…
SELECT para anon limitado por grant de columna a esas cinco y por política a los bots activos. system_prompt, allowed_domains, las claves de handoff y las cuotas siguen siendo invisibles para anon.
Va a mitad de página, entre «Todo lo aburrido, ya resuelto» y el bloque oscuro: justo el hueco que dejó la rejilla de sectores al quitarla.
La imagen va a sangre, de borde a borde, sin marco ni esquinas redondeadas —a todo el ancho quedarían raras contra los bordes— y con una franja fina arriba y abajo para separarla del fondo.
La CTA principal de la home pasa a rojo, a juego con el logo y el favicon. En escritorio y también en el menú móvil, que es el mismo botón.
El botón del móvil sale de MobileNav, que comparten TODAS las cabeceras (/pymes, /inmobiliarias, /webdesign…). Cambiarlo ahí las habría teñido a todas, así que se añade un `ctaClassName` opcional: por defecto sigue azul y solo la home pide el rojo.
El cuadro «pIA» del logo es el mismo dibujo que el favicon, así que pasa a rojo (red-600) con él, y el «IA» del nombre lo acompaña.
También la variante `light`, la de la barra azul del móvil: si solo se cambiara el «IA», el logotipo quedaría partido en dos colores.
El icono «pIA» pasa de azul (#2563eb) a rojo (#dc2626), el equivalente exacto en la misma escala.
No solo los SVG de la pestaña: también los tres PNG del PWA, que son el icono de la app instalada y se habrían quedado azules.
«Módulos» pasa a ser un desplegable, con el mismo patrón de hover/focus que «Sectores», y dentro cuelgan dos entradas: el catálogo de módulos (el ancla de siempre) y Web Design IA.
El propio «Módulos» sigue siendo un enlace al ancla, así que quien lo pulse en vez de esperar el desplegable acaba donde acababa antes.
Alinea la integración con la versión actualizada del encargo:
- La función pasa a llamarse `soporte-enlace` (era `soporte-portal`), que es el nombre con el que presupuestaIA la documenta y por el que se buscará cuando algo falle. - El `nombre` que se manda es «Persona · Agencia»: es lo que se ve en la bandeja de Blas, y sin la agencia hay que abrir el ticket para saber de quién es.
Integra el soporte de presupuestaIA en la barra superior de /app:
- «Soporte» pide el enlace personal del portal y lo abre. Va por una edge function nueva, `soporte-portal`, porque phoneia.es es un sitio estático (output: export) y no hay servidor de Next donde esconder la clave. - «Compartir pantalla» es un enlace pelado a /app/ayuda, sin clave ni token, y solo se muestra si el navegador tiene getDisplayMedia.
Nuevo módulo 13 en la home, así que aparece tanto en la píldora del índice como en su tarjeta al entrar por «Módulos» del menú. El CTA lleva a /webdesign/, que hasta ahora no estaba enlazada desde ningún sitio.
Dos cosas que no encajaban en el molde de los demás módulos: - No tiene cuota: se le da su propia rama de precio («desde €490 · pago único»), porque el render por defecto pintaba «/mes» y una cuota anual con «2 meses gratis» que aquí no existen.
Página adicional 120 -> 43 €, idioma adicional 290 -> 39 €, migración 250 -> 90 €, tienda online 1.200 -> 899 €, rediseño completo 350 -> 135 €.
La FAQ de «ya tengo web pero está anticuada» repetía el precio de la migración, así que también pasa a 90 € y no se contradice con la tabla.
El pack Negocio baja de 1990 a 1390 €. Además, los importes de las tarjetas pasan por un formateador de miles, así que se imprimen como «1.390 €» y «1.190 €» en vez de «1390 €» y «1190 €».
El formateador es manual y no toLocaleString, para que el HTML que genera el servidor sea idéntico al que espera el navegador y no haya discrepancias de hidratación.
Esencial incluye 1 ronda; Profesional y Negocio, hasta 3. Los 55 € pasan a ser el precio de la ronda ADICIONAL, no el de cualquier ronda, y así se dice en los tres bullets, en la lista de extras y en las dos FAQ que habl…
Cambio de modelo: se elimina la cuota mensual de los tres packs. La web se paga una vez (Esencial baja de 690 a 490 €) y los cambios posteriores se cobran por rondas de 55 €.
Repasado TODO el copy que hablaba de la cuota, que si no la página se contradecía: metadata, franja de características, dato del hero, tarjeta oscura de la entrega, subtítulo y pies de la sección de precios, y las dos preguntas frecuentes sobre la cuota y los cambios incluidos. El campo `monthly` desaparece del tipo Pack.
Fuera la rejilla de «Hecha para tu sector» con los seis sectores, su array de datos y los dos enlaces del menú (escritorio y móvil) que apuntaban al ancla, que si no quedarían muertos.
El proceso pasa de 4 a 5 pasos: entre la llamada inicial y la primera versión, el cliente elige entre varias propuestas de diseño con su logo y sus colores.
La rejilla pasa a 5 columnas en escritorio, con menos separación y algo menos de padding para que las tarjetas respiren.
Nueva línea de negocio: diseño web para pymes y profesionales, con la web generada con IA y revisada a mano. Estructura clonada de /pymes (header sticky, hero, franja de características, precios, FAQ, CTA) con paleta vio…
Packs: Esencial 690 € + 29 €/mes · Profesional 1.190 € + 49 €/mes · Negocio 1.990 € + 79 €/mes. Los importes viven en un único array de este archivo; si algún día se activa el cobro por Stripe habrá que crear los productos webdesign_* en create-checkout-session y cuadrarlos (y NO duplicarlos como pasó con /pymes e /inmobiliarias).
Estaban en seis sitios: el bloque de bonos, la etiqueta de la tabla, la caja de la cuarta fila, «El marco», una FAQ entera, el pie de las maquetas y la pantalla del CRM. Fuera de todos.
La tabla comparativa, la explicación de los artículos 41.1 y 41.2 y la diferencia entre los dos tipos de sello se quedan: son descripción del marco legal, no un aviso de disponibilidad.
Repetía lo que ya dice el bloque de bonos justo encima, y en la ventana de pago restaba a lo que allí importa: cuánto se paga y por cuántos sellos.
Dos maquetas nuevas entre «Cómo funciona» y el valor legal: la hoja de visita tal y como sale —con su pie de QR, huella y sello— y la pantalla que ve quien recibe el enlace.
Van maquetadas en HTML como el resto del sitio, no como capturas: se ven nítidas en cualquier pantalla y no hay que rehacerlas cuando cambie un dato. El QR es decorativo y no codifica nada — uno de verdad en una simulación llevaría a un documento que no existe.
La pantalla de módulos guarda una lista blanca de Secciones (`__only`), y Custodia no es una sección: es una entrada dentro de CRM que se comprueba con `modules.custodia`.
Se generaliza lo que ya se hacía a mano con `clinica`: FLAG_KEYS agrupa los módulos que van por bandera propia, y tanto el guardado como la lectura los tratan aparte. De paso se arregla la lectura: una org sin `__only` los enseñaba todos encendidos, incluidos los de bandera, que estaban apagados de verdad. El panel decía lo contrario de lo que veía el cliente.
La entrada del menú salía en todas las empresas. Custodia se vende aparte (79 €/mes), así que ahora depende de `modules.custodia` y el super admin la activa por empresa desde /app/admin/modulos/, como el resto.
Esconder la entrada del menú NO es control de acceso: quien teclee la URL llega igual, y ahí el botón «Dar de alta» crea una empresa real en Custodia a nombre de su organización. Así que la comprobación va también en custodia-alta y en custodia-api, que son las que actúan. La pantalla solo se adelanta para no enseñar un formulario que el servidor va a rechazar.
Al añadir «Contacto» el menú pasó a ocho entradas, y entre 768 y 1024 px ya no cabía: se comía el logo, partía «Cómo funciona» en dos líneas y acababa pisando el botón de demo.
El menú horizontal pasa a aparecer solo desde `lg`; por debajo se usa el desplegable, que es lo que ya hacía en móvil. MobileNav gana una prop `wide` para subir su corte a la vez —con las dos clases literales, que Tailwind no compila las que se construyen a trozos—.
Mismo patrón que en la landing de Custodia: el hero pasa a dos columnas —relato a la izquierda, alineado a la izquierda solo en pantallas grandes, y formulario a la derecha sobre tarjeta blanca— y una sección centrada en…
Las tres cifras del hero (24/7, +30 idiomas, 7 días) se quedan en la columna del relato: son parte del argumento, no del formulario.
Quien baja hasta el final de la landing ya es una agencia interesada en ordenar su operativa, así que el CRM es el paso siguiente natural.
Dos sitios: en el hero, a la derecha del relato —que pasa a dos columnas y se alinea a la izquierda en pantallas grandes—, y centrado abajo entre la FAQ y la llamada final, con su propia entrada en el menú.
El iframe es del mismo origen (/f/… es de phoneia.es), así que no depende de ninguna política de terceros. Va con loading="lazy": son 520px de alto que no bloquean el primer pintado del hero.
Repaso del código de las funciones de Custodia, no de su documentación.
El grave: un documento con marca de agua NO está sellado. Custodia no inserta nada, así que la referencia sigue libre — pero la pantalla lo guardaba como «ya emitido» y no volvía a ofrecer el botón. Esa visita se quedaba sin hoja con valor probatorio para siempre, justo en el caso que el producto está diseñado para provocar: emitir antes de personalizar la plantilla.
El CRM no sabía qué piso se había enseñado. `events` guardaba el evento con su contacto y `property_contacts` unía contacto con vivienda, pero nada unía el evento con el inmueble — y ese es justo el hecho que la hoja de…
También faltaba la dirección: `properties` viene de feeds de portales, que la ocultan a propósito. Una hoja de visita sin la dirección del piso no acredita gran cosa, así que la agencia la completa y se guarda en la ficha para no volver a teclearla en cada visita al mismo inmueble.
phoneia.es es un sitio estático: no hay servidor de aplicación donde esconder un secreto. Y la clave que Custodia da a cada agencia no es de lectura, SELLA: quien la tenga puede emitir documentos con fecha certificada a…
custodia_cuentas no tiene ninguna policy de RLS. No es un olvido: ni el dueño de la organización puede leer su propia fila desde el navegador. La pantalla no la necesita — el estado se lo da la acción `estado`, que además lo pregunta a Custodia en vez de fiarse de una copia local.
El prestador cualificado no está contratado todavía: hoy todo se sella con sello estándar (art. 41.1), que es prueba admisible pero no tiene la presunción de fecha del 41.2.
El bono se sigue vendiendo, porque el saldo no caduca y se abona igual, pero ahora lo dice donde se decide la compra: en el bloque de bonos y dentro del modal de pago, no en letra pequeña.
Custodia se vende por un ángulo concreto: cuando dos agencias se disputan una comisión decide quién puede probar que enseñó el piso primero, y esa fecha hoy la pone la propia agencia en su propio papel.
El cobro NO pasa por create-checkout-session: Custodia se factura contra la edge function checkout-custodia del proyecto de presupuestaIA, que es donde vive el sellado. De ahí que la anon key vaya literal en el componente —la de phoneIA es de otro proyecto y la función la rechazaría— y que el payload mande variante: "inmobiliaria", sin lo cual se cobraría la tarifa general de 5…
La cadena de if/else de integration-sync-contacts cubre ocho proveedores y no tenía else. Un proveedor fuera de la lista —presupuestaIA, por ejemplo— no llamaba a nadie, dejaba la lista de contactos vacía y salía por la…
Eso es indistinguible de un ERP que no tiene contactos, y es justo lo que se vio al conectar presupuestaIA: la empresa tiene 4 clientes y el mensaje decía 0 importados con estado success.
La pantalla ofrecía presupuestaIA en el desplegable pero la lista blanca de la base de datos solo admitía nueve proveedores, así que el error salía al pulsar Guardar.
Es la segunda vez en este repo. checkout_sessions tenía otra lista blanca que llevaba meses rechazando bono_integracion en silencio. Por eso no añado un valor más: se cambia por una comprobación de forma (slug en minúsculas), que es lo que de verdad hay que impedir aquí — el valor sale de una unión cerrada de TypeScript, no lo teclea nadie.
El ERP no pregenera PDF —el impreso es una página con botón de imprimir—, así que pdf_url no se va a rellenar y el botón no habría aparecido nunca. Ahora usa pdf_url si existe y el enlace público si no.
Corrige además el encargo: el write-back del QR que reclamé no faltaba. Los 14 envíos de verifactu_envios son huérfanos —apuntan a 3 facturas de prueba borradas— y verifactu_marcar_resultado sí escribe vf_hash, vf_qr_url, vf_csv y vf_estado. Los contadores estaban a cero porque ninguna factura viva ha pasado por Verifactu, no porque el circuito no escribiera.
El PDF lo genera y lo custodia el ERP, no el CRM: el impreso de una factura Verifactu lleva el QR y la leyenda VERI*FACTU, y ese dato es suyo.
Guarda erp_pdf_url, erp_enlace_publico y erp_vf_estado en la operación, amplía crm_rentabilidad_operaciones con las dos primeras (drop+create: no se puede cambiar el tipo de salida con CREATE OR REPLACE) y añade 'Ver factura' y 'Copiar enlace' en la fila ya facturada.
Añade la sección #rentabilidad entre Portafolio y Precios, con el mismo patrón que las demás (texto + maqueta oscura), enlace en la navegación de escritorio y móvil, y tres preguntas nuevas en el FAQ: Verifactu, conviven…
El argumento no es 'facturamos' —eso lo hace cualquier gestoría— sino que la factura y el gasto quedan pegados a la operación, que es lo que permite decir cuánto se ha ganado con cada venta.
Cierra el módulo: resultado del periodo, cascada de lo facturado a lo que queda, evolución mensual, desglose por tipo y umbral de facturación.
DECISIONES DE REPRESENTACIÓN - El resultado es un TITULAR, no un gráfico: un solo número no se dibuja, se escribe grande. Y cambia de color solo cuando es negativo, con una frase que explica por qué. - La cascada usa color con SIGNIFICADO (entra / sale / queda), no color por categoría: los importes tienen polaridad, no identidad. - El desglose por tipo va en TABLA.
Donde el agente registra lo que ha firmado: la venta escriturada, el alquiler o el contrato de gestión, con sus honorarios y lo que costó sacarla adelante.
DOS EXPORTACIONES, PORQUE SIRVEN A DOS COSAS DISTINTAS - "Facturación": una fila por LÍNEA con los datos fiscales repetidos. Es el formato que otro programa de facturación puede importar directamente, y hace que el módulo sirva sin depender del ERP ni de Verifactu. - "Rentabilidad": una fila por operación con márgenes y estructura asignada, para analizar en una hoja de cálculo.
Base para el módulo de facturación y rentabilidad de una inmobiliaria.
MODELO - crm_operaciones: la venta escriturada, el alquiler firmado o el contrato de gestión. Es el hecho que genera factura, NO la oportunidad ganada: entre aceptar una oferta y firmar pasan meses y muchas se caen, y con Verifactu una factura emitida de más no se borra, se rectifica ante Hacienda. - crm_operacion_líneas: lo que se factura.
Se coloca justo después del hero, antes de que haya que leer nada: quien llega puede entender el producto en dos minutos sin recorrer las tres puertas de la demo. Enlazado desde el menú de escritorio y el de móvil.
Se usa el mismo patrón que los vídeos de /inmobiliarias/ —aspect-video con el iframe en absoluto— en lugar del padding-bottom al 56,25 % del código original. Es equivalente pero no depende de un número mágico que hay que recalcular si algún día cambia la proporción.
La RPC ordena por `semana desc` y "semana 7" significa hace siete semanas, así que el array llega de MÁS ANTIGUA a MÁS RECIENTE — que es justo como se lee un gráfico de izquierda a derecha.
Con datos reales el fallo es evidente: una tendencia que sube de 48 a 119 se pintaba bajando de 119 a 48, y la barra destacada como "esta semana" mostraba 48, que es la de hace ocho semanas. A un propietario le estaríamos diciendo que el interés por su casa se desploma cuando se ha duplicado.
Las ilustraciones generadas en SVG eran honestas pero no vendían: un portafolio inmobiliario se juzga por las fotos. Se sustituyen por fotografías reales de Pexels, cuya licencia permite uso comercial sin atribución.
18 fotos (6 inmuebles × 3), servidas desde el propio dominio como el resto de activos: no dependen de que un tercero siga en pie ni de su CDN.
La zona privada del propietario no cargaba NADA. La migración 20260808000700 filtraba las visitas con `status is distinct from 'cancelled'`, pero bookings.status es un ENUM cuyos valores son confirmed, cancelled_by_custo…
Postgres no lo trata como "no coincide": lanza invalid input value for enum booking_status: "cancelled" y eso tumba la función ENTERA. No fallaba un bloque, fallaba todo y la página se quedaba en blanco.
El producto se ve distinto según quién lo mire, así que la demo son tres sitios y no uno:
1. Lo que ve el comprador → /portal/inmodemo/ (portafolio real, ya construido) 2. Lo que ve la agencia → /demo/?ir=portal (CRM efímero, 1 hora) 3. Lo que ve el propietario→ /p/?t=… (zona privada, enlace real)
39 € colocaba el producto en la casilla equivocada: al lado de la web de Witei a 19 €/mes, donde el comprador compara webs.
59 € además hace algo que 39 € no hacía: deja Esencial (79 €, con CRM y los canales IA) a solo 20 € de distancia. El ascenso pasa de ser una decisión a ser un sí fácil, y es en el pack donde está el margen.
Cloudflare Pages lee esos archivos desde la CARPETA PUBLICADA (out/), y Next con `output: export` solo copia ahí lo que hay en public/.
Se vio al comprobar que /portafolio/ devolvía 200 en vez del 301 a /demuestra24/: la redirección estaba escrita en el archivo muerto.
"Portafolio" nombraba el envoltorio, no el argumento. Lo que vende esto es que el propietario VEA lo que haces por vender su casa, así que el nombre tenía que decir eso: demuéstralo.
Entra además en la familia de marca que ya existe —Atiende 24, Comercia 24, Cita 24, Clínica 24— que es verbo + 24. Y sirve para cualquier agencia, trabaje con exclusiva o sin ella, cosa que "Exclusiva 24" no habría hecho: en España se trabaja mucho sin exclusividad.
globals.css declaraba "Inter" pero la fuente NO se cargaba en ninguna parte: ni next/font, ni enlace a Google, ni @font-face.
El portal usaba además font-serif, que cae en la pila por defecto de Tailwind: Georgia en Mac pero Times New Roman en Windows. La intención era una serif de catálogo cuidado; a media España le salía Times.
Landing propia en /portafolio/ y producto portal_solo (39 €/mes, alta 290 €, anual 312 €). Hay agencias a las que les seduce un servicio u otro pero no los dos, y hoy no había forma de venderles solo el escaparate.
EL TITULAR ES LA ZONA PRIVADA DEL PROPIETARIO, no la web. Una web inmobiliaria la incluye Inmovilla en su plan de 79 € y Witei la vende a 19 €/mes: si el argumento es "te hacemos una web", esto es un commodity y la conversación acaba en precio. La zona privada no la tiene nadie, y es lo que sostiene una exclusiva cuando llega el mes cuarto.
El portal prometía en cinco sitios que la agencia responde "en minutos". Hoy es cierto porque todo cliente del portafolio lleva la Secretaria IA incluida en su pack, pero al vender el portafolio suelto deja de serlo — y…
El daño además no lo pagamos nosotros: esa página lleva el logo y el nombre de la agencia. El comprador que escribe un sábado por la noche y no recibe respuesta hasta el lunes no concluye que le hemos mentido nosotros, sino que esa inmobiliaria le ha dejado tirado.
El portal estaba construido y en producción, pero no aparecía en ninguna página donde se venda: el diferencial era invisible para un prospecto.
Sección #portafolio entre Visitas y Precios, con enlace en el menú de escritorio y móvil. El titular NO vende una web —eso lo incluye Inmovilla en su plan de 79 € y Witei lo vende a 19 €/mes, así que por ahí la conversación acaba en precio— sino la respuesta a "¿qué estás haciendo por vender mi casa?", que es la pregunta que rompe exclusivas.
Completa los dos bloques que faltaban del panel del propietario: "qué pregunta quien la mira" y "lo que hemos hecho esta semana".
No se podían construir porque el CRM ata llamadas, visitas y conversaciones al CONTACTO, y nadie sabía a qué vivienda se refería: la referencia viajaba solo en el texto del mensaje. property_contacts cierra ese hueco y form-submit crea el vínculo al recibir el lead, validando que la propiedad sea de la misma organización para que un property_id inventado desde el navegador no c…
Cada inmobiliaria publica su cartera en /portal/<agencia>/, y cada ficha capta leads hacia el CRM para que la Secretaria IA responda al instante.
El enfoque NO es "una web de propiedades" —eso lo incluye Inmovilla en su plan y Witei lo vende por 19 €/mes—, sino la prueba de trabajo ante el PROPIETARIO: un enlace privado donde el dueño ve cada semana el interés que despierta su casa. Es lo que responde a "¿qué estás haciendo por vender mi casa?", la pregunta que rompe exclusivas.
El patrón +34 estaba repetido en cinco sitios y todos rechazaban a un comprador extranjero. En un portal inmobiliario de costa eso deja fuera a medio mercado: un británico o un alemán no podía ni dejar su número.
Todos pasan a E.164 (^\+[1-9]\d{7,14}$): - contacts_phone_check (migración) - form-submit devolvía invalid_phone - bot-capture-lead devolvía invalid_phone - booking-create se saltaba la creación del contacto EN SILENCIO - integration-sync-contacts descartaba el teléfono de todo contacto extranjero importado, también en silencio