Crawlbase es el cliente número uno, así que la primera ronda seria de Knockwire apuntó a nuestro propio negocio. Escribimos un perfil de cliente ideal a partir de lo que creíamos sobre nuestras mejores cuentas, apuntamos el sistema hacia allá, y después nos sentamos a leer los primeros cien rechazos en orden. El perfil estaba mal en dos lugares. Los dos errores eran visibles en las empresas que rechazamos e invisibles en las que calificaron.
01Lea los rechazos, no los aciertos
El registro de rechazos es la parte de este producto que publica lo que se declinó y por qué. Cada rechazo carga un motivo escrito y no un código, lo que significa que el registro se puede leer como prosa en lugar de contarse, y leerlo de punta a punta es un ejercicio distinto de recorrer la lista de calificadas.
La lista de calificadas le da la razón. Tiene que dársela. Una empresa calificó porque coincidió con el perfil que usted escribió, así que una página de empresas calificadas es una página de sus propios supuestos devuelta con logotipos encima. Los rechazos son el único lugar donde el perfil se topa con algo que no predijo. Una empresa que supera todos los filtros menos uno, con un motivo escrito en el filtro que la detuvo, es un pequeño argumento en contra de la regla que la detuvo.
Dos de esos grupos no dicen nada sobre nosotros. Las empresas muertas son higiene, y sin puerta utilizable es un hecho sobre un sitio web y no sobre nuestro perfil. Los otros tres son el perfil siendo puesto a prueba, y dos de ellos estaban discutiendo con nosotros por escrito.
02Primer error: habíamos escrito empresas que necesitan datos
Nuestro objetivo declarado eran empresas que necesitan datos. Es la clase de frase que sobrevive a un taller porque nadie puede estar en desacuerdo con ella, y estaba mal de la manera en que suelen estarlo las frases amplias. Admitía muchísimo de más, y los filtros detrás de ella se pasaron la ronda entera devolviendo el excedente.
Treinta y cuatro de los primeros cien rechazos cargaban una versión del mismo motivo escrito: aquí los datos son un insumo, no el producto. Cada una de esas empresas había pasado sin problema la verificación del perfil. Una empresa de logística que extrae tarifas de transportistas tiene una necesidad real de datos. También la tiene un minorista que vigila precios de la competencia, y un banco que revisa listas de sanciones. En los tres casos la recolección es una partida que alguien en finanzas está tratando de reducir, y ese hecho fija el techo de lo que llegarán a gastar.
Un rechazo así se lee como un caso que quedó cerca. Treinta y cuatro se leen como una definición. El filtro de evidencia había deducido el atributo que le faltaba a la frase de nuestro perfil, y lo había estado anotando en castellano llano, una vez por empresa, durante quince días antes de que alguien leyera el registro desde arriba.
Nuestras doce mejores cuentas por ingreso acumulado no se parecen en nada a esas treinta y cuatro. Las doce venden un producto de datos. La recolección es su costo de ventas y no una actividad lateral, que es por lo que su gasto sube cuando al negocio le va bien en lugar de bajar cuando se revisa el presupuesto. Se agrupan en tres familias de objetivos, marketplaces, viajes y datos de personas o empresas, y todos esos objetivos bloquean el tráfico casual.
Así que el objetivo no es una empresa que necesita datos. Es una empresa cuyo producto son los datos, que ya está haciendo scraping y que la está pasando mal con eso. Esa versión es más estrecha, más nítida y contestable al momento de la lectura, porque usted puede mirar una empresa y ver qué vende. No puede mirar una empresa y ver cuánto necesita algo.
03Segundo error: contamos personas en lugar de volumen
El segundo error fue más callado y nos costó más, porque rechazaba empresas en lugar de solo desperdiciar lecturas en ellas. Habíamos puesto un piso de personal en el perfil suponiendo que el tamaño de la empresa predice el presupuesto.
El tamaño sí predice el presupuesto, débilmente, y en la dirección equivocada para este mercado. Varias de las cuentas más fuertes de nuestra cartera son equipos pequeños con volumen muy pesado: empresas de un solo producto donde un puñado de ingenieros corre recolección continua contra objetivos que se defienden. El número de personas es un sustituto del gasto, y es un sustituto pobre en cuanto el producto son los datos, porque el volumen viene del objetivo del crawl y no del organigrama. Ocho personas indexando un marketplace con millones de anuncios gastan más que cuatrocientas que jalan una lista de precios de la competencia cada lunes.
En el registro esto apareció como una contradicción antes que como un patrón. Catorce empresas fueron rechazadas por tamaño mientras cargaban evidencia fuerte en todo lo demás, así que sus motivos escritos se leían como argumentos contra sí mismos: calificada por familia de objetivos, calificada por evidencia de recolección, por debajo del piso de personal. Cuando usted tiene una docena de rechazos con esa forma, ya no tiene un piso de personal. Tiene un error que todavía no ha admitido.
Quitamos el piso y pusimos en su lugar dos preguntas observables: ¿la familia de objetivos bloquea el tráfico casual, y la superficie pública implica recolección continua en lugar de un proyecto con fecha de término? Las dos se contestan con evidencia que una fuente devolvió de verdad. Ninguna nos pide adivinar una nómina.
04Un perfil de cliente ideal es una hipótesis
La lección general es sobre qué clase de objeto es un perfil. Tratábamos el nuestro como una descripción de clientes que ya teníamos, cuando en realidad era una hipótesis: escrita antes de la evidencia, arrastrada sin examen y nunca puesta a prueba contra aquello que excluía. Una descripción se verifica mirando. Una hipótesis se verifica observando lo que desecha, y un registro de rechazos es el acta de todo lo que un perfil desechó, con el motivo adjunto.
Eso cambia lo que uno hace con los primeros cien de cualquier cosa. El instinto es leer las empresas calificadas y decidir si el sistema funciona. La pasada útil es leer los rechazos y decidir si el perfil funciona. En nuestro caso el sistema hizo exactamente lo que se le dijo, dos veces, y lo que se le dijo estaba mal.
Lo que nos lleva a lo que nos negamos a hacer aquí. No ajustamos el perfil a espaldas del operador. Nada en este proceso auto ajusta el perfil de cliente ideal a partir del comportamiento de aprobación y rechazo, aunque los datos para hacerlo están ahí mismo y la demostración se vería excelente.
La razón es que un perfil que se ajusta solo vuelve ilegible el registro de rechazos. El registro solo vale la pena publicarlo si un motivo significa lo mismo en marzo que lo que significaba en enero. Si las reglas se mueven por su cuenta, nadie puede saber si una empresa fue declinada porque cambiaron sus circunstancias o porque la regla se movió por debajo, y cada rechazo histórico se convierte en una afirmación sobre una versión del perfil que nunca se escribió.
Así que el sistema propone y el operador decide. Cuando los rechazos se agrupan, mostramos el grupo: aquí hay treinta y cuatro empresas declinadas por el mismo motivo escrito, aquí está el filtro que las declinó, aquí está el cambio al perfil que las habría dejado pasar, y aquí está lo que ese cambio le habría hecho al resto de la ronda. El operador lo lee y toma la decisión. Un cambio al perfil de cliente ideal es una decisión con fecha y con nombre, y los dos errores de arriba se corrigieron así, a la vista, por una persona.