{"id":117,"date":"2026-09-04T23:11:29","date_gmt":"2026-09-05T05:11:29","guid":{"rendered":"https:\/\/zherpa.ai\/blog\/?p=117"},"modified":"2026-09-04T23:11:29","modified_gmt":"2026-09-05T05:11:29","slug":"zoho-crm-skills-agentes-ia-director-comercial","status":"publish","type":"post","link":"https:\/\/zherpa.ai\/blog\/investigacion\/zoho-crm-skills-agentes-ia-director-comercial\/","title":{"rendered":"Zoho CRM incorpora Skills: lo importante para un Director Comercial no es programar con IA"},"content":{"rendered":"

Un Director Comercial probablemente nunca abrir\u00e1 el archivo SKILL.md<\/code> que Zoho acaba de publicar. Tampoco deber\u00eda necesitar hacerlo. El anuncio habla de APIs, Functions, Client Scripts, Widgets, COQL, MCP y especificaciones OpenAPI, t\u00e9rminos que parecen pertenecer exclusivamente a desarrolladores y administradores de CRM. Sin embargo, detr\u00e1s de esa capa t\u00e9cnica est\u00e1 ocurriendo algo que s\u00ed deber\u00eda interesarle a quien dirige ventas: Zoho est\u00e1 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.<\/p>\n

El nuevo Zoho CRM Skill<\/a> est\u00e1 dise\u00f1ado para trabajar con agentes de programaci\u00f3n como Codex, Claude Code, Cursor y GitHub Copilot. Ante una necesidad expresada en lenguaje natural, el Skill puede interpretar qu\u00e9 se pretende conseguir, determinar qu\u00e9 mecanismo de Zoho CRM resulta apropiado, cargar las referencias t\u00e9cnicas correspondientes, generar una soluci\u00f3n y validarla contra par\u00e1metros, scopes, sintaxis y restricciones de la plataforma. Zoho no est\u00e1 ofreciendo simplemente otro asistente capaz de escribir c\u00f3digo: est\u00e1 estructurando conocimiento especializado para que un agente pueda participar en decisiones que antes depend\u00edan directamente de la experiencia de un desarrollador.<\/p>\n

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

De saber programar a saber c\u00f3mo debe resolverse un problema<\/h2>\n

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

El nuevo Skill intenta resolver precisamente esa distancia entre saber generar c\u00f3digo y saber desarrollar correctamente sobre una plataforma espec\u00edfica<\/strong>. Zoho documenta un proceso de cinco etapas: el agente interpreta primero el objetivo, la acci\u00f3n, la entidad y el contexto; despu\u00e9s 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\u00f3n 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\u00f3 durante su entrenamiento y obtiene conocimiento especializado en el momento en que necesita utilizarlo.<\/p>\n

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

Una documentaci\u00f3n que ya no est\u00e1 escrita solamente para personas<\/h2>\n

Hay una segunda parte del anuncio que podr\u00eda parecer menos relevante que el propio SKILL.md<\/code>, pero que quiz\u00e1 diga m\u00e1s sobre hacia d\u00f3nde se dirige el software empresarial. Zoho tambi\u00e9n reorganiz\u00f3 su repositorio OpenAPI de CRM<\/a> y explica que la nueva estructura fue dise\u00f1ada espec\u00edficamente para que LLMs y agentes puedan comprender y navegar las APIs con mayor eficiencia.<\/p>\n

Las especificaciones existentes migraron de JSON a YAML y cada recurso dispone ahora de una estructura separada que incluye su esquema, un index.md<\/code> para proporcionar contexto, documentaci\u00f3n comprimida por operaci\u00f3n y ejemplos independientes de solicitudes y respuestas. La raz\u00f3n declarada por Zoho es reducir la cantidad de informaci\u00f3n que un modelo necesita procesar para encontrar y utilizar una operaci\u00f3n concreta. En otras palabras, no estamos interpretando accidentalmente documentaci\u00f3n para humanos como documentaci\u00f3n \u00fatil para agentes; Zoho est\u00e1 dise\u00f1ando deliberadamente documentaci\u00f3n para que las m\u00e1quinas puedan consumirla mejor<\/strong>.<\/p>\n

La empresa tambi\u00e9n anunci\u00f3 que publicar\u00e1 nuevos OAS semanalmente para APIs ya liberadas y que est\u00e1 trabajando para incorporar nuevas funcionalidades de V8 primero a trav\u00e9s del repositorio p\u00fablico mientras, en paralelo, las lleva a la documentaci\u00f3n tradicional. Esto convierte al repositorio en algo m\u00e1s que una colecci\u00f3n de especificaciones t\u00e9cnicas: empieza a funcionar como una fuente actualizada de conocimiento estructurado mediante la cual un agente puede descubrir qu\u00e9 capacidades existen y c\u00f3mo utilizarlas.<\/p>\n

Durante d\u00e9cadas dise\u00f1amos las interfaces del software empresarial pensando fundamentalmente en personas. El vendedor recibi\u00f3 pantallas, formularios y vistas; el administrador obtuvo herramientas de configuraci\u00f3n; el desarrollador recibi\u00f3 APIs, SDKs y documentaci\u00f3n. Lo que estamos observando ahora es la aparici\u00f3n de otra interfaz para otro tipo de usuario: el agente de IA<\/strong>. No necesita botones ni men\u00fas como una persona. Necesita contexto estructurado, instrucciones especializadas, esquemas, permisos y herramientas que pueda descubrir e invocar.<\/p>\n

MCP completa otra parte del rompecabezas<\/h2>\n

Aqu\u00ed es donde Zoho CRM MCP<\/a> adquiere una relevancia especial. El Skill puede ayudar al agente a entender c\u00f3mo deber\u00eda resolverse una necesidad, mientras MCP puede proporcionarle herramientas para interactuar con el sistema. Cuando las herramientas MCP de Zoho CRM est\u00e1n conectadas, el Skill no tiene que limitarse a producir una explicaci\u00f3n o un comando curl<\/code>: Zoho indica que puede invocar directamente las herramientas correspondientes y que el propio Skill puede incorporarse como parte de un flujo ag\u00e9ntico.<\/p>\n

La distinci\u00f3n es importante porque ayuda a entender algo que frecuentemente se pierde cuando utilizamos \u201cIA\u201d como una categor\u00eda \u00fanica. Un modelo puede responder preguntas; un modelo con conocimiento especializado puede saber mejor c\u00f3mo resolver un problema; un modelo conectado mediante herramientas puede adem\u00e1s interactuar con sistemas externos. Cuando combinamos razonamiento, conocimiento especializado y capacidad de actuaci\u00f3n, empezamos a acercarnos a sistemas que no solamente explican c\u00f3mo deber\u00eda realizarse un trabajo, sino que pueden participar en su ejecuci\u00f3n.<\/p>\n

Para un Director Comercial, sin embargo, conocer estas diferencias t\u00e9cnicas s\u00f3lo tiene sentido si las traducimos a una consecuencia empresarial. La combinaci\u00f3n de modelos, Skills, especificaciones estructuradas y herramientas como MCP empieza a reducir la distancia que existe entre expresar una intenci\u00f3n comercial y convertirla en comportamiento dentro del CRM<\/strong>.<\/p>\n

La distancia entre una decisi\u00f3n comercial y el software que la ejecuta<\/h2>\n

Imaginemos una situaci\u00f3n cotidiana. Direcci\u00f3n Comercial detecta que ciertos leads provenientes de eventos tienen una probabilidad considerablemente mayor de convertirse cuando cumplen determinadas caracter\u00edsticas, pero observa tambi\u00e9n que algunos permanecen demasiado tiempo sin atenci\u00f3n. La decisi\u00f3n podr\u00eda expresarse simplemente as\u00ed: cuando un lead de ese segmento alcance cierto nivel de inter\u00e9s y no haya recibido seguimiento dentro del periodo definido, queremos generar una acci\u00f3n prioritaria para el ejecutivo responsable.<\/p>\n

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

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<\/strong>. Un agente especializado puede recibir la intenci\u00f3n, utilizar conocimiento oficial de Zoho para identificar el mecanismo t\u00e9cnico adecuado, construir una primera soluci\u00f3n y validarla. Si adem\u00e1s dispone de herramientas autorizadas para interactuar con CRM, puede participar tambi\u00e9n en etapas que antes exig\u00edan cambiar de herramienta o ejecutar acciones manualmente.<\/p>\n

La consecuencia estrat\u00e9gica no consiste en ahorrarse unas l\u00edneas de c\u00f3digo. Consiste en que podr\u00eda reducirse el costo marginal de convertir una decisi\u00f3n comercial en una capacidad digital. Y cuando cambia ese costo, tambi\u00e9n cambia la forma en que una organizaci\u00f3n puede experimentar, corregir procesos y adaptar su operaci\u00f3n comercial.<\/p>\n

Cuando desaparece un cuello de botella aparece otro<\/h2>\n

Durante a\u00f1os, muchas organizaciones han tenido m\u00e1s ideas para mejorar sus procesos comerciales que capacidad t\u00e9cnica disponible para implementarlas. Ventas detecta oportunidades, Operaciones las documenta, Tecnolog\u00eda prioriza, el administrador configura, el desarrollador construye y despu\u00e9s comienza el ciclo de pruebas, correcciones y mantenimiento. Esa fricci\u00f3n puede resultar desesperante, pero tambi\u00e9n explica por qu\u00e9 muchas mejoras aparentemente sencillas permanecen meses en un backlog.<\/p>\n

Los agentes de desarrollo tienen el potencial de reducir parte de esa fricci\u00f3n. Sin embargo, eliminar un cuello de botella rara vez significa que desaparezcan todos los dem\u00e1s. Con frecuencia simplemente revela cu\u00e1l era el siguiente. Si producir t\u00e9cnicamente una soluci\u00f3n se vuelve mucho m\u00e1s sencillo, el problema empieza a desplazarse desde \u201c\u00bfqui\u00e9n sabe construir esto?\u201d hacia \u201c\u00bfsabemos exactamente qu\u00e9 queremos construir, por qu\u00e9 queremos hacerlo y qu\u00e9 resultado esperamos obtener?\u201d<\/strong><\/p>\n

Ese cambio podr\u00eda aumentar, en lugar de disminuir, la importancia del criterio comercial. Un agente puede construir perfectamente una automatizaci\u00f3n que reasigne una oportunidad despu\u00e9s de siete d\u00edas sin actividad, pero que el c\u00f3digo funcione no responde por qu\u00e9 siete d\u00edas es el periodo adecuado, qu\u00e9 oportunidades deber\u00edan estar sujetas a la regla, c\u00f3mo afecta a ciclos comerciales largos, qu\u00e9 deber\u00eda ocurrir con cuentas estrat\u00e9gicas o qu\u00e9 indicador demostrar\u00eda que la reasignaci\u00f3n mejor\u00f3 realmente el resultado.<\/p>\n

Podemos llegar, por tanto, a una paradoja: la IA puede reducir radicalmente el costo de implementar una mala decisi\u00f3n sin convertirla en una buena decisi\u00f3n<\/strong>. Cuanto m\u00e1s sencillo sea construir, mayor puede ser la necesidad de decidir bien qu\u00e9 merece ser construido.<\/p>\n

No es solamente Zoho: el software empresarial est\u00e1 cambiando de arquitectura<\/h2>\n

Una forma de determinar si estamos frente a una funcionalidad particular de Zoho o ante una transformaci\u00f3n m\u00e1s amplia consiste en observar qu\u00e9 est\u00e1n haciendo otras plataformas empresariales. La comparaci\u00f3n muestra que Zoho no est\u00e1 solo.<\/p>\n

Salesforce describe actualmente una arquitectura de headless development<\/em> construida alrededor de Agent Skills, servidores MCP y plugins. Sus Skills son instrucciones reutilizables y validadas que ense\u00f1an a los agentes a realizar tareas especializadas, mientras MCP proporciona una forma estandarizada de conectarlos con sistemas externos. Esta direcci\u00f3n refuerza la idea de que el desarrollo empresarial empieza a adquirir una capa dise\u00f1ada espec\u00edficamente para agentes. Ver la explicaci\u00f3n de Salesforce Developers<\/a>.<\/p>\n

HubSpot<\/a> est\u00e1 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\u00e9ntico buscan aportar contexto de plataforma a los asistentes de programaci\u00f3n. Las implementaciones no son id\u00e9nticas y ser\u00eda incorrecto presentarlas como si lo fueran. Lo relevante es la direcci\u00f3n com\u00fan: las plataformas empresariales est\u00e1n empezando a crear superficies espec\u00edficamente dise\u00f1adas para que agentes puedan entenderlas, desarrollarlas y operarlas<\/strong>.<\/p>\n

Zoho CRM Skills no parece entonces una curiosidad tecnol\u00f3gica aislada, sino otra evidencia de una transici\u00f3n m\u00e1s profunda en la relaci\u00f3n entre personas, agentes y software empresarial.<\/p>\n

El conocimiento t\u00e9cnico no desaparece; cambia de lugar<\/h2>\n

Esta transici\u00f3n abre una pregunta inc\u00f3moda 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, \u00bfqui\u00e9n aport\u00f3 el conocimiento t\u00e9cnico? Si el agente genera una Function v\u00e1lida porque consult\u00f3 las restricciones y ejemplos mantenidos por Zoho, una parte del expertise que antes ten\u00eda que residir en la memoria y experiencia de una persona ahora est\u00e1 codificada en una fuente que la m\u00e1quina puede consultar.<\/p>\n

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

Este fen\u00f3meno puede alterar lo que entendemos por \u201cexperto\u201d. En un entorno donde las m\u00e1quinas pueden recuperar sintaxis, documentaci\u00f3n, par\u00e1metros y patrones t\u00e9cnicos bajo demanda, saber de memoria c\u00f3mo ejecutar cada operaci\u00f3n podr\u00eda perder parte de su valor relativo. Saber formular correctamente un problema, identificar restricciones, evaluar una soluci\u00f3n, reconocer sus consecuencias y decidir cu\u00e1ndo no debe implementarse puede ganar importancia.<\/p>\n

M\u00e1s capacidad para cambiar el CRM tambi\u00e9n significa m\u00e1s capacidad para da\u00f1arlo<\/h2>\n

Existe adem\u00e1s una consecuencia que merece especial atenci\u00f3n. Durante a\u00f1os, modificar sistemas empresariales ha sido relativamente costoso. Esa fricci\u00f3n resulta ineficiente, pero funciona indirectamente como un mecanismo de control: obliga a priorizar porque no todo puede desarrollarse.<\/p>\n

Si los agentes reducen sustancialmente esa fricci\u00f3n, una organizaci\u00f3n puede pasar de sufrir un backlog de cambios a enfrentar el problema contrario: una proliferaci\u00f3n de modificaciones t\u00e9cnicamente sencillas pero organizacionalmente dif\u00edciles de gobernar<\/strong>. Cada gerente puede tener una idea, cada \u00e1rea una automatizaci\u00f3n que desea incorporar, cada administrador un cambio que quiere probar y cada agente la capacidad de generar una soluci\u00f3n plausible en minutos.<\/p>\n

La capacidad de construir puede crecer mucho m\u00e1s r\u00e1pido que la capacidad de mantener coherencia. Entonces las preguntas dif\u00edciles dejan de ser \u00fanicamente c\u00f3mo programar una Function o consumir una API. Empiezan a ser qui\u00e9n puede ordenar un cambio, qu\u00e9 modificaciones requieren aprobaci\u00f3n, qu\u00e9 pruebas deben superarse, c\u00f3mo se documentan dependencias, c\u00f3mo se revierte una decisi\u00f3n, qui\u00e9n responde por sus consecuencias y qu\u00e9 evidencia demuestra que vali\u00f3 la pena conservarla.<\/p>\n

La advertencia del propio Zoho sobre revisi\u00f3n y pruebas antes de producci\u00f3n adquiere aqu\u00ed una lectura empresarial m\u00e1s amplia. La validaci\u00f3n t\u00e9cnica puede determinar que una soluci\u00f3n es sint\u00e1cticamente correcta y compatible con CRM; no puede determinar por s\u00ed sola que la decisi\u00f3n que estamos implementando sea buena para el negocio.<\/p>\n

La ventaja competitiva dif\u00edcilmente estar\u00e1 en tener acceso al Skill<\/h2>\n

El repositorio oficial zoho\/crm-skills<\/code><\/a> es p\u00fablico. MCP es un est\u00e1ndar abierto. Los principales modelos y agentes de programaci\u00f3n est\u00e1n disponibles para muchas organizaciones. Salesforce, HubSpot y otros proveedores est\u00e1n desarrollando capacidades comparables. Por eso resulta dif\u00edcil sostener que instalar un Skill o conectar un servidor MCP constituya por s\u00ed mismo una ventaja competitiva sostenible.<\/p>\n

La diferencia puede aparecer un nivel m\u00e1s arriba. Dos empresas pueden utilizar el mismo Zoho CRM, el mismo modelo y el mismo Skill. Una puede pedir \u201cautomatiza el seguimiento de leads\u201d. La otra puede definir qu\u00e9 segmento quiere mejorar, qu\u00e9 comportamiento pretende cambiar, qu\u00e9 restricciones debe respetar la automatizaci\u00f3n, cu\u00e1les son las excepciones, qu\u00e9 intervenci\u00f3n humana debe conservarse y qu\u00e9 KPI determinar\u00e1 si la modificaci\u00f3n produjo valor. La tecnolog\u00eda disponible puede ser pr\u00e1cticamente la misma; la calidad de la intenci\u00f3n, del dise\u00f1o y de la decisi\u00f3n no lo es<\/strong>.<\/p>\n

Eso deber\u00eda interesarle especialmente a Direcci\u00f3n Comercial porque desplaza la conversaci\u00f3n desde adquisici\u00f3n de tecnolog\u00eda hacia arquitectura del negocio. Si la capacidad t\u00e9cnica empieza a democratizarse, entender profundamente el proceso comercial, sus restricciones, sus clientes y su econom\u00eda puede convertirse en un diferenciador todav\u00eda mayor.<\/p>\n

Entonces, \u00bfqu\u00e9 deber\u00eda hacer hoy un Director Comercial?<\/h2>\n

No necesita instalar SKILL.md<\/code>, aprender MCP ni decidir cu\u00e1ndo utilizar COQL. Necesita reconocer que el costo y la velocidad con los que una organizaci\u00f3n puede transformar una decisi\u00f3n en comportamiento dentro de su CRM est\u00e1n empezando a cambiar. Eso justifica revisar d\u00f3nde existe hoy fricci\u00f3n entre las necesidades comerciales y la capacidad del sistema para acompa\u00f1arlas, y distinguir cu\u00e1les de esas fricciones son realmente tecnol\u00f3gicas y cu\u00e1les esconden procesos mal definidos, datos deficientes o decisiones que nadie ha querido tomar.<\/p>\n

Tambi\u00e9n conviene comenzar a definir niveles de autoridad antes de que la tecnolog\u00eda los haga urgentes. Una cosa es permitir que un agente analice el CRM y proponga una modificaci\u00f3n; 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\u00e9cnicamente podamos acercarnos a ese \u00faltimo escenario no significa que todas las organizaciones deban hacerlo ni que todas las modificaciones merezcan el mismo grado de autonom\u00eda.<\/p>\n

La pregunta tampoco deber\u00eda ser cu\u00e1ntos desarrollos puede producir un agente. La m\u00e9trica empresarial sigue estando aguas abajo: qu\u00e9 comportamiento cambi\u00f3, qu\u00e9 problema resolvi\u00f3, qu\u00e9 KPI afect\u00f3 y qu\u00e9 valor produjo. Una organizaci\u00f3n capaz de generar veinte automatizaciones en una semana no necesariamente est\u00e1 mejor que otra que implement\u00f3 dos y puede demostrar que mejoraron su operaci\u00f3n comercial.<\/p>\n

Para organizaciones que quieran profundizar en c\u00f3mo traducir necesidades comerciales a una arquitectura sostenible de CRM, puede consultarse el enfoque de Consultor\u00eda Zoho de Zherpa<\/a>.<\/p>\n

La verdadera noticia es qui\u00e9n podr\u00e1 cambiar el sistema<\/h2>\n

La lectura inmediata del anuncio de Zoho es sencilla: Zoho CRM ahora dispone de un Skill oficial para desarrollar con agentes de IA<\/strong>. Es correcto, pero insuficiente. La lectura estrat\u00e9gica es que Zoho est\u00e1 empezando a convertir conocimiento especializado de su plataforma en conocimiento estructurado que una m\u00e1quina 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\u00f3n no pertenece \u00fanicamente a un fabricante; empieza a perfilarse como una nueva capa de la arquitectura del software empresarial.<\/p>\n

Si esta tendencia contin\u00faa, escribir una Function ser\u00e1 progresivamente menos dif\u00edcil. Encontrar la operaci\u00f3n correcta de una API ser\u00e1 menos dif\u00edcil. Consultar documentaci\u00f3n ser\u00e1 menos dif\u00edcil. Incluso seleccionar el mecanismo t\u00e9cnico adecuado para resolver ciertos problemas podr\u00eda requerir menos conocimiento almacenado exclusivamente en la cabeza de una persona. Pero nada de eso elimina la necesidad de decidir qu\u00e9 queremos que ocurra, por qu\u00e9 debe ocurrir, qu\u00e9 autoridad estamos dispuestos a delegar, qu\u00e9 l\u00edmites deben permanecer, qu\u00e9 resultado esperamos obtener y qu\u00e9 evidencia aceptaremos para determinar si la decisi\u00f3n funcion\u00f3<\/strong>.<\/p>\n

Tal vez ah\u00ed est\u00e9 la implicaci\u00f3n m\u00e1s importante para un Director Comercial. La inteligencia artificial no s\u00f3lo est\u00e1 entrando al CRM para ayudar al vendedor a redactar un correo, resumir una llamada o encontrar una oportunidad. Est\u00e1 empezando a entrar en el proceso mediante el cual decidimos c\u00f3mo debe funcionar el propio sistema comercial<\/strong>. Y cuando la capacidad de cambiar el sistema se vuelve abundante, el criterio para decidir qu\u00e9 cambiar puede convertirse en el recurso verdaderamente escaso.<\/p>\n

Fuentes<\/h2>\n