Integración con Pathlight

La pregunta que gobierna esta sección: cómo se le permite a un operador apretar un botón que le cuesta dinero real al estudio, sin exponer al comprador a una cuenta desbocada. Esa frase suena a un efecto secundario de preocuparse por el costo, pero en realidad es la restricción que dio forma a toda la integración. Donde haya un cobro por llamada en el camino, el costo es un comodín a menos que algo lo detenga a propósito. La respuesta estándar es 'facturación por uso con un umbral de alerta suave'. He leído suficientes autopsias de ese patrón como para saber qué pasa cuando la alerta se dispara a las tres de la mañana y el ingeniero que puede apagar el interruptor está dormido: la cuenta sigue creciendo durante toda la ventana entre la alerta y la respuesta. Cada capa de alertas que he montado encima de una facturación por uso ha terminado por filtrarse. Así que construí la integración con la postura inversa: la cuenta no puede crecer más allá del tope, por construcción, esté o no despierto alguien. La integración está resguardada por controles que tienen que pasar todos antes de que se dispare cualquier llamada. Los límites de gasto, las reglas de alcance y las condiciones de disparo pueden detener una llamada cada uno por su cuenta. Los límites de gasto detienen una llamada cuando el tope de presupuesto del periodo ya no tiene margen, revisado y reservado de forma atómica contra la misma escritura que registra el gasto. Las reglas de alcance detienen una llamada cuando la instalación no fue configurada para el tipo de trabajo que se está pidiendo. Las condiciones de disparo detienen una llamada que no venga de una acción deliberada del operador; cada camino de disparo es o un clic directo, o una regla cuyo disparo exige aprobación humana explícita. Si cualquiera de esas revisiones bloquea la llamada, no se dispara nada y el operador ve la razón. No hay un camino dentro de la integración que permita que el costo crezca sin control, porque toda llamada con costo tiene que pasar todos los controles antes de llegar al servicio de arriba. Consideré escaneos programados en segundo plano con facturación por uso como el punto de partida obvio. Despertar, escanear la lista de prospectos, mostrarle los hallazgos al operador. Es el patrón que trae casi toda herramienta de agencia. Lo rechacé por dos razones. La primera es el problema del costo desbocado que ya describí: un error en el programador que vuelva a encolar tareas más rápido de lo que se completan no se puede acotar con un umbral suave; solo un tope duro con reserva atómica puede detenerlo. La segunda es el problema de la confianza del operador: cuando el sistema puede escanear por su cuenta, el operador deja de ser quien eligió gastar el dinero del estudio. Cada instalación de Canopy tiene que sentirse como un local del que el comprador tiene las llaves, y un sistema que le cobra por acciones que nunca autorizó es exactamente lo contrario. El mecanismo del límite de gasto es la parte que más iteraciones llevó. La forma ingenua es revisar y luego reservar: leer el consumo del periodo, compararlo con el tope, y si hay margen, disparar la llamada y después escribir la fila de consumo nueva. Dos clics simultáneos de administración en el instante exacto en que al presupuesto le queda margen para un solo escaneo pueden pasar los dos esa revisión, disparar los dos, y dejar al comprador por encima del tope. Ese es un error de libro de texto de tiempo de revisión contra tiempo de uso, y el arreglo de libro de texto es revisar y reservar de forma atómica: la misma escritura que registra la fila de consumo nueva está condicionada a que el tope no se rebase. O la fila entra y la llamada puede dispararse, o la fila no entra y la llamada recibe un bloqueo visible para el usuario. No hay ventana donde dos caminos simultáneos puedan pasar los dos. Ese arreglo salió en el trabajo de cierre de auditoría del 5 de mayo; antes de eso, la revisión del límite de gasto era correcta con un solo operador, pero tenía esa ventana de concurrencia. El arreglo es una sola escritura condicional a la base de datos; o afecta una fila o afecta cero, nunca dos. Las revisiones de alcance y de condición de disparo son más simples en mecanismo e igual de importantes en postura. El alcance es por instalación: una instalación de Canopy donde el comprador no se ha suscrito a la integración con Pathlight no puede disparar ninguna llamada, por más que todos los demás controles pasaran. Eso significa que la integración llega apagada en cada instalación nueva y se enciende solo cuando el comprador firma el servicio que la incluye. El requisito de disparo significa que no hay proceso programado, ni planificador, ni retroalimentación del bucle de eventos que pueda disparar una llamada a Pathlight sin que un operador haya hecho clic en algo. Existen disparos acotados por reglas, cuando un negocio llega a una etapa donde volver a escanear tiene sentido o cuando el sitio de un cliente marca un cambio que vale la pena revisar, pero cada regla que dispara Pathlight exige aprobación humana explícita antes de que la llamada pase. La regla encola la llamada como pendiente de aprobación; el operador aprueba; la llamada se dispara. La aprobación no es una casilla en la regla misma; es una acción por llamada. La integración aparece en tres lugares dentro de Canopy. La investigación de candidatos de prospección es el más común: un operador elige un contacto o una lista de contactos, lanza un escaneo de Pathlight contra el dominio de cada prospecto, y el resultado entra al pipeline como un registro adjunto al contacto. El puntaje del escaneo se vuelve un campo por el que se puede ordenar; las recomendaciones se adjuntan a las notas del prospecto; el operador puede redactar un correo de seguimiento citando hallazgos concretos. El monitoreo de cambios es el segundo: los sitios de clientes existentes se vuelven a escanear con cierta periodicidad, pero esos reescaneos se encolan para revisión del operador en lugar de dispararse solos, y la cola aparece en el aviso de operaciones cuando hay algo esperando. La inteligencia competitiva es el tercero: un operador puede escanear a un competidor directo del comprador y guardar el resultado junto al historial de escaneos del propio comprador, para que la siguiente conversación sobre posicionamiento tenga datos de los dos lados de la mesa. Los tres pasan por el mismo camino de controles. No hay un camino privilegiado que los evite por ninguna razón. El modo de falla contra el que más cuidado tuve es justo el que motivó la revisión y reserva atómica: dos clics de administración en el mismo instante cuando al presupuesto le queda margen para un solo escaneo. Los dos no pueden pasar. Un escaneo se dispara, el otro recibe un bloqueo visible que nombra el tope de presupuesto como la razón. El bloqueo es una superficie real de interfaz, no un error lanzado: el operador ve 'se alcanzó el tope de presupuesto, este escaneo no se ejecutó' y un enlace al aviso de operaciones donde se ven el tope y la fecha en que se reinicia el periodo. La misma forma aplica si el alcance no está habilitado para esa instalación, o si falta la aprobación manual de un disparo por regla. El trabajo de la arquitectura es hacer el bloqueo legible, no solo impedir la llamada. Un segundo modo de falla que vale la pena nombrar: la llamada pasa todos los controles, el intento ocurre, y el servicio de Pathlight falla por una razón ajena. La reserva ya se escribió y el presupuesto ya se descontó; la llamada no produjo resultado. El comportamiento correcto es devolver: una liberación que regresa las unidades reservadas al presupuesto disponible. Canopy implementa esa liberación en el camino de falla, para que al comprador nunca se le cobre una llamada que no produjo un entregable. La liberación es atómica contra la misma fila que escribió la reserva, por la misma razón por la que la reserva tiene que ser atómica desde el principio. El encuadre honesto sobre el costo: un cobro externo por llamada como partida recurrente solo cabe en un servicio productizado cuando el costo es un máximo mensual conocido y no un comodín. El precio de Canopy para las instalaciones que incluyen la integración con Pathlight se estructura alrededor del tope de presupuesto. El comprador elige un tope que corresponda al volumen de escaneos que espera correr; el estudio corre escaneos contra ese tope; el tope es el techo. No hay escenario en el que la cuenta del comprador supere el tope, porque no hay camino de código que permita disparar un escaneo cuando el tope ya se alcanzó. Cada partida está acotada. La consecuencia operativa que el comprador siente es exactamente la que la arquitectura persigue: la partida por llamada es un máximo mensual fijo, todos los meses, por construcción. No por esperanza, ni por alertas, ni por reconciliación posterior. El tope es el techo, el tope se aplica en la misma escritura que registra el gasto, y al comprador nunca le llega una cuenta sorpresa por un bucle desbocado. Esa es la versión de una integración con costo que cabe en un servicio productizado y, hasta donde puedo ver, es la única que cabe.