ATS vs CRM vs PSA: diferencias, solapes y arquitectura correcta

    ATS vs CRM vs PSA: diferencias, solapes y arquitectura correcta - Stack Tecnológico

    ATS, CRM y PSA en una frase

    SistemaObjeto principalPregunta
    ATSCandidatos y talent pool¿A quién podemos contratar o presentar?
    CRMCuentas, contactos y oportunidades¿A quién vendemos y qué puede cerrar?
    PSAProyectos, personas, horas y margen¿Qué entregamos y con qué resultado?
    Plataforma unificadaRelación entre talento, cliente y delivery¿Qué decisión operativa toca ahora?

    Cada firma de consultoría que hemos auditado utiliza al menos dos de estos tres sistemas. La mayoría utiliza los tres, y aproximadamente la mitad paga por herramientas que se solapan tanto que los datos viven en dos o tres lugares simultáneamente, sin que ninguno sea autoritativo. Las costuras entre ATS, CRM y PSA son donde la productividad muere silenciosamente. Las personas dejan de confiar en los números. Los informes se reconstruyen en hojas de cálculo. Los account managers y los reclutadores se persiguen buscando actualizaciones que deberían haber sido una consulta a la base de datos. Y cada trimestre, alguien abre una factura de renovación y pregunta: ¿realmente necesitamos todas estas herramientas?

    Esta es la entrada enciclopédica para esa pregunta. Definiremos cada sistema sin rodeos, trazaremos las líneas que los separan, marcaremos las zonas de solapamiento, presentaremos los tres arquetipos de integración que funcionan en el mundo real, daremos una matriz de decisión para la consolidación y terminaremos con lo que cambia en un stack AI-native.

    Las definiciones limpias

    Antes de discutir sobre solapamientos, tenemos que acordar qué significa realmente cada acrónimo. La industria es descuidada al respecto, los vendedores son deliberadamente descuidados porque las fronteras vagas venden más licencias, y el resultado es una Torre de Babel donde dos directores de operaciones de dos firmas pueden usar la palabra CRM y referirse a software completamente diferente.

    ATS significa Applicant Tracking System, sistema de seguimiento de candidatos. Su trabajo es el funnel de candidatos: búsqueda, screening, entrevistas, ofertas y onboarding de personas que podrían trabajar para o a través de su firma. La unidad de dato es el candidato. El flujo principal es mover ese candidato a través de etapas, desde un perfil bruto encontrado hasta un resultado de contratación o rechazo. Las buenas plataformas ATS incluyen parsing de CV, visualización de pipelines, programación de entrevistas, scorecards e integración con los canales de sourcing que utilice.

    CRM significa Customer Relationship Management, gestión de relaciones con clientes. Su trabajo es el funnel de clientes: prospectos, oportunidades, tratos, cuentas, contactos. La unidad de dato es el lead o la cuenta, según la etapa. El flujo principal es mover una oportunidad desde el primer contacto hasta el cierre, y luego gestionar la relación continua con esa cuenta. Las buenas plataformas CRM incluyen integración de email, pronósticos de pipeline, seguimiento de actividad e informes sobre tasas de cierre.

    PSA significa Professional Services Automation, automatización de servicios profesionales. Su trabajo es la entrega y la facturación: convertir un trato cerrado en un proyecto con personal asignado, rastrear el tiempo y los gastos del proyecto, facturar al cliente y reconocer ingresos. La unidad de dato es el proyecto o encargo, con todo lo demás (personas, tiempo, gastos, facturas) colgando de él. El flujo principal es el ciclo completo desde la creación del proyecto hasta la planificación de recursos, captura de tiempos, facturación y cierre. Las buenas plataformas PSA incluyen planificación de recursos, reporting de utilización, facturación por milestones y reconocimiento de ingresos.

    Si recuerdan una sola cosa de este artículo, recuerden la versión en una frase: ATS es para personas que podrían contratar, CRM es para clientes a los que podrían vender, PSA es para proyectos que están entregando y facturando. Tres funnels diferentes, tres unidades de dato diferentes, tres grupos de usuarios diferentes dentro de su firma.

    El modelo mental

    Imaginen tres tuberías que desembocan en una piscina central que es los ingresos de su firma.

    La tubería ATS trae personas. Reclutadores y sourcers están en un extremo. Por el otro salen consultores, ingenieros, diseñadores, analistas — humanos facturables que eventualmente serán asignados a proyectos.

    La tubería CRM trae tratos. Account executives, socios y responsables de desarrollo de negocio están en un extremo. Por el otro salen contratos firmados, statements of work, acuerdos marco — compromisos de clientes de pagar a su firma por resultados.

    La tubería PSA es donde ocurre la magia. Toma a las personas de la primera tubería y los tratos de la segunda, los combina en proyectos, ejecuta esos proyectos hasta completarlos, captura las horas y convierte esas horas en facturas e ingresos reconocidos. PSA es el único de los tres donde el dinero efectivamente cambia de manos.

    ATS CRM [candidatos] [oportunidades]

           |                    |

    v v Consultores Contratos contratados cerrados

                \              /
                 \            /

    v v PSA

           (personas + deal -> proyecto)
                      |

    v Entrega

                      |

    v Facturacion

                      |

    v Ingresos

    Este diagrama está deliberadamente simplificado, porque en el momento en que añaden las zonas de solapamiento se convierte en un nudo. Pero la forma básica se sostiene. Dos funnels de entrada, un motor de entrega y facturación. Sin el motor, los funnels son solo listas. Sin los funnels, el motor no tiene nada sobre lo que correr.

    Profundización en ATS

    Un Applicant Tracking System existe porque contratar a cualquier escala es imposible de gestionar en una hoja de cálculo. Una vez que tienen más de un puñado de posiciones abiertas y más de uno o dos reclutadores trabajándolas, necesitan etapas, estados, registros de candidatos, historial de comunicaciones y la capacidad de hacer preguntas como qué sourcer está cerrando ofertas más rápido en el pipeline de ingenieros senior.

    Lo que hace bien un ATS: ingesta estructurada de candidatos desde múltiples canales, parsing de CV a perfiles buscables, pipelines por etapa por rol o requisición, coordinación de entrevistas incluyendo integración con calendarios, recolección de scorecards de los entrevistadores, gestión de ofertas y cada vez más un handoff ligero al onboarding. Las mejores plataformas ATS (Greenhouse, Lever, Ashby en la ola moderna; Bullhorn, JobAdder, JobDiva en la ola staffing; Workable, Recruitee, SmartRecruiters en pymes) hacen todas estas cosas razonablemente bien.

    Lo que no hace un ATS: no rastrea lo que hace un candidato después de convertirse en empleado o contractor. No captura horas facturables. No genera facturas al cliente. No gestiona oportunidades o tratos. No rastrea la rentabilidad del proyecto. En el momento en que una persona cruza la línea de candidato a consultor, el ATS efectivamente se silencia sobre ella, y otro sistema tiene que tomar el relevo.

    ¿Cuándo necesita realmente una firma de consultoría un ATS dedicado? Dos respuestas, ambas honestas.

    Sí si son una firma de headhunting, search o staffing donde colocar candidatos es su modelo de negocio. Toda su cuenta de resultados gira sobre la velocidad y calidad del funnel de candidatos. Probablemente necesiten un ATS enfocado en staffing como Bullhorn o JobDiva, donde el ATS es en sí mismo un sistema operativo principal y se integra estrechamente con la facturación de colocaciones.

    A menudo no si son una firma de pura consultoría IT, estrategia o management que contrata a un puñado de personas al año y la mayor parte de la complejidad operativa está del lado cliente y entrega. Un PSA capaz con un módulo de recruiting básico, o un ATS standalone ligero para pymes, puede cubrirlos. Lanzar Greenhouse a una consultora de 40 personas que contrata 12 personas al año es sobredimensionamiento.

    El criterio de decisión son las contrataciones por trimestre y la centralidad estratégica de la contratación. Si contratar es una función constante de alto volumen, quieren un ATS dedicado. Si contratar es un proyecto una vez por trimestre gestionado por un managing partner con una hoja de cálculo, no paguen Greenhouse.

    Profundización en CRM

    El CRM es el sistema más colonizado por los vendedores de software. Salesforce por sí solo ha entrenado a dos generaciones de operadores para asumir que CRM es sinónimo de pipeline de ventas, lo cual es cierto a nivel de copy de marketing y falso a nivel de operativa real de una firma de consultoría.

    Los CRM genéricos están construidos para ventas transaccionales. Su unidad de valor asumida es un trato: un compromiso monetario discreto, cerrado en una fecha, vinculado a una cuenta. Esto funciona perfectamente para ventas SaaS, licencias de software, hardware, cualquier negocio donde el trato se cierra y la relación puede ser básicamente entregada a un equipo de customer success.

    Las firmas de consultoría no funcionan así. El valor de una firma de consultoría no es un trato, es un proyecto. El trato es solo el permiso para empezar el proyecto. La complejidad real, el margen real, la experiencia cliente real ocurren todas dentro del proyecto, no en el momento de la firma. Y los proyectos tienen tarifarios, consultores nombrados, scopes basados en milestones, change orders, facturación a tiempo y materiales versus precio fijo, staffing multinivel y docenas de otros conceptos de los que un CRM genérico nunca ha oído hablar.

    Salesforce como plataforma base puede personalizarse para manejar esto, pero las personalizaciones son extensas y caras. Acaban construyendo un medio PSA dentro de Salesforce, o pagando un add-on PSA para Salesforce (FinancialForce, ahora Certinia, siendo el ejemplo canónico), y ahora están pagando dos veces: una por las licencias CRM, otra por la capa PSA encima.

    HubSpot es más amigable y barato pero aún más deal-céntrico. Su fuerza es la automatización de marketing y la gestión del funnel inbound. Su debilidad para firmas de consultoría es la misma que la de Salesforce: no entiende nativamente proyecto, tarifa, milestone, utilización.

    Existen CRM verticales para consultoría (Pipedrive personalizado, Insightly, Capsule, Copper), pero la mayoría son demasiado pequeños o demasiado genéricos. La categoría real a mirar no es CRM-para-consultoría, es PSA-con-CRM-integrado, donde el trato y el proyecto comparten una base de datos desde el primer día y no hay integración que romper.

    La respuesta honesta para la mayoría de las firmas de consultoría: necesitan un CRM en el sentido de un lugar para rastrear leads y tratos, pero no necesitan una plataforma CRM enterprise standalone. Su PSA debería cubrirlo, o deberían tener un CRM ligero (HubSpot Starter, Pipedrive) y poner la inteligencia real en el PSA.

    Profundización en PSA

    El PSA es el más estratégico de los tres sistemas, y también el menos invertido por firmas bajo cierto tamaño. La razón es psicológica. Vender se siente estratégico, así que los líderes pagan CRMs grandes. Contratar se siente estratégico, así que pagan ATSs grandes. Entregar se siente operativo, así que lo gestionan con hojas de cálculo hasta que algo se rompe.

    Lo que hace realmente un PSA: setup de proyecto desde un trato firmado, planificación de recursos y staffing de consultores nombrados, seguimiento y aprobación de tiempo, gestión de gastos, seguimiento de milestones, gestión de change orders, facturación en múltiples modelos, cuentas por cobrar, reconocimiento de ingresos (a menudo ASC 606 o NIIF 15), reporting de utilización por consultor y equipo, reporting de rentabilidad, forecast versus actuals y cada vez más funciones ligeras de CRM y ATS.

    Por qué el PSA es la columna estratégica: es el único sistema que toca cada euro de ingreso. Cada hora facturable pasa por él. Cada factura se genera desde él. Cada pregunta de margen — es rentable este proyecto, está este consultor a la tarifa correcta, dejamos dinero en los change orders — solo es respondible con datos del PSA. ATS y CRM influencian los ingresos. PSA es el ingreso.

    Los jugadores canónicos: Kantata (antes Mavenlink + Kimble), Certinia (antes FinancialForce), Projector, BigTime, Unanet, Replicon PSA, Scoro, Productive, Forecast. Por debajo, opciones ligeras como Harvest más Forecast pueden funcionar para firmas muy pequeñas pero se rompen por encima de treinta cabezas facturables.

    Lo que no hace bien un PSA: no está construido para sourcing de alto volumen (usen un ATS) ni para nurturing sofisticado (usen un CRM). Los PSA modernos absorben funciones adyacentes, pero cuanto más se alejan del núcleo project-to-cash, más delgados se vuelven.

    La guía de inversión: si son una firma de más de 20 personas sin un PSA real, están perdiendo margen que no pueden medir. Arreglar esto es casi siempre mayor ROI que mejorar el CRM o el ATS.

    Las tres zonas de solapamiento

    Aquí es donde toda firma de consultoría se atasca. Los tres sistemas no son limpiamente separables en el mundo real. Se solapan en tres zonas específicas, y cómo manejan esos solapamientos determina si su stack funciona o se pudre.

    Zona de solapamiento uno: candidato se convierte en consultor

    Una persona pasa del mundo ATS al mundo PSA en el momento en que es contratada. El registro ATS tiene notas de entrevista, fuente, sourcer, scorecard, detalles de la oferta. El registro PSA tiene habilidades, tarifa, utilización, historia de proyectos, estado facturable.

    La integración ingenua es empujar el perfil básico del candidato (nombre, email, rol) de ATS a PSA en el evento de contratación y darlo por hecho. Esto funciona para contabilidad de cabezas y poco más. La integración más rica lleva adelante habilidades, certificaciones, idiomas, banda salarial, canal de sourcing y reclutador, todos útiles para decisiones de staffing más tarde. Saber que su ingeniero senior top-performer fue encontrado a través de un canal de referral específico es el tipo de insight que justifica silenciosamente la estructura de bonus de un reclutador.

    La forma incorrecta es mantener dos registros de persona separados, uno en ATS y uno en PSA, sin link. Lo vemos constantemente. Las habilidades se actualizan en un sistema, no en el otro. El PSA muestra al consultor como experto en Python, el ATS aún lo tiene etiquetado como Java de su ronda de contratación. Las decisiones de staffing se toman con datos rancios.

    Zona de solapamiento dos: lead se convierte en proyecto

    Un trato pasa del mundo CRM al mundo PSA en el momento en que se firma. El registro CRM tiene la historia de la oportunidad, los contactos, la propuesta, la fecha de cierre. El registro PSA tiene el statement of work, el presupuesto, el equipo asignado, los milestones, los consuntivos.

    La pregunta de integración aquí es exactamente la misma que candidato-consultor. Dónde viven los datos durante la transición, quién es dueño del handoff y qué pasa. Una buena práctica es que CRM y PSA compartan contactos, cuentas y un link oportunidad-proyecto, de modo que los tratos cerrados generen automáticamente un esqueleto de proyecto en el PSA, listo para ser asignado.

    La forma incorrecta: desarrollo de negocio cierra un trato en el CRM, lanza el contrato al equipo de delivery, que reconstruye manualmente un registro de proyecto en el PSA, a menudo con convenciones de naming diferentes, a menudo recordando mal el scope. La costura entre CRM y PSA es una de las más caras en todo el stack cuando se gestiona mal.

    Zona de solapamiento tres: el contacto cliente

    Cada contacto cliente existe, potencialmente, en los tres sistemas. El buyer del cliente apareció primero como lead CRM. Después del cierre, el mismo buyer es ahora contacto en un proyecto PSA. Si la firma posteriormente coloca contractors en ese cliente, el buyer puede también ser un contacto en el ATS para fines de colocación.

    La respuesta correcta es un registro de contacto canónico, federado a los otros sistemas. La respuesta incorrecta, que también es la respuesta universal en firmas que no han diseñado esto correctamente, es tres registros, cada uno con campos rancios, cada uno con notas de alguien sobre una llamada reciente que los otros dos sistemas no conocen.

    Esta es la zona de solapamiento de la que los account managers y delivery leads se quejan más a menudo. "¿Sigue siendo nuestro buyer? ¿Cuándo lo contactamos por última vez? ¿Renovó? ¿Le estamos cobrando la tarifa correcta?" En un stack bien integrado, cada respuesta es una consulta. En un stack mal integrado, cada respuesta es un hilo de Slack.

    Tres arquetipos de integración

    Esencialmente hay tres arquitecturas viables para combinar ATS, CRM y PSA en una firma de consultoría. Elijan una conscientemente. Derivar entre ellas es lo que produce el caos en el que viven la mayoría de las firmas.

    Arquetipo uno: PSA como hub

    El PSA es el sistema de registro para personas, proyectos e ingresos. ATS y CRM existen como sistemas alimentadores, más estrechos en alcance, con puntos de handoff explícitos al PSA. Los registros de candidato se empujan de ATS a PSA en la contratación. Los registros de oportunidad se empujan de CRM a PSA en el cierre. El PSA lleva el registro de contacto canónico.

    Funciona mejor para firmas donde la entrega es el centro de gravedad. Consultoría IT, consultoría estratégica, servicios de ingeniería, agencias de diseño. ATS y CRM son herramientas tácticas para funciones específicas; el PSA es la columna operativa.

    Arquetipo dos: CRM como hub

    El CRM es el sistema de registro para cuentas, contactos y oportunidades. PSA y ATS alimentan en él. Los registros de proyecto existen en el PSA, pero la vista canónica de la cuenta vive en el CRM. El ATS puede ser reemplazado por un módulo de recruiting dentro del CRM, especialmente para firmas de staffing que corren Salesforce con Bullhorn o similar.

    Funciona mejor para firmas de colocación de alto volumen y negocios liderados por recruiting donde el valor en euros de cada engagement es lo suficientemente pequeño como para que el seguimiento detallado tipo PSA sea exagerado, pero la relación con la cuenta y la historia de colocaciones importa enormemente.

    Arquetipo tres: plataforma consolidada

    Una única plataforma cubre las funciones ATS, CRM y PSA, con un modelo de datos, una interfaz de usuario y un lugar donde buscar las cosas. El compromiso es que la plataforma consolidada será más débil en al menos una de las tres funciones que lo que sería un especialista best-of-breed, pero el coste de integración es cero porque no hay integración.

    Esto es cada vez más viable y atractivo para firmas por debajo de, digamos, 150 cabezas facturables. Los vendedores modernos de plataformas para consultoría y las plataformas operativas AI-native (donde se encuentra hice) están explícitamente construidas alrededor del modelo consolidado. El argumento es que el impuesto de costura para integrar tres best-of-breed supera los gaps de funcionalidad de una única plataforma que es simplemente muy buena en los tres.

    Consolidar versus separar: la matriz de decisión

    No hay respuesta universal a la pregunta de si consolidar. Hay una matriz de decisión.

    Tamaño de firma hasta 25 cabezas facturables: consolidar. El impuesto de costura de correr tres sistemas eclipsará cualquier ventaja de funcionalidad. Una única plataforma, o un PSA con módulos ligeros de CRM y ATS, les servirá mejor.

    Tamaño de firma de 25 a 75 cabezas facturables: depende. Si el volumen de contrataciones es bajo (bajo 30 contrataciones al año) y las ventas son de complejidad media, consolidar. Si el volumen de contrataciones es alto o las ventas son de estilo enterprise con ciclos largos y equipos complejos, consideren un especialista CRM o ATS junto a un PSA.

    Tamaño de firma de 75 a 250 cabezas facturables: depende de la complejidad. Si tienen roles especializados (un head of sales operations, un head of recruiting operations, un head of delivery operations), el best-of-breed es a menudo justificable. Si no los tienen, la consolidación aún gana.

    Tamaño de firma por encima de 250 cabezas facturables: el best-of-breed se vuelve estándar, pero con inversión seria en integración. Necesitarán una capa de data platform (a menudo una CDP o un data warehouse interno) para mantener los tres sistemas sincronizados. El impuesto de costura se vuelve manejable solo cuando industrializan las costuras.

    La complejidad de ventas es el otro eje. Una firma con ciclos de ventas de tres meses y un decisor por trato no necesita Salesforce. Una firma con ciclos de dieciocho meses, tratos de millones de euros y siete stakeholders por oportunidad probablemente sí.

    La complejidad de contratación es el tercer eje. Una firma que contrata veinte roles al año a través de uno o dos canales no necesita Greenhouse. Una firma que contrata ochenta roles al año en cinco geografías con reclutadores embebidos sí.

    El cuarto eje, cada vez más importante, es si su modelo de entrega incluye talento contracted o colocado. Las firmas de staffing, incluso las pequeñas, necesitan un ATS real porque los candidatos son el producto. Las firmas de pura entrega, incluso grandes, a menudo no.

    El cambio AI-native

    Hasta hace muy poco, el panorama de los tres acrónimos estaba asentado. Los vendedores competían dentro de cada categoría, los de integración vivían pegándolos, y las firmas pagaban el impuesto de costura como coste de hacer negocios.

    Lo que está cambiando rápido es la emergencia de plataformas operativas AI-native que abarcan las tres categorías con una interfaz chat-first. La interfaz del futuro no son tres apps, es una conversación. No inician sesión en su PSA para revisar utilización, preguntan. No abren su CRM para actualizar un trato, le dicen al asistente qué pasó en la reunión y actualiza todo: CRM, esqueleto de proyecto, staffing, forecast.

    El modelo chat-first es particularmente disruptivo en las zonas de solapamiento, porque la interfaz conversacional no le importa bajo qué acrónimo viva un dato. Preguntan "qué hay de último con la cuenta Bardelli" y el sistema junta la oportunidad abierta del CRM, el proyecto activo del PSA, y las colocaciones recientes del ATS, en una respuesta coherente.

    El arquetipo consolidado recibe un empujón importante. El argumento por best-of-breed siempre ha sido que los especialistas tienen mejores funcionalidades. El argumento por consolidación es que un sistema significa no impuesto de costura. Cuando la interfaz es conversacional y mediada por IA, la profundidad importa menos y la unidad del dato importa más. El péndulo está oscilando.

    Esto no mata al ATS, CRM o PSA como categorías. Reorganiza la decisión de compra. En lugar de preguntar qué CRM comprar, se pregunta sobre qué plataforma operativa estandarizar.

    Playbook de migración para la firma sobre-herramentada

    Si han concluido que su firma paga por sistemas redundantes, aquí está el playbook.

    Fase uno, auditoría. Listen cada sistema, conteo de licencias, coste anual y los diez flujos más importantes por sistema. Identifiquen qué flujos cruzan fronteras de sistema — esos son sus flujos de impuesto de costura. Identifiquen qué campos están duplicados.

    Fase dos, decidan la arquitectura objetivo. Ejecuten la matriz de decisión. Elijan uno de los tres arquetipos conscientemente, con socios y liderazgo operativo alineados. No es una decisión IT, es de arquitectura de negocio.

    Fase tres, elijan el sistema de registro. Para cada dominio (personas, cuentas, contactos, oportunidades, proyectos, tiempo, facturación) decidan qué sistema es dueño de la verdad. Lo demás se federa o sincroniza desde el sistema de registro.

    Fase cuatro, migren los datos cuidadosamente. No big-bang. Un dominio a la vez, empezando con el de menor riesgo (a menudo contactos) y terminando con el de mayor riesgo (proyectos activos con facturas abiertas). Corran dual-write por una ventana definida.

    Fase cinco, maten las herramientas redundantes. La parte que todos retrasan. Fijen fecha dura para cada sistema retirado, comuníquenla y aférrense. Una herramienta retirada con quince logins por semana no está retirada, es un zombie.

    Fase seis, rediseñen los flujos de costura. Incluso tras consolidar tendrán algunas costuras. El handoff CRM-PSA, la contratación ATS-PSA, la federación de contactos. Rediseñenlos explícitamente.

    La mayoría de las firmas que consolidan de tres a uno reportan payback en doce meses solo de ahorros en licencias.

    Cerrando el círculo

    ATS, CRM y PSA son tres funnels diferentes, tres unidades de dato diferentes y tres grupos de usuarios diferentes, pero todos alimentan el mismo motor de ingresos. La versión limpia: necesitan las tres funciones y posiblemente solo un sistema. La desordenada: la mayoría de las firmas usa demasiadas herramientas, paga demasiado en impuesto de costura y no obtiene la vista integrada que la tecnología ha podido entregar durante años.

    La pregunta correcta no es qué CRM es mejor. Es cuál es la arquitectura operativa correcta para su firma, a su tamaño, con su modelo de entrega, y cuánto puede correr en una sola plataforma.

    hice.ai está construido para el extremo consolidado y AI-native de este espectro. Existimos porque creemos que la mayoría de las firmas bajo 250 cabezas gastarán menos, se moverán más rápido y verán más si su CRM, PSA y ATS ligero están en una única interfaz conversacional que conoce sus proyectos, personas, clientes y las costuras entre ellos. Si esa es la arquitectura hacia la que se dirigen, deberíamos hablar.