Zoho CRM incorpora Skills: lo importante para un Director Comercial no es programar con IA

Un Director Comercial probablemente nunca abrirá el archivo SKILL.md que Zoho acaba de publicar. Tampoco debería necesitar hacerlo. El anuncio habla de APIs, Functions, Client Scripts, Widgets, COQL, MCP y especificaciones OpenAPI, términos que parecen pertenecer exclusivamente a desarrolladores y administradores de CRM. Sin embargo, detrás de esa capa técnica está ocurriendo algo que sí debería interesarle a quien dirige ventas: Zoho está empezando a convertir parte del conocimiento necesario para desarrollar sobre su CRM en conocimiento estructurado que un agente de inteligencia artificial puede consultar y utilizar.

El nuevo Zoho CRM Skill está diseñado para trabajar con agentes de programación como Codex, Claude Code, Cursor y GitHub Copilot. Ante una necesidad expresada en lenguaje natural, el Skill puede interpretar qué se pretende conseguir, determinar qué mecanismo de Zoho CRM resulta apropiado, cargar las referencias técnicas correspondientes, generar una solución y validarla contra parámetros, scopes, sintaxis y restricciones de la plataforma. Zoho no está ofreciendo simplemente otro asistente capaz de escribir código: está estructurando conocimiento especializado para que un agente pueda participar en decisiones que antes dependían directamente de la experiencia de un desarrollador.

La pregunta empresarial, por tanto, no es si ahora resulta más sencillo programar Zoho CRM con inteligencia artificial. La pregunta interesante es qué ocurre cuando el conocimiento necesario para modificar el sistema comercial de una empresa empieza a ser entendible y accionable por agentes de IA. Para un Director Comercial, la respuesta podría terminar afectando algo mucho más importante que el desarrollo de software: el tiempo, costo y complejidad necesarios para convertir una decisión comercial en una capacidad real dentro del CRM.

De saber programar a saber cómo debe resolverse un problema

Hasta ahora, pedirle a un LLM que genere código y utilizar un agente especializado en una plataforma podían parecer variaciones de una misma idea. No lo son necesariamente. Un modelo general puede saber escribir JavaScript, construir una petición REST o producir código Deluge, pero eso no significa que conozca cuál es el mecanismo correcto de Zoho CRM para resolver un problema determinado, qué operación de la API V8 debe utilizar, qué scopes necesita, qué restricciones existen o cuándo conviene utilizar una Function en lugar de un Client Script, un Widget o una consulta COQL.

El nuevo Skill intenta resolver precisamente esa distancia entre saber generar código y saber desarrollar correctamente sobre una plataforma específica. Zoho documenta un proceso de cinco etapas: el agente interpreta primero el objetivo, la acción, la entidad y el contexto; después selecciona el primitive apropiado entre REST API, Deluge Function, Client Script, Widget, COQL, Query o Connection; posteriormente carga las referencias pertinentes como fuente de verdad; genera la solución y, finalmente, valida el resultado contra las reglas de CRM. Es una arquitectura sencilla de describir, pero importante conceptualmente: el modelo deja de depender exclusivamente de aquello que aprendió durante su entrenamiento y obtiene conocimiento especializado en el momento en que necesita utilizarlo.

Esto tampoco convierte al agente en un desarrollador autónomo e infalible. Zoho señala expresamente que el Skill pretende acelerar el desarrollo, no sustituir la revisión de un desarrollador, y recomienda revisar y probar las soluciones generadas antes de utilizarlas en producción. La primera versión tiene, además, limitaciones concretas: aunque Zoho CRM Functions admite varios lenguajes, actualmente el Skill genera y valida Functions únicamente en Deluge, no en Java, Node.js o Python. Esa limitación es importante porque ayuda a separar lo que esta arquitectura promete de lo que efectivamente puede hacer hoy.

Una documentación que ya no está escrita solamente para personas

Hay una segunda parte del anuncio que podría parecer menos relevante que el propio SKILL.md, pero que quizá diga más sobre hacia dónde se dirige el software empresarial. Zoho también reorganizó su repositorio OpenAPI de CRM y explica que la nueva estructura fue diseñada específicamente para que LLMs y agentes puedan comprender y navegar las APIs con mayor eficiencia.

Las especificaciones existentes migraron de JSON a YAML y cada recurso dispone ahora de una estructura separada que incluye su esquema, un index.md para proporcionar contexto, documentación comprimida por operación y ejemplos independientes de solicitudes y respuestas. La razón declarada por Zoho es reducir la cantidad de información que un modelo necesita procesar para encontrar y utilizar una operación concreta. En otras palabras, no estamos interpretando accidentalmente documentación para humanos como documentación útil para agentes; Zoho está diseñando deliberadamente documentación para que las máquinas puedan consumirla mejor.

La empresa también anunció que publicará nuevos OAS semanalmente para APIs ya liberadas y que está trabajando para incorporar nuevas funcionalidades de V8 primero a través del repositorio público mientras, en paralelo, las lleva a la documentación tradicional. Esto convierte al repositorio en algo más que una colección de especificaciones técnicas: empieza a funcionar como una fuente actualizada de conocimiento estructurado mediante la cual un agente puede descubrir qué capacidades existen y cómo utilizarlas.

Durante décadas diseñamos las interfaces del software empresarial pensando fundamentalmente en personas. El vendedor recibió pantallas, formularios y vistas; el administrador obtuvo herramientas de configuración; el desarrollador recibió APIs, SDKs y documentación. Lo que estamos observando ahora es la aparición de otra interfaz para otro tipo de usuario: el agente de IA. No necesita botones ni menús como una persona. Necesita contexto estructurado, instrucciones especializadas, esquemas, permisos y herramientas que pueda descubrir e invocar.

MCP completa otra parte del rompecabezas

Aquí es donde Zoho CRM MCP adquiere una relevancia especial. El Skill puede ayudar al agente a entender cómo debería resolverse una necesidad, mientras MCP puede proporcionarle herramientas para interactuar con el sistema. Cuando las herramientas MCP de Zoho CRM están conectadas, el Skill no tiene que limitarse a producir una explicación o un comando curl: Zoho indica que puede invocar directamente las herramientas correspondientes y que el propio Skill puede incorporarse como parte de un flujo agéntico.

La distinción es importante porque ayuda a entender algo que frecuentemente se pierde cuando utilizamos “IA” como una categoría única. Un modelo puede responder preguntas; un modelo con conocimiento especializado puede saber mejor cómo resolver un problema; un modelo conectado mediante herramientas puede además interactuar con sistemas externos. Cuando combinamos razonamiento, conocimiento especializado y capacidad de actuación, empezamos a acercarnos a sistemas que no solamente explican cómo debería realizarse un trabajo, sino que pueden participar en su ejecución.

Para un Director Comercial, sin embargo, conocer estas diferencias técnicas sólo tiene sentido si las traducimos a una consecuencia empresarial. La combinación de modelos, Skills, especificaciones estructuradas y herramientas como MCP empieza a reducir la distancia que existe entre expresar una intención comercial y convertirla en comportamiento dentro del CRM.

La distancia entre una decisión comercial y el software que la ejecuta

Imaginemos una situación cotidiana. Dirección Comercial detecta que ciertos leads provenientes de eventos tienen una probabilidad considerablemente mayor de convertirse cuando cumplen determinadas características, pero observa también que algunos permanecen demasiado tiempo sin atención. La decisión podría expresarse simplemente así: cuando un lead de ese segmento alcance cierto nivel de interés y no haya recibido seguimiento dentro del periodo definido, queremos generar una acción prioritaria para el ejecutivo responsable.

Esa frase no dice nada sobre REST API, Deluge, Client Script, COQL o Connections. Es una intención de negocio. Tradicionalmente, para convertirla en comportamiento del CRM debe atravesar varias capas de traducción: alguien analiza el requerimiento, alguien conoce suficientemente bien Zoho para determinar cómo implementarlo, se selecciona el mecanismo técnico, se construye la solución, se prueba y finalmente se despliega.

El nuevo enfoque no elimina esa cadena ni justifica prescindir de quienes entienden la plataforma. Lo que empieza a hacer es comprimir algunas de sus etapas. Un agente especializado puede recibir la intención, utilizar conocimiento oficial de Zoho para identificar el mecanismo técnico adecuado, construir una primera solución y validarla. Si además dispone de herramientas autorizadas para interactuar con CRM, puede participar también en etapas que antes exigían cambiar de herramienta o ejecutar acciones manualmente.

La consecuencia estratégica no consiste en ahorrarse unas líneas de código. Consiste en que podría reducirse el costo marginal de convertir una decisión comercial en una capacidad digital. Y cuando cambia ese costo, también cambia la forma en que una organización puede experimentar, corregir procesos y adaptar su operación comercial.

Cuando desaparece un cuello de botella aparece otro

Durante años, muchas organizaciones han tenido más ideas para mejorar sus procesos comerciales que capacidad técnica disponible para implementarlas. Ventas detecta oportunidades, Operaciones las documenta, Tecnología prioriza, el administrador configura, el desarrollador construye y después comienza el ciclo de pruebas, correcciones y mantenimiento. Esa fricción puede resultar desesperante, pero también explica por qué muchas mejoras aparentemente sencillas permanecen meses en un backlog.

Los agentes de desarrollo tienen el potencial de reducir parte de esa fricción. Sin embargo, eliminar un cuello de botella rara vez significa que desaparezcan todos los demás. Con frecuencia simplemente revela cuál era el siguiente. Si producir técnicamente una solución se vuelve mucho más sencillo, el problema empieza a desplazarse desde “¿quién sabe construir esto?” hacia “¿sabemos exactamente qué queremos construir, por qué queremos hacerlo y qué resultado esperamos obtener?”

Ese cambio podría aumentar, en lugar de disminuir, la importancia del criterio comercial. Un agente puede construir perfectamente una automatización que reasigne una oportunidad después de siete días sin actividad, pero que el código funcione no responde por qué siete días es el periodo adecuado, qué oportunidades deberían estar sujetas a la regla, cómo afecta a ciclos comerciales largos, qué debería ocurrir con cuentas estratégicas o qué indicador demostraría que la reasignación mejoró realmente el resultado.

Podemos llegar, por tanto, a una paradoja: la IA puede reducir radicalmente el costo de implementar una mala decisión sin convertirla en una buena decisión. Cuanto más sencillo sea construir, mayor puede ser la necesidad de decidir bien qué merece ser construido.

No es solamente Zoho: el software empresarial está cambiando de arquitectura

Una forma de determinar si estamos frente a una funcionalidad particular de Zoho o ante una transformación más amplia consiste en observar qué están haciendo otras plataformas empresariales. La comparación muestra que Zoho no está solo.

Salesforce describe actualmente una arquitectura de headless development construida alrededor de Agent Skills, servidores MCP y plugins. Sus Skills son instrucciones reutilizables y validadas que enseñan a los agentes a realizar tareas especializadas, mientras MCP proporciona una forma estandarizada de conectarlos con sistemas externos. Esta dirección refuerza la idea de que el desarrollo empresarial empieza a adquirir una capa diseñada específicamente para agentes. Ver la explicación de Salesforce Developers.

HubSpot está recorriendo un camino relacionado, aunque con una arquitectura propia. Su servidor MCP remoto proporciona a herramientas y agentes compatibles acceso autorizado sobre datos de CRM, mientras sus herramientas para desarrollo agéntico buscan aportar contexto de plataforma a los asistentes de programación. Las implementaciones no son idénticas y sería incorrecto presentarlas como si lo fueran. Lo relevante es la dirección común: las plataformas empresariales están empezando a crear superficies específicamente diseñadas para que agentes puedan entenderlas, desarrollarlas y operarlas.

Zoho CRM Skills no parece entonces una curiosidad tecnológica aislada, sino otra evidencia de una transición más profunda en la relación entre personas, agentes y software empresarial.

El conocimiento técnico no desaparece; cambia de lugar

Esta transición abre una pregunta incómoda sobre expertise. Si un administrador describe correctamente una necesidad y un agente selecciona COQL en lugar de REST API porque el Skill contiene el conocimiento necesario para distinguir ambas opciones, ¿quién aportó el conocimiento técnico? Si el agente genera una Function válida porque consultó las restricciones y ejemplos mantenidos por Zoho, una parte del expertise que antes tenía que residir en la memoria y experiencia de una persona ahora está codificada en una fuente que la máquina puede consultar.

Eso no significa que el expertise desaparezca. Significa que parte del conocimiento puede desplazarse desde la persona hacia la arquitectura. El desarrollador puede necesitar memorizar menos particularidades de la plataforma y dedicar más atención a arquitectura, excepciones, pruebas, seguridad, integración y consecuencias. De manera similar, el responsable de negocio puede tener más capacidad para expresar directamente una necesidad, pero también mayor responsabilidad de formularla correctamente.

Este fenómeno puede alterar lo que entendemos por “experto”. En un entorno donde las máquinas pueden recuperar sintaxis, documentación, parámetros y patrones técnicos bajo demanda, saber de memoria cómo ejecutar cada operación podría perder parte de su valor relativo. Saber formular correctamente un problema, identificar restricciones, evaluar una solución, reconocer sus consecuencias y decidir cuándo no debe implementarse puede ganar importancia.

Más capacidad para cambiar el CRM también significa más capacidad para dañarlo

Existe además una consecuencia que merece especial atención. Durante años, modificar sistemas empresariales ha sido relativamente costoso. Esa fricción resulta ineficiente, pero funciona indirectamente como un mecanismo de control: obliga a priorizar porque no todo puede desarrollarse.

Si los agentes reducen sustancialmente esa fricción, una organización puede pasar de sufrir un backlog de cambios a enfrentar el problema contrario: una proliferación de modificaciones técnicamente sencillas pero organizacionalmente difíciles de gobernar. Cada gerente puede tener una idea, cada área una automatización que desea incorporar, cada administrador un cambio que quiere probar y cada agente la capacidad de generar una solución plausible en minutos.

La capacidad de construir puede crecer mucho más rápido que la capacidad de mantener coherencia. Entonces las preguntas difíciles dejan de ser únicamente cómo programar una Function o consumir una API. Empiezan a ser quién puede ordenar un cambio, qué modificaciones requieren aprobación, qué pruebas deben superarse, cómo se documentan dependencias, cómo se revierte una decisión, quién responde por sus consecuencias y qué evidencia demuestra que valió la pena conservarla.

La advertencia del propio Zoho sobre revisión y pruebas antes de producción adquiere aquí una lectura empresarial más amplia. La validación técnica puede determinar que una solución es sintácticamente correcta y compatible con CRM; no puede determinar por sí sola que la decisión que estamos implementando sea buena para el negocio.

La ventaja competitiva difícilmente estará en tener acceso al Skill

El repositorio oficial zoho/crm-skills es público. MCP es un estándar abierto. Los principales modelos y agentes de programación están disponibles para muchas organizaciones. Salesforce, HubSpot y otros proveedores están desarrollando capacidades comparables. Por eso resulta difícil sostener que instalar un Skill o conectar un servidor MCP constituya por sí mismo una ventaja competitiva sostenible.

La diferencia puede aparecer un nivel más arriba. Dos empresas pueden utilizar el mismo Zoho CRM, el mismo modelo y el mismo Skill. Una puede pedir “automatiza el seguimiento de leads”. La otra puede definir qué segmento quiere mejorar, qué comportamiento pretende cambiar, qué restricciones debe respetar la automatización, cuáles son las excepciones, qué intervención humana debe conservarse y qué KPI determinará si la modificación produjo valor. La tecnología disponible puede ser prácticamente la misma; la calidad de la intención, del diseño y de la decisión no lo es.

Eso debería interesarle especialmente a Dirección Comercial porque desplaza la conversación desde adquisición de tecnología hacia arquitectura del negocio. Si la capacidad técnica empieza a democratizarse, entender profundamente el proceso comercial, sus restricciones, sus clientes y su economía puede convertirse en un diferenciador todavía mayor.

Entonces, ¿qué debería hacer hoy un Director Comercial?

No necesita instalar SKILL.md, aprender MCP ni decidir cuándo utilizar COQL. Necesita reconocer que el costo y la velocidad con los que una organización puede transformar una decisión en comportamiento dentro de su CRM están empezando a cambiar. Eso justifica revisar dónde existe hoy fricción entre las necesidades comerciales y la capacidad del sistema para acompañarlas, y distinguir cuáles de esas fricciones son realmente tecnológicas y cuáles esconden procesos mal definidos, datos deficientes o decisiones que nadie ha querido tomar.

También conviene comenzar a definir niveles de autoridad antes de que la tecnología los haga urgentes. Una cosa es permitir que un agente analice el CRM y proponga una modificación; otra que genere el artefacto; otra que lo prepare en un ambiente de pruebas; y otra muy distinta que pueda modificar un sistema productivo. El hecho de que técnicamente podamos acercarnos a ese último escenario no significa que todas las organizaciones deban hacerlo ni que todas las modificaciones merezcan el mismo grado de autonomía.

La pregunta tampoco debería ser cuántos desarrollos puede producir un agente. La métrica empresarial sigue estando aguas abajo: qué comportamiento cambió, qué problema resolvió, qué KPI afectó y qué valor produjo. Una organización capaz de generar veinte automatizaciones en una semana no necesariamente está mejor que otra que implementó dos y puede demostrar que mejoraron su operación comercial.

Para organizaciones que quieran profundizar en cómo traducir necesidades comerciales a una arquitectura sostenible de CRM, puede consultarse el enfoque de Consultoría Zoho de Zherpa.

La verdadera noticia es quién podrá cambiar el sistema

La lectura inmediata del anuncio de Zoho es sencilla: Zoho CRM ahora dispone de un Skill oficial para desarrollar con agentes de IA. Es correcto, pero insuficiente. La lectura estratégica es que Zoho está empezando a convertir conocimiento especializado de su plataforma en conocimiento estructurado que una máquina puede descubrir, interpretar y utilizar. Al mismo tiempo, herramientas como MCP empiezan a proporcionar a esos agentes mecanismos estandarizados para interactuar con los sistemas sobre los que razonan. Salesforce y HubSpot muestran que esta dirección no pertenece únicamente a un fabricante; empieza a perfilarse como una nueva capa de la arquitectura del software empresarial.

Si esta tendencia continúa, escribir una Function será progresivamente menos difícil. Encontrar la operación correcta de una API será menos difícil. Consultar documentación será menos difícil. Incluso seleccionar el mecanismo técnico adecuado para resolver ciertos problemas podría requerir menos conocimiento almacenado exclusivamente en la cabeza de una persona. Pero nada de eso elimina la necesidad de decidir qué queremos que ocurra, por qué debe ocurrir, qué autoridad estamos dispuestos a delegar, qué límites deben permanecer, qué resultado esperamos obtener y qué evidencia aceptaremos para determinar si la decisión funcionó.

Tal vez ahí esté la implicación más importante para un Director Comercial. La inteligencia artificial no sólo está entrando al CRM para ayudar al vendedor a redactar un correo, resumir una llamada o encontrar una oportunidad. Está empezando a entrar en el proceso mediante el cual decidimos cómo debe funcionar el propio sistema comercial. Y cuando la capacidad de cambiar el sistema se vuelve abundante, el criterio para decidir qué cambiar puede convertirse en el recurso verdaderamente escaso.