Cómo calcular capacidad de envío en cold email sin copiar un límite mágico por inbox

Google Workspace y Exchange Online publican límites de envío para proteger sus servicios. Esos techos describen lo que una cuenta puede intentar antes de ser restringida bajo determinadas condiciones; no certifican inbox placement, consentimiento, relevancia ni conveniencia comercial. Usarlos como cuota de cold email confunde disponibilidad técnica con capacidad operativa.

Los límites también cambian por plan, antigüedad, tipo de destinatario, ventana temporal y política del proveedor. Google advierte que puede suspender temporalmente el envío cuando una cuenta rebasa un límite. Microsoft señala que los límites de Exchange Online no están diseñados para bulk-email scenarios. Por eso el dato debe consultarse en la documentación vigente y guardarse como restricción, no como meta.

La postura útil es trabajar con capacidad autorizada y observada. Autorizada significa compatible con contrato, política y reglas aplicables. Observada significa que el dominio, los inboxes, la lista y el equipo han demostrado estabilidad sobre una cohorte real. Si una de las dos falta, el número todavía no está listo para producción.

Primera: proveedor. Registra límite de mensajes, destinatarios y tasa, además de restricciones del plan. Segunda: infraestructura y reputación. Revisa autenticación, errores, spam reportado y señales disponibles por proveedor receptor. Tercera: datos. Solo cuentan contactos aprobados, deduplicados, no suprimidos y con estado de validación permitido.

Cuarta: presión comercial. Una cuenta puede tener varios contactos, campañas y canales. Define cuántas conversaciones simultáneas tolera sin recibir mensajes cruzados. Quinta: capacidad humana. Si el equipo puede revisar y responder veinte conversaciones relevantes al día, programar un volumen que potencialmente produzca muchas más crea una cola en el punto más valioso del embudo.

La capacidad diaria será el menor valor que permita cumplir las cinco restricciones. No hace falta disfrazarlo de fórmula científica: si proveedor permite más, pero faltan leads aprobados o owner para replies, el cuello de botella está ahí. Aumentar inboxes no elimina un límite aguas abajo; solo ayuda a llegar antes.

Crea un inventario con domain_id, inbox_id, proveedor, plan, fecha de alta, SPF, DKIM, DMARC, owner, campaña, zona horaria, límite contractual consultado, volumen configurado y estado. Añade eventos diarios: enviados, aceptados por servidor, errores temporales, rechazos permanentes, respuestas, bajas y quejas cuando el proveedor las exponga.

Para cada lead conserva account ID, contact ID, fuente, fecha, estado de validación, supresión, segmento y razón de inclusión. Sin esos campos, una caída de entrega no podrá separarse entre infraestructura, fuente de datos o cohorte. El promedio global suele esconder que un inbox o proveedor receptor concentra el problema.

Guarda también presión de cuenta: contactos activos, último toque, campaña, respuesta y oportunidad. La capacidad no debe medirse únicamente por buzón remitente. Dos inboxes pueden cumplir su cuota individual y aun así escribir a la misma empresa con mensajes distintos durante la misma semana.

Empieza por el universo elegible: leads que pasaron ICP, validación y supresión. Después aplica límites de cuenta para evitar multithreading accidental, reserva margen para follow-ups y bloquea capacidad para reintentos controlados. El presupuesto de mensajes nuevos es lo que queda después de compromisos existentes, no el total disponible del inbox.

Distribuye por cohortes y dominios con una regla explícita. Por ejemplo, asigna cada cuenta a un solo campaign ID y cada contacto a un solo inbox durante la ventana. Evita que el balanceador cambie de remitente a mitad de secuencia, salvo un proceso documentado. La continuidad ayuda a conservar contexto y simplifica atribución.

No publiques una cifra universal de mensajes por inbox. Un dominio con historial, lista estable y operación madura no tiene el mismo perfil que una cuenta nueva, un segmento no probado o un proveedor con señales deterioradas. El punto inicial debe ser conservador respecto al historial propio y subir en pasos pequeños después de una ventana suficiente de observación.

Google exige autenticación a remitentes hacia Gmail personal y pide mantener spam reportado por debajo de 0.3%; además recomienda permanecer por debajo de 0.1%. Yahoo publica también 0.3% como límite que los bulk senders no deben alcanzar. Son límites de riesgo para esos ecosistemas, no objetivos operativos ni garantía de entrega.

No esperes a una queja para actuar. Pausa ante picos de hard bounce, errores de autenticación, bloqueos, cambios bruscos por proveedor receptor, opt-outs no sincronizados, personalizaciones rotas o replies sin owner. Define umbrales internos más conservadores según historial y riesgo. Cuando la muestra sea pequeña, reporta conteos junto al porcentaje para no sobrerreaccionar a un solo evento ni ignorarlo.

Decide el alcance de la pausa. Un error DNS puede afectar al dominio; una fuente mala, a la cohorte; credenciales vencidas, a un inbox; una oferta irrelevante, al segmento. Apagar todo puede ser prudente mientras investigas, pero el diagnóstico debe encontrar la capa exacta antes de reanudar.

Aumenta una variable a la vez: más leads nuevos dentro del mismo segmento, otro inbox bajo el mismo proceso o una nueva cohorte con volumen limitado. Mantén constantes oferta, validación y reglas de salida cuando quieras medir infraestructura. Si todo cambia junto, cualquier estabilidad será imposible de atribuir.

Revisa resultados por inbox, dominio, fuente, receptor, segmento y periodo. El promedio de diez buzones puede verse sano mientras uno acumula errores. También puede ocurrir lo contrario: un problema concentrado en direcciones inválidas de una fuente no justifica culpar a toda la infraestructura.

Antes de ampliar, confirma que el equipo atendió replies dentro de su SLA, que bajas y rebotes llegaron a supresión y que reuniones regresaron al CRM. Capacidad comercial no es cuántos correos pueden salir; es cuántos eventos puede procesar el sistema sin perder contexto ni control.

Supongamos que el proveedor permitiría un volumen alto, pero la cohorte aprobada contiene pocas cuentas y el equipo solo tiene una persona para responder. El presupuesto debe quedar limitado por leads válidos, presión por cuenta y capacidad de seguimiento. Comprar más inboxes no mejora ninguna de esas tres variables.

En otro caso, hay suficientes leads y owners, pero crecen los errores en un dominio. La capacidad de ese dominio baja a pausa o diagnóstico aunque los demás sigan estables. Redistribuir inmediatamente todo el volumen puede trasladar el problema o crear un pico; primero confirma causa, supresiones y estado de las cuentas afectadas.

El método evita dos extremos: una cuota fija que ignora señales y una operación que cambia el volumen por intuición cada mañana. La capacidad se convierte en una decisión versionada con entradas, owner, fecha y motivo.

Clay puede preparar cuentas, validación, señales y estado de elegibilidad. Instantly o Smartlead pueden ejecutar secuencias y devolver eventos. El CRM conserva cuenta, owner, respuesta, reunión y oportunidad. Una capa central debe mantener supresiones, presión por cuenta y el presupuesto por inbox para que cada herramienta no calcule capacidad en aislamiento.

Configura gates antes de enviar: lead elegible, account lock disponible, inbox activo, presupuesto restante, autenticación sin alerta y owner asignado. Después del evento, descuenta capacidad de forma idempotente y actualiza estados. Un reintento de webhook no debe duplicar el consumo ni el mensaje.

picos.Ai puede diseñar este control de capacidad y probarlo con una cohorte: inventario de dominios e inboxes, reglas, panel por receptor, stop conditions y conexión con replies y pipeline. El objetivo no es encontrar el máximo diario. Es operar un volumen que el sistema pueda justificar, atender y aprender a ampliar.