Sistema de tickets de Microsoft: las 5 opciones reales en 2026

¿Tiene Microsoft un sistema de tickets?

No como un producto que puedas comprar con ese nombre.

Lo más cercano es Dynamics 365 Customer Service, que Microsoft posiciona con la frase "Empodera a los representantes de servicio para resolver problemas rápidamente usando agentes de IA". Es una aplicación de gestión de casos que se apoya en el stack de Dynamics 365 y Power Platform, vendida como se vende el software empresarial: la única llamada a la acción de cada nivel de pago es Contáctanos. La línea de ventas está atendida de lunes a viernes, de 6 a 15 horas, Pacific.

Ese enfoque importa más de lo que parece. Un sistema de tickets es una cola con un flujo de trabajo. Un caso de CRM es un registro asociado a un cliente, y ambos se superponen lo suficiente como para que algunos compradores busquen un sistema de tickets CRM en lugar de decidir por un camino. Pero la forma de comprar y el precio no se parecen en nada, tampoco el esfuerzo de configuración, y por eso tantos equipos de TI terminan construyendo algo propio.

Un cambio de nomenclatura más que conviene conocer antes de leer cualquier página de Microsoft en 2026. Microsoft ha renombrado a las personas. En las páginas de Customer Service, la persona que responde tickets ahora es un "representante de servicio" o "service rep", y la palabra "agente" se ha reasignado a la IA. La sección dedicada en la página del producto está literalmente encabezada como AGENTES DE SERVICIO, describiendo "servicio agéntico". Cuando un documento de Microsoft dice que un agente gestionó el caso, no significa que lo haya hecho una persona.

Las cinco rutas, una junto a otra

Aquí está la comparación honesta antes de repasar cada una. Cada precio a continuación es el precio de lista en EE. UU., por usuario al mes, pagado anualmente, extraído de las propias páginas de precios de Microsoft el 31 de julio de 2026.

Dos cosas destacan de esa tabla. Los reportes faltan en el extremo económico de cada ruta, incluido el propio producto de Microsoft de 50 $. Y la ID de ticket, lo que hace que una cola sea realmente una cola, no existe de forma adecuada hasta la ruta tres. Si la IA en la cola es la razón real por la que estás comparando rutas, mi análisis más amplio sobre IA para sistemas de tickets vale la pena leerlo junto a este.

Ruta 1: el buzón compartido

Casi toda cola de soporte de Microsoft empieza aquí, y por un tiempo funciona bien. Un buzón compartido en Outlook no cuesta nada más allá de las licencias de Microsoft 365 que ya tienes. Todos pueden verlo, y nadie tiene que aprender nada nuevo. Para los sistemas de tickets de equipos pequeños que nunca crecen más allá de un puñado de agentes, suele ser la respuesta completa.

Falla en una cosa: no hay ID de ticket, así que no hay estado. No puedes saber si un correo se está gestionando. No puedes saber si el hilo que llegó el martes es el mismo problema que el de la semana pasada. Y dos agentes terminarán respondiendo al mismo cliente con un minuto de diferencia. Todo workaround que la gente inventa (categorías de color, una carpeta de "reclamado", una convención de nombres en el asunto) es una reimplementación artesanal de un campo de estado.

El umbral es más bajo de lo que los equipos esperan. En cuanto más de dos personas trabajan en el mismo buzón, o en cuanto alguien pregunta "¿cuánto tardamos en responder?", el buzón ha dejado de ser suficiente. He escrito una comparación más completa de buzón compartido frente a sistema de tickets, además de un análisis separado sobre software de mesa de ayuda por correo para equipos que quieren mantener el correo como puerta de entrada sin perder la cola.

La conclusión: está bien como punto de partida, pero no diseñes tu operación alrededor de él. En el momento en que estás escribiendo reglas sobre quién toca qué, ya lo has superado.

Ruta 2: una lista de SharePoint con Power Automate encima

Esta es la construcción casera clásica, y sobre la que más me preguntan. Una lista de SharePoint contiene los tickets. Un flujo de Power Automate detecta elementos nuevos y dispara notificaciones, y una pestaña de Teams muestra la lista. Parece gratis porque ya pagas por las tres, aunque vale la pena revisar los precios de SharePoint frente a una mesa dedicada antes de asumir que eso se mantiene a escala.

Es una opción real. También tiene el límite más precisamente documentado de todo el stack de Microsoft, y casi nadie lo revisa antes de construir.

El muro de los 5.000 elementos

El List View Threshold de SharePoint es 5.000. En las propias palabras de Microsoft: "Las operaciones que superan este límite se bloquean". La razón es el bloqueo de filas de SQL: por encima de unas 5.000 filas bloqueadas, SQL Server considera más eficiente bloquear toda la tabla, así que Microsoft bloquea la consulta en su lugar.

Tres detalles que se pierden en la mayoría de los análisis:

• La advertencia aparece en 3.000, no en 5.000. La verás en la página de Configuración de lista mucho antes de que algo se rompa realmente.
• El número no es fijo. Microsoft lo matiza directamente: "El número real no siempre es 5.000, y puede variar según tu sitio, la cantidad de actividad en la base de datos y la configuración de tu sitio."
• No puedes subirlo. La excepción de 20.000 elementos para auditores y administradores es una función de SharePoint Server. En SharePoint Online el límite "no se puede cambiar".

La lista en sí admite 30 millones de elementos. Ese es el número que la gente cita cuando dice que SharePoint escala sin problemas. Pero una cola en realidad es una vista sobre una lista, y las vistas se rompen mucho antes que la lista. Un equipo que cierra 200 tickets al mes entra en la banda de advertencia en 15 meses, y en la banda de bloqueo en dos años.

El flujo que lo ejecuta está en el peor nivel

Power Automate clasifica cada cuenta en un perfil de rendimiento. Un equipo que construye sobre las licencias de Microsoft 365 que ya tiene cae en Low, la peor fila de cada tabla que Microsoft publica. En Low:

• 10.000 solicitudes de Power Platform por 24 horas, frente a 200.000 en Medium y 500.000 en High.
• Apply to each tope en 5.000 elementos de matriz, frente a 100.000 en cualquier otro perfil. La paginación también tope en 5.000, así que se suma al umbral de SharePoint en lugar de cancelarlo.
• El intervalo mínimo de recurrencia es de 60 segundos, así que un flujo de "ticket nuevo" que hace polling tiene un retraso de detección en el peor caso de un minuto completo antes de que se dispare nada.
• El propio conector de SharePoint limita a 600 llamadas de API por conexión cada 60 segundos.

Y el asesino silencioso: según la documentación de límites de Power Automate de Microsoft, un flujo que se mantiene por encima de los límites "durante 14 días, el sistema lo apaga". Los flujos con errores también se apagan después de 14 días. Una cola cuyo enrutamiento se detiene silenciosamente dos semanas después de un pico de volumen es un martes muy malo.

Otra trampa de licenciamiento está aquí. Una licencia normal de Microsoft 365 incluye 6.000 solicitudes de Power Platform por usuario cada 24 horas, no las 40.000 que recibe un puesto de Power Platform de pago. Cada llamada de conector cuenta como una solicitud, también cada acción HTTP, y también cada acción integrada, desde inicializar una variable hasta un simple compose. Microsoft lo dice claramente en su documentación de límites de solicitudes: "Tanto las acciones exitosas como las fallidas cuentan para estos límites. Los reintentos y las solicitudes de paginación también cuentan."

La conclusión: una buena opción para una cola interna pequeña con volumen predecible y sin plan de crecimiento. No pongas ahí una cola de cara al cliente, y pon un recordatorio en el calendario para el día en que la lista pase de 3.000 filas.

Ruta 3: Power Apps sobre Dataverse

Si la construcción en SharePoint es donde los equipos empiezan, esta es a donde escalan cuando empieza a crujir. Una Power App basada en modelos sobre Dataverse te da un modelo de datos real, relaciones reales, una ID de ticket real y una interfaz que controlas.

El problema es el licenciamiento, y Microsoft lo dice de la manera más clara posible: "Crear apps no tiene coste, pero usarlas requiere licencias de pago." El Power Apps Developer Plan gratuito cubre la construcción y las pruebas en tres entornos de desarrollador, con un tope de 750 flujos de automatización al mes. Producción es un SKU distinto.

Así que el suelo real es de 35 $ por agente al mes, con compromiso anual, antes de responder un solo ticket. Diez agentes son 350 $ al mes, o 4.200 $ al año, por software que aun así tienes que construir y mantener tú mismo.

Dos notas al pie muerden en la práctica. Primero, las asignaciones de Dataverse se agrupan a nivel de tenant en lugar de por usuario: 250 MB de base de datos y 2 GB de archivos por puesto Premium, así que diez agentes comparten un pool de 2,5 GB de base de datos. Un sistema de tickets con adjuntos agotará el pool de base de datos mucho antes que el pool de archivos, y ampliarlo cuesta 40 $ por GB al mes. Segundo, las funciones agénticas de Microsoft en Power Apps están "disponibles solo en apps basadas en modelos" - si construyes tu cola como una app de lienzo, esa capa simplemente no está disponible para ti.

El problema de delegación que nadie te advierte

Si construyes sobre SharePoint en lugar de Dataverse, la delegación de Power Apps cambia silenciosamente lo que tu app puede hacer. La que atrapa a todos: los campos de ID de SharePoint parecen números en Power Apps pero son texto por debajo, por lo que SharePoint solo "admite la operación de igualdad ('=')" para la delegación en un campo de ID. Los operadores relacionales simplemente no funcionan. "Muéstrame cada ticket con una ID superior a 4.000" no es una consulta delegable.

Not nunca delega. Catorce campos de sistema nunca delegan. UpdateIf y RemoveIf en realidad no delegan del todo, "funcionan localmente y simulan la delegación con un límite de 500/2000 registros." Cada una es sobrevivible por sí sola. Juntas, son la razón por la que las colas caseras de Microsoft tienen fama de ser rápidas el día uno y lentas el día 400.

La conclusión: la construcción correcta si tu flujo de trabajo es verdaderamente inusual y tienes a alguien técnico en plantilla. Si tus requisitos son "tickets, estados, asignación, SLAs", estás a punto de pasar meses reconstruyendo una mesa de ayuda interna que ya existe como producto empaquetado. Muchas mesas internas empaquetadas cubren exactamente esta forma de fábrica, y si el coste de licencia es la objeción, hay un sistema de tickets de código abierto que podrías alojar tú mismo. Microsoft mismo lo enmarca así, listando "Gestión de mesa de ayuda" como una de sus plantillas de Power Apps listas para usar, junto a la incorporación de empleados y el registro de activos.

Ruta 4: un agente de Copilot Studio dentro de Teams

Esta es más una capa de desviación que un sistema de tickets, y merece la pena separarla, porque muchos proyectos de "construimos un sistema de tickets en Teams" son en realidad esto.

Copilot Studio es la plataforma low-code de Microsoft para construir agentes. Absorbió Power Virtual Agents, se publica en Teams, SharePoint y Microsoft 365 Copilot, y alcanza más de 1.400 conectores. Microsoft afirma que el 90 % de las Fortune 500 lo usan. En G2 tiene una puntuación de 4,4 sobre 5 en 156 reseñas.

Para una cola de TI de preguntas repetidas ("cómo reinicio mi VPN", "dónde está la política de gastos"), un agente en Teams que lee tu SharePoint y Confluence es un uso legítimamente bueno del stack, y es exactamente el tipo de trabajo que la IA en Microsoft Teams hace bien - básicamente es un bot de soporte de TI en Teams sentado frente a tu cola. Lo que no obtienes es una cola, un estado, una asignación, ni ningún reporte sobre lo que no pudo responder.

El modelo de coste es lo que hay que entender antes de comprometerse, y merece su propia sección.

El segundo medidor: Copilot Credits

Aquí está la parte que sorprende a quienes calcularon Microsoft solo por el coste de puesto. La licencia de puesto no incluye la IA. En Customer Service Professional y Enterprise, los cuatro agentes de servicio con nombre de Microsoft - el Agente de Gestión de Casos, el Agente de Gestión de Conocimiento del Cliente, el Agente de Intención del Cliente y el Agente de Evaluación de Calidad - están todos marcados como "Requiere Copilot Credits (vendidos por separado)" en la propia comparación de planes de Microsoft, algo que vale la pena leer junto con cualquier plan de desviación de tickets que estés construyendo alrededor de esto.

Compras créditos a través de Copilot Studio a 200 $ por 25.000 Copilot Credits al mes, pagado anualmente. Eso equivale a 0,008 $ por crédito de lista, aunque Microsoft nunca imprime una tarifa por crédito en sí. Ambos planes de crédito llevan el mismo requisito previo, impreso en cada tarjeta: "Se requiere una suscripción de Azure para usar agentes."

El número que no puedes obtener es el número que necesitas. La propia nota al pie de Microsoft dice que siempre que un agente completa una acción o respuesta, "se facturará un número variable de Copilot Credits dependiendo del uso específico", según su página de precios de Power Automate. Las tarifas publicadas van desde 1 crédito para una respuesta clásica hasta 100 para una respuesta generativa premium. Suma 10 por el grounding del grafo del tenant, y un medidor separado de tokens premium encima cuando interviene un modelo de razonamiento. En ningún lugar hay una cifra de créditos por ticket resuelto, así que puedes calcular tu coste por paquete de créditos pero nunca tu coste por ticket - exactamente la brecha que un sistema de tickets con IA con precio por ticket está diseñado para cerrar.

El nivel Premium a 195 $ lista "Capacidad incluida" para esos agentes, pero la nota al pie 6 la matiza como "Capacidad base de Copilot Credit" sin cantidad publicada. El número solo vive en la guía de licenciamiento descargable.

Nada de esto es un riesgo teórico. En junio de 2026, un usuario de r/copilotstudio describió exactamente lo que hace un medidor imposible de prever cuando algo entra en bucle:

"Luego desplegué un agente de dev a prod. Eso es todo, un solo agente. Hoy revisé mi suscripción de Azure y hay una factura de ~47.000 $."

Woke up to a $47K bill after deploying ONE Copilot Studio agent, Reddit

El mecanismo apareció en las respuestas, y esa es la parte que merece la pena asimilar antes de activar nada:

"Los presupuestos para PAYG con suscripciones de Azure en Copilot solo tienen fines de alerta. No hay un cese de servicio duro para eso... tuvimos un flujo de agente disparado por correo entrante que se metió en un bucle enviándose correos a su propia bandeja de entrada por error."

NikoThe1337, en el mismo hilo, Reddit

Un presupuesto de pago por uso en Azure alerta, no detiene. Un flujo disparado por correo que puede responder a su propia bandeja de entrada es un bucle, y el medidor sigue corriendo hasta que alguien se da cuenta.

Quiero ser justo aquí. Esto no es incompetencia, es un problema real de modelado: el uso realmente varía, y una tarifa plana por ticket significa que el proveedor absorbe la varianza en lugar del cliente. La propia investigación de precios de eesel aterrizó con fuerza en el lado opuesto de eso. Probamos unidades inventadas y las retiramos, porque "crédito" obligaba a los clientes a hacer matemáticas - la reacción que escuchábamos repetidamente era alguna versión de "espera, ¿qué es un crédito?" Los tickets y las sesiones de chat son unidades en las que los responsables de soporte ya piensan. Cuando la persona que tiene que defender el presupuesto no puede prever la factura, el despliegue se estanca en compras, y ninguna calidad de modelo rescata eso.

Ruta 5: Dynamics 365 Customer Service

El producto real. Si quieres que Microsoft te venda un verdadero sistema de tickets ITSM en lugar de las piezas, esto es.

Qué es realmente un caso

Los casos de Dynamics son más rígidos que la mayoría de los tickets de mesa de ayuda. Vale la pena conocer las restricciones antes de diseñar un flujo de trabajo alrededor de ellos.

• Salen de fábrica tres estados: Activo, Resuelto, Cancelado. Activo lleva substatuses con nombre (En progreso, En espera, Esperando detalles, Investigando).
• La fusión de casos tope en 10. Por defecto puedes fusionar hasta 10 casos a la vez, y el caso fusionado pasa a Cancelado con un motivo de estado Fusionado.
• La jerarquía es exactamente de dos niveles. Un caso hijo no puede tener un caso hijo, y un caso padre no puede ser hijo de otro caso. Si tu modelo de escalado tiene tres niveles de anidamiento, no encaja.
• La migración de SLA tiene un tope. Mover más de 1.000 SLAs puede hacer fallar la verificación de premigración, y las condiciones de SLA en entidades relacionadas están limitadas a un nivel.

Ninguna de estas es un factor decisivo. Todas son del tipo de cosas que quieres descubrir en la semana uno en lugar de la semana nueve, especialmente si la gestión de SLA es la pieza que a tu equipo realmente le importa.

El precio, y la puerta que importa

El punto delicado aquí es la puerta de los reportes. A 50 $ por puesto, Professional te da gestión de casos y ningún analytics o reporte de KPI en absoluto. Tampoco integración con Microsoft Teams ni enrutamiento unificado. Todo eso empieza en el puesto Enterprise de 105 $, un salto del 110 % para desbloquear la capacidad de medir tu propia cola.

Nota también que Premium (195 $) queda muy cerca de Enterprise (105 $) más Contact Center (110 $), agrupado con un descuento de 20 $. La voz es entonces una tercera factura: la nota al pie 8 indica que "el precio de Azure Communication Services es independiente y no está incluido", así que el puesto de 195 $ compra el software del contact center y no los minutos.

Lo que Microsoft puede demostrar

Cada prueba en la página proviene del carrusel de clientes de Microsoft, así que léelas como publicadas por el proveedor y no como independientes. La más fuerte: Lenovo con una reducción del 20 % en el tiempo de gestión, Lexmark con un aumento del 23 % en la productividad del centro de llamadas, y Hype con una tasa de resolución en la primera llamada del 90 % con una reducción del 70 % en la intervención de los representantes de servicio. El propio despliegue interno de Microsoft afirma un ahorro del 50 % en el tiempo de proceso.

El posicionamiento de los analistas es real. Microsoft es un Líder en el Forrester Wave para Soluciones de Servicio al Cliente, Q1 2026, publicado el 11 de marzo de 2026, y un Líder en el Cuadrante Mágico de Gartner 2025 para el Centro de Compromiso con el Cliente de CRM, la misma categoría en la que compite ServiceNow. Vale la pena señalar dos cosas de todos modos. La propia glosa de Microsoft sobre el posicionamiento en el Wave usa la frase "visión a la par", un lenguaje inusualmente matizado para decir voluntariamente sobre uno mismo. Y el estudio de Impacto Económico Total que promociona está fechado en marzo de 2024, dos años antes de la página en la que se muestra.

La conclusión: la respuesta correcta si el soporte es de cara al cliente, el volumen es real y la empresa ya funciona sobre Dynamics. Es la respuesta equivocada para una mesa de TI interna de 12 personas, donde la licencia, el socio de implementación y el ciclo de ventas cuestan juntos más que el problema en sí. Para esa escala, un sistema de tickets interno construido sobre una mesa más ligera - Jira incluido - te llega más rápido.

Calcula lo que realmente te costaría

Los precios de lista esconden la forma de la factura, así que pon tus propios números.

Cambia el número de puestos y los interruptores para ver cómo se clasifican las cuatro rutas de Microsoft para tu equipo. El momento interesante es el punto en el que la construcción propia deja de ser la opción barata.

Ejecútalo con diez personas y la ruta de construirlo tú mismo parece una victoria fácil: 350 $ al mes frente a 500 $ de Dynamics Professional. Ejecútalo con diez personas con IA en la cola y la brecha se estrecha a 550 $ frente a 700 $, por un sistema que aun así alguien de tu equipo tiene que poseer. Esos 150 $ al mes te compran un trabajo a tiempo parcial que no habías presupuestado.

Lo que la gente realmente dice sobre operar tickets en Microsoft

Para esto leí muchos hilos de r/sysadmin y r/msp que se remontan a 2020, incluyendo bastante discusión sobre si un sistema de tickets gratuito siquiera vale la pena probar antes de comprar algo. Una frase aparece en casi todos ellos, y no es una comparación de funciones.

"A lo largo de mi carrera, la frase '¿por qué no? ya tenemos las licencias' ha sido pronunciada al menos una vez por alguien en un puesto directivo senior (o el gestor de proyecto) para todos los proyectos de mi lista de los diez peores proyectos."

BrainWaveCC, Is Microsoft Dynamics 365 a viable ticketing system candidate?, Reddit

Ese es el motor de la decisión, y vale la pena nombrarlo, porque "ya pagamos por ello" es un argumento sobre la factura, no sobre el ajuste. En el mismo hilo, alguien cuya empresa ya se había comprometido describió el resultado:

"Acabamos de empezar un proyecto usando Dynamics como reemplazo de nuestro sistema de tickets. Hasta ahora no estamos impresionados. Pero nuestro CIO siguió adelante de todos modos porque teníamos licencias para ello."

admlshake, Is Microsoft Dynamics 365 a viable ticketing system candidate?, Reddit

Los hilos de Power Apps se dividen en una línea más clara, y la división tiene que ver con quién lo mantiene, no con si funciona en absoluto. La gente que construyó lo suyo reporta que funciona bien durante años:

"Desarrollé un sistema de tickets con Power Apps y algo de Power Automate (antes Flow). Toda nuestra base de datos está en SharePoint Online. Está en producción desde noviembre de 2019, funciona genial."

Neiviv2828, Building a ticketing system using the MS Power Platorm?, Reddit

La gente que heredó uno cuenta una historia muy distinta:

"Mi predecesor lo usó para aprender la power platform. Genial... pero el problema es que hay una docena de excelentes sistemas de tickets ahí fuera, la mayoría gratuitos hasta cierto punto, y no son realmente caros de todas formas. Así que lo que nos quedó fue un desastre lleno de bugs al que le faltaba el 90 % de las funciones básicas que esperaría ver (y necesitar). Después de una semana peleando con él, terminó en la papelera."

canadian_sysadmin, O365 ticketing, Reddit

Ambas historias son ciertas al mismo tiempo, que es lo útil de leerlas una junto a la otra. Una cola casera de Power Apps es un proyecto personal que resulta ser crítico para el negocio. Funciona exactamente mientras su autor siga ahí.

El último tema es la escala, y las cifras que da la gente son más bajas de lo que imaginarías. Un sysadmin que había construido la versión de lista de SharePoint más Power Automate, con notificaciones y resaltado de SLA y todo, cerró su relato con una recomendación tajante en contra:

"No lo recomendaría. 300 empleados son suficientes para invertir en una mesa de servicio DE VERDAD."

Ayy4K, O365 ticketing, Reddit

Cómo elegir de verdad

Quitando el licenciamiento, se reduce a cuatro preguntas.

¿La cola es de cara al cliente? Si es así, salta las rutas uno y dos y ve directamente a un sistema de tickets basado en la nube apropiado. Un umbral de vista de 5.000 elementos y un retraso de sondeo de 60 segundos son problemas tolerables internamente, pero los clientes no tienen esa tolerancia.

¿Necesitas medirlo? Si alguien va a pedir el tiempo de primera respuesta, necesitas el puesto Enterprise de 105 $ o una mesa distinta. El nivel de 50 $ no puede responder esa pregunta, y construir tú mismo los reportes en Power BI añade otra licencia. Esa misma brecha de medición es la razón por la que la clasificación de tickets tiene que venir primero - no puedes reportar sobre una categoría que nunca etiquetaste.

¿Alguien es dueño de la construcción? Un sistema de tickets en Power Apps viene con un responsable adjunto, lo hayas nombrado o no. Si la respuesta es "nuestro gestor de TI lo hará junto a su trabajo", el coste real es más alto que la licencia.

¿La IA es la razón real por la que estás comprando? Esta es la que más a menudo se enfoca mal. Los equipos buscan un nuevo sistema de tickets cuando el objetivo real es que lleguen menos tickets a un humano. Replataformarse para conseguir IA es la forma más cara de comprar IA, y por eso mi guía de IA para mesas de ayuda de TI defiende añadir capas antes de cambiar en casi todos los casos. Si tu equipo ya está profundamente metido en Microsoft, el movimiento más rápido suele ser automatizar el soporte de Microsoft Teams sobre la cola que ya tienes.

Vale la pena decirlo con claridad: nada de esto convierte a Microsoft en una mala elección. Dynamics 365 es un producto serio con reconocimiento real de analistas, y la Power Platform de verdad puede construir cosas que una mesa de ayuda empaquetada no puede. El modo de fallo no es elegir Microsoft. Es elegir la ruta barata de Microsoft para un problema que necesitaba la cara, y luego encontrarse con la brecha en los 3.000 elementos de lista. Lee mi análisis más amplio sobre ticketing de TI automatizado si todavía estás decidiendo qué camino te conviene.

eesel para una cola de tickets de Microsoft

Si la desviación es la razón por la que estás leyendo esto, y no una mesa nueva, probablemente no necesites replataformarte en absoluto.

eesel es una capa de IA que se conecta a la mesa y a la documentación que ya usas - tu base de conocimiento interna incluida. Lee Microsoft Teams, SharePoint, Confluence y tus tickets existentes, redacta o envía respuestas en la herramienta en la que tu equipo ya está, y sale en vivo en minutos en lugar de en un trimestre de implementación. Dos cosas importan específicamente frente a las rutas de Microsoft anteriores. Factura por ticket, no por crédito, así que el número que llevas a finanzas es un número que puedes prever. Y cada despliegue se simula primero contra tus tickets históricos, así que ves lo que habría respondido, y con qué calidad, antes de que toque una cola en vivo. Construí eso porque he visto a un bot que suena seguro dar respuestas equivocadas en silencio, y una vez es suficiente.

La mesa de TI interna de una fintech, que funciona sobre Jira Service Management con Confluence y Slack detrás, puso a eesel como primer respondedor en su cola de mesa de ayuda. La desviación subió al 15 % de camino a un objetivo del 55 %. Su jefe de TI lo expresó así:

"Lo usamos para que sea el primer respondedor de nuestros tickets de mesa de ayuda en Jira. Básicamente actúa como lo haría un agente."

Jason Loyola, Head of IT en InDebted

Ese es el mismo tipo de trabajo que una mesa de TI sobre stack de Microsoft intenta hacer cuando pone IA en una mesa de ayuda interna en lugar de un agente de Copilot Studio, sin las matemáticas de créditos. Gratis para probar, y la configuración toma aproximadamente el mismo tiempo que leer este artículo.

Dónde te deja esto

No existe un sistema de tickets de Microsoft. Existe un CRM de 50 a 195 $ llamado Dynamics 365 Customer Service, y un kit de construcción llamado Power Platform. La decisión interesante es cuál de los dos merece realmente tu problema.

Las cinco rutas son reales, y están ordenadas. Buzón compartido hasta que dos personas colisionan. SharePoint y Power Automate hasta 3.000 elementos. Power Apps cuando el flujo de trabajo es de verdad tuyo y alguien lo posee. Copilot Studio cuando el objetivo es la desviación. Dynamics cuando el soporte es el negocio.

Lo único que no haría es comprar el puesto y asumir que la IA venía incluida. En Professional y Enterprise no lo hace. Se mide en una unidad cuyo coste por ticket Microsoft no publica, y necesita una suscripción de Azure conectada antes de funcionar en absoluto. Sea cual sea la ruta que tomes, calcula el precio de ese medidor antes de firmar, no después.