Introducción
Elegir un proveedor FSM es una de las decisiones de plataforma de mayor riesgo que toma un líder de operaciones. La elección equivocada bloquea años de fricción operativa; la correcta capitaliza — mejores decisiones de despacho, mejor adopción del técnico, mejor experiencia del cliente — trimestre tras trimestre. El proceso de compra debería reflejar esa asimetría.
Este checklist está escrito para VP de Operaciones, COOs y líderes de TI ejecutando una evaluación FSM empresarial. Cubre las dimensiones que importan — arquitectura, despliegue, precios, IA, UX móvil, modelo de fuerza de trabajo, integraciones, cobertura regional, carga de personalización y expectativas de referencia — y explica qué preguntar, qué respuestas buscar y qué respuestas deberían hacerte irte.
Paso 0: define tu perfil de complejidad operativa
Antes de evaluar cualquier proveedor, escribe tu perfil de complejidad operativa en una sola página. Las dimensiones que importan: cantidad de técnicos y trayectoria de crecimiento, mezcla empleado vs contratado, número de países, regímenes de facturación electrónica en alcance, sistemas de registro integrados (CRM, ERP, EAM, ITSM), canales hacia el cliente (WhatsApp, web, call center), multiplicador de carga de día pico, exposición regulatoria de SLA. Este documento se vuelve la base para cada conversación con cada vendor.
Los equipos de operaciones que saltan este paso terminan dejando que las demos del vendor definan los requerimientos, lo cual es precisamente la dirección de encaje equivocada. El perfil de complejidad cambia la conversación de "qué vendes" a "cómo manejas la forma de nuestro problema". Los vendors que pueden responder bien la segunda pregunta están operando a un nivel diferente que los vendors que solo pueden responder la primera.
Arquitectura: hecho a propósito vs extensión de plataforma
La primera pregunta arquitectónica es si el producto FSM está hecho a propósito para field service o si es una extensión de una plataforma empresarial más grande (Salesforce, ServiceNow, IFS, Microsoft Dynamics). Ambos arquetipos pueden ser la respuesta correcta, pero encajan en organizaciones diferentes. Las plataformas FSM hechas a propósito tienden a tener un modelo de datos de field service más profundo, plazos de despliegue más rápidos y menor carga de personalización; el FSM de extensión de plataforma tiende a ser la elección correcta cuando la organización compradora ya está profundamente estandarizada en la plataforma padre y las operaciones de campo son una extensión de un workflow más amplio.
El patrón que falla en producción es comprar FSM de extensión de plataforma cuando el comprador no está realmente estandarizado en la plataforma padre, con el supuesto de que lo estará en el futuro. La superficie de despliegue, la carga de personalización y la economía continua de licenciamiento del FSM de extensión de plataforma tienen sentido cuando la inversión en plataforma ya se amortizó a lo largo de otros workflows; no tienen sentido como una inversión de field service standalone.
Plazo de despliegue y dependencia de SI
Pídele a cada vendor un plazo realista de despliegue en cuentas en producción que se parezcan a la tuya. Cuidado con las respuestas que citan un solo número ("dieciséis semanas") sin contexto; la respuesta correcta es una vista por fases (piloto a producción en X semanas, rollout completo de un país en Y semanas, expansión multipaís a Z semanas por país) con los supuestos declarados. Luego pregunta por el perfil del partner SI que recomiendan: cuánto del despliegue es el vendor mismo versus un partner integrador de sistemas y cuál es típicamente el ratio de costo de SI contra el valor anual de licencia.
Las respuestas saludables en 2026 se ven así: piloto a producción en cuatro a doce semanas para un despliegue de un solo país, con el equipo de implementación del propio vendor ejecutando el proyecto; partners SI opcionales para organizaciones que prefieren ese modelo de entrega; ratio de costo de SI a o por debajo del costo de licencia en lugar de dos a cinco veces. Si el vendor no puede entregar sin un SI, o si el costo del SI domina la economía del proyecto, eso es información estructural sobre cómo se comporta la plataforma en producción — no solo un argumento de venta.
Modelo de precios y economía unitaria
El modelo de precios merece más atención de la que los compradores usualmente le dan porque define la economía para los próximos cinco años, no solo el año de contrato. Los dos patrones dominantes son por-usuario (licencia por asiento, por técnico, por despachador) y por-pedido (licencia atada al throughput operativo — órdenes de trabajo completadas, visitas completadas o similar). El precio por-usuario es familiar pero acopla costo a headcount: a medida que la fuerza de trabajo de campo crece, los costos de licencia crecen linealmente con ella, incluyendo para poblaciones de contratistas que la plataforma ahora soporta. El precio por-pedido desacopla el costo del headcount y lo ata al output operativo, que es contra lo que los ejecutivos realmente presupuestan.
La pregunta correcta sobre precios no es "cuál es más barato" sino "cuál sigue la forma de nuestra operación". Las operaciones que crecen agregando técnicos y contratistas más rápido de lo que crecen en volumen de transacciones favorecen el precio por-pedido. Las operaciones cuyo conteo de técnicos es estable y cuyo crecimiento está en volumen de transacciones favorecen el precio por-usuario. Construye un modelo TCO de cinco años con supuestos de crecimiento realistas y compara los dos modelos contra la misma forma.
Capacidades de IA e integración operativa
La capacidad de IA merece un lente de evaluación específico: dónde en el workflow vive la IA y qué métrica operativa mueve. Los vendors con despacho con IA embebido (corriendo continuamente dentro de la pantalla de despacho, integrado con el modelo de orden de trabajo) operan cualitativamente diferente de los vendors que empaquetan IA como un producto separado de analítica o una superficie copilot. La pregunta de evaluación más útil es: "Muéstrame qué decisión tomó la IA, en qué trabajo y cuál fue el resultado operativo".
Pide referencias en producción con la capacidad de IA habilitada a escala significativa, pide las mejoras de métricas específicas (primera intervención exitosa, utilización del técnico, llegada a tiempo, CSAT) antes y después y trata las afirmaciones genéricas de adopción con cautela. La IA que vive al lado del workflow rara vez paga; la IA que vive dentro del workflow consistentemente sí. La misma cautela aplica al precio de IA: cuidado con modelos por consumo (por mensaje manejado por IA, por despacho sugerido por IA) donde la economía unitaria puede desviarse desfavorablemente con la escala.
UX móvil y adopción del técnico
La adopción del técnico es el fundamento de todos los demás resultados operativos — la mala UX móvil fuga productividad por cada visita. Evalúa la app móvil con la prueba más dura disponible: pásale el dispositivo a un técnico (tuyo o de ellos) por un turno completo y observa qué pasa. Específicamente, busca usabilidad con una sola mano, comportamiento offline-first, tiempos de finalización para los flujos rutinarios (iniciar un trabajo, capturar una foto, cerrar un trabajo, pedir repuestos) y si la app elimina tipeo en lugar de pedirlo.
Las dos preguntas que separan el FSM móvil fuerte del débil son: cuánto tarda un técnico nuevo en ser productivo sin capacitación formal y cómo está construido realmente el modo offline (¿es verdaderamente offline-first, con resolución de conflictos, o solo cacheo optimista que se rompe en la reconexión?). Los vendors que pueden demostrar horas-a-productividad para técnicos nuevos y un modelo offline creíble están operando a un nivel diferente que los vendors que necesitan programar programas de capacitación formal.
Modelo de fuerza de trabajo: empleado, contratado, mixto
El soporte de una plataforma para fuerzas de trabajo mixtas empleado-contratado es uno de los separadores más limpios en la evaluación FSM empresarial de 2026. La plataforma debería modelar contratistas y empleados en la misma superficie de despacho con capas de política diferentes por detrás (cobertura geográfica, habilidades contratadas, disponibilidad contratada, economía precio-por-trabajo, requisitos de documento y certificación). El patrón equivocado son dos superficies de despacho separadas para empleados y contratistas, lo cual crea una carga de reconciliación y una brecha de productividad.
Pregunta específicamente sobre los workflows de onboarding de contratistas: KYC, certificación, verificación de seguro, asignación de cobertura geográfica, activación de la app y período de calibración. Las plataformas que codifican estos como workflows nativos manejan la escala bien; las plataformas que las dejan a checklists manuales de operaciones chocan contra una pared por encima de conteos modestos de contratistas. Para operaciones LATAM, pregunta por las estructuras locales de clasificación laboral (CLT vs PJ en Brasil, empleado vs honorarios en México, estructuras equivalentes en otros lugares) y si la plataforma las modela nativamente.
Integraciones con CRM, ERP y mensajería
Las plataformas FSM no viven solas. Se integran con el CRM (registros de cliente, casos), el ERP (datos financieros y de inventario), a veces el EAM (registros de activos) y el stack de mensajería hacia el cliente (WhatsApp, SMS, email). Evalúa la historia de integración específicamente: qué conectores preconstruidos existen, cuál es la superficie de API (REST-first con webhooks documentados es la expectativa moderna), cuál es el plazo típico de integración y cómo maneja el vendor la inevitable deriva de esquema a medida que los sistemas integrados evolucionan.
Los conectores preconstruidos a las principales plataformas CRM y ERP (Salesforce, SAP, Oracle, Microsoft Dynamics, más ERPs regionales para rollouts LATAM) reducen significativamente el riesgo de integración. La respuesta equivocada es "construiremos una integración a medida como parte de la implementación" — esa es una bandera de dependencia continua de SI. La respuesta correcta es un conector documentado con el alcance y plazo típico del equipo de integración, más una superficie API clara para los casos que el conector no cubre.
Cobertura regional y soporte de idioma
La cobertura regional importa en proporción a dónde realmente opera la operación. Para operaciones LATAM, las preguntas son concretas: soporte nativo de español y portugués (no traducido a máquina), manejo de dialectos regionales, integraciones locales de pagos y KYC, facturación electrónica por país, residencia de datos del cliente y horarios de operación del equipo de soporte del vendor que superpongan con las horas laborales de la operación. Los vendors con un track record serio en LATAM pueden demostrar referencias en producción a lo largo de múltiples países; los vendors que tratan a LATAM como un mercado de expansión a menudo no pueden.
La misma lógica aplica a otras regiones en proporción a la huella operativa. Una operación solo norteamericana no necesita profundidad en facturación electrónica brasileña; una operación multirregional sí. El encuadre correcto es ponderar la cobertura regional por la distribución geográfica de la operación, no por lo que el vendor quiere mostrar en la demo.
Economía post-despliegue y carga de personalización
El costo de FSM no termina en el go-live. Pídele a cada vendor la carga típica de personalización continua — cuántos persona-días por trimestre se requieren típicamente para mantener la plataforma alineada con los cambios operativos, cuál es el costo típico de un cambio de configuración no trivial, cuál es la cadencia de upgrade y con qué frecuencia un upgrade rompe configuraciones a medida. Las plataformas con cargas de configuración low-code tienen economía significativamente diferente que las plataformas que requieren tiempo de developer en la plataforma padre para cambios continuos.
Estrechamente relacionado: pregunta sobre el modelo de soporte, el patrón de contacto nombrado, los compromisos de tiempo de respuesta y el camino de escalamiento para incidentes que impactan producción. Los equipos de operaciones que corren sobre FSM empresarial esperan soporte grado-producción; los vendors que tratan el soporte como un add-on post-venta en lugar de parte del modelo operativo están dejando el trabajo al cliente.
Chequeo de referencias y expectativas de prueba de despliegue
Las referencias son la entrada de due diligence de etapa tardía más útil. Pide al menos tres referencias con perfiles operativos similares al tuyo, en las características de IA que planeas desplegar, en las geografías donde planeas operar, con el modelo de fuerza de trabajo que planeas usar. En las llamadas de referencia, haz las preguntas a nivel operador: cómo se vio realmente el despliegue (plazos, sorpresas, costos de SI), qué métricas realmente movieron (específicos, no platitudes), qué harían diferente si estuvieran re-licitando.
Más allá de las referencias, pídele al vendor que demuestre la plataforma contra tus propios datos operativos — un conjunto redactado de órdenes de trabajo, un escenario de despacho representativo, un flujo real de plantilla de mensajería al cliente. Los vendors que pueden configurar su plataforma para tus datos en una sesión de trabajo te están mostrando algo sobre qué tan fácil es realmente configurar la plataforma. Los vendors que requieren un proyecto de prueba de concepto de seis semanas para hacer la misma demostración también te están mostrando algo, aunque menos halagador.