Hay una conversación que se repite en casi todas las empresas que llevan dos o tres años con Salesforce. Alguien de negocio pide un reporte nuevo y la respuesta es: «eso hay que pedirlo a sistemas y están saturados». O peor: «ese reporte ya existe, pero nadie confía en él».
No es un problema de soporte. Cuando algo se rompe, alguien lo arregla. El problema es lo otro: todo lo que nunca se rompe del todo pero deja de responder a lo que el negocio necesita.
La cola que no avanza
Un Salesforce sin mantenimiento no falla de golpe. Se degrada.
Casi siempre empieza por una petición pequeña. Un campo nuevo en el formulario de altas. Un aviso cuando una oportunidad lleva treinta días parada. Nada complicado, y sin embargo nadie lo toma: el equipo técnico está resolviendo lo urgente y eso no lo es.
Así se forma una cola. Diez, veinte peticiones que nunca fueron prioridad y nunca llegaron a ejecutarse. Y mientras la cola crece, el negocio no espera: alguien monta la hoja de cálculo que sí hace lo que necesita. Otro replica los datos en su propia herramienta. Sin que nadie lo decida, Salesforce deja de ser el sitio donde se trabaja.
Esa cola es el problema. No las incidencias.
A eso se suma que la plataforma se mueve sola. Salesforce publica tres releases al año, y cada uno trae capacidades que podrían resolver algo que tu equipo sigue haciendo a mano. Si nadie los revisa, no es que algo se rompa: es que pagas por funciones que no usas.
Mientras tanto, la operación deja su rastro. Un campo que se creó para un proyecto que se canceló. Tres reportes que miden lo mismo con criterios distintos, y nadie sabe cuál es el bueno. Un flujo que se duplicó porque era más rápido copiarlo que entender el original. Usuarios que se fueron de la empresa y siguen con licencia activa.
Por separado, casi nada de esto llega a generar un ticket. Todo junto explica por qué, dieciocho meses después, el equipo comercial ha vuelto a la hoja de cálculo.
La señal de alarma no es que Salesforce falle. Es que la gente empiece a trabajar por fuera.
Por qué el modelo reactivo se queda corto
El esquema habitual —un proveedor al que se llama cuando hay una incidencia— no es malo. Es incompleto, por una razón estructural: solo se activa cuando ya hay daño.
Nadie abre un ticket para pedir que le ayuden a decidir si una iniciativa es viable. Nadie llama a su proveedor para preguntar si lo que se construyó hace dos años sigue teniendo sentido, o si conviene rehacerlo antes de montarle algo encima. Esas tareas no tienen quien las pida, así que no se hacen.
El resultado es que se paga por corregir lo que se podría haber evitado. Y hay un costo que no aparece en ninguna factura: el de todo lo que la plataforma podría estar haciendo y no hace, porque nadie tiene el encargo de mirar hacia adelante.
Las tres salidas, con sus contras
Hay tres formas de resolver esto, y ninguna es la mejor para todos.
Contratar un administrador interno
Funciona cuando tu operación es lo bastante grande y estable como para justificar una persona a tiempo completo, y necesitas a alguien que conozca el negocio desde dentro y esté en las reuniones.
El contra honesto: es un costo fijo y es una persona con un perfil. Un buen administrador no es necesariamente un buen desarrollador de Apex, ni un arquitecto de integraciones, ni un especialista en Field Service. Cuando aparece algo fuera de su ámbito, hay que buscar ayuda igualmente. Y hay que prever las ausencias: vacaciones, incapacidades, capacitación.
Y está el riesgo de concentración. Cuando ese conocimiento queda en una sola persona —por qué ese flujo está configurado así, qué se probó y no funcionó, qué depende de qué—, su salida puede convertirse en un riesgo operativo importante. Reemplazarla no es solo reclutar: son meses hasta que alguien nuevo es productivo.
Freelance a demanda
Funciona cuando las necesidades son puntuales y espaciadas, y tienes a alguien interno capaz de dirigir el trabajo.
El contra honesto: la disponibilidad depende de la agenda de esa persona, que trabaja para varios clientes a la vez. Cuando la incidencia coincide con un pico de otro proyecto, la respuesta puede tardar. Y como cada encargo se contrata por separado, el foco natural está en cerrar la tarea pedida más que en cuidar la coherencia del conjunto —salvo que exista una relación continua, que es justo lo que este modelo no garantiza.
Servicio gestionado
Funciona cuando necesitas varios perfiles pero ninguno a tiempo completo, y quieres que alguien se responsabilice del estado de la plataforma, no solo de las tareas que le pidas.
El contra honesto: hay una curva de arranque. El onboarding formal lleva semanas, pero entender del todo una operación —sus excepciones, sus acuerdos tácitos, por qué algo se hizo así— lleva más tiempo que eso. Tampoco es un modelo en el que puedas desentenderte: alguien de tu lado tiene que priorizar la cola y validar decisiones. Y pagas una capacidad mensual, la uses entera o no —por eso importa entender exactamente qué pasa con las horas que no consumes.
Una precisión, porque es un malentendido frecuente: una operación pequeña y estable no es un caso que sobre para este modelo. Puede ser aquel en el que el deterioro pasa más desapercibido. Cuando nada urge, nadie revisa; y a los dos años la lista de «algún día lo mejoramos» es más larga que el backlog original. Para eso existe el nivel de entrada: capacidad reducida, suficiente para no perder la evolución.
Qué exigirle a un servicio gestionado
Si te decides por esta vía, hay cinco cosas que separan un servicio real de un contrato de soporte con otro nombre. Sirven para evaluar a cualquier proveedor, nosotros incluidos.
1. Que cubra los cuatro frentes, no solo el primero. Soporte a la operación, administración de la plataforma, evolución continua y prevención. Si la propuesta solo habla de resolver incidencias, es soporte. La evolución —que la plataforma gane capacidades de forma regular y previsible, con una cadencia acordada— es la parte que vacía la cola.
2. Que haya un mecanismo de gobierno, no solo una bolsa de horas. Un backlog visible, una cadencia para priorizarlo y criterios para decidir qué se hace, qué queda en espera y qué no conviene construir. Las horas indican capacidad; no garantizan dirección. Pregunta quién convierte los objetivos de negocio en un plan y cómo se mide el avance: sin eso, la cola sigue sin avanzar aunque pagues por horas.
3. Que alguien evalúe tus iniciativas, no solo las ejecute. Cuando pidas algo, la respuesta útil no es «son ocho horas»: es si tiene sentido hacerlo así, si es compatible con lo que ya existe, y si hay una forma estándar de conseguirlo sin desarrollo. Un proveedor que solo ejecuta lo que le pides te construye deuda técnica con tu propio presupuesto. Aquí entra también la revisión de los releases: qué capacidad nueva te sirve y qué cambio te afecta antes de que llegue.
4. Que el SLA sea contractual y medible. «Te respondemos rápido» no es un compromiso. Un tiempo de primera respuesta ante una incidencia crítica, por escrito y diferenciado por severidad, sí lo es.
Y hay una pregunta que importa tanto como el número: qué pasa después de esa primera respuesta. Con qué frecuencia te informan mientras el caso sigue abierto, quién escala y cuándo, y qué ocurre si la causa está en un tercero o en el propio Salesforce. Desconfía de quien te prometa un tiempo de resolución cerrado para cualquier incidencia: la resolución depende de factores que ningún proveedor controla del todo, y comprometerla sin matices es más una técnica de venta que un compromiso real. Lo que sí se puede exigir es un proceso claro y comunicación constante.
5. Que el conocimiento sea transferible y la salida ordenada. Documentar es necesario pero no basta. Confirma que tu empresa conserva el control de los accesos y la propiedad de las configuraciones y del código, que las decisiones quedan justificadas por escrito, y que existe un procedimiento de traspaso si algún día cambias de proveedor. Es la protección de fondo contra la dependencia.
Cómo lo planteamos nosotros
Con esos cinco criterios sobre la mesa, así es como trabajamos.
Un equipo, no una persona. En un servicio gestionado interviene quien haga falta según lo que toque ese mes: administración, consultoría funcional, desarrollo, arquitectura. No se contrata un perfil y se espera que cubra todo.
Especialización en Field Service. Es donde tenemos la mayor profundidad: implementaciones para más de 9.000 usuarios en operaciones de campo, con integraciones a sistemas legados y los problemas que se vuelven críticos a esa escala. Si tu Salesforce incluye operación de campo, esa especialización se nota en el tipo de preguntas que hacemos.
Agentforce en producción, no en presentación. El asistente que ves en este sitio —Maia, el chat de la esquina— es nuestro, construido con la misma tecnología que implementamos para clientes. No sustituye a un caso de éxito ni a una evaluación técnica, pero es una prueba pública de que no hablamos de Agentforce solo desde una diapositiva. Puedes probarlo ahora mismo.
Evolución con criterio, no solo ejecución. Cada iniciativa se evalúa antes de estimarse: si resuelve algo que vale la pena, si encaja con lo que ya existe, y si hay una vía estándar que evite desarrollo. A eso se suman los health checks, la revisión de arquitectura y la de cada release. El objetivo es doble: que la mayoría de los problemas no lleguen a serlo, y que la cola de mejoras avance sin generar una cola nueva de deuda técnica.
La capacidad no consumida tiene reglas explícitas. Según el plan, hasta una cuarta parte —o hasta la totalidad, en el nivel más alto— de las horas no usadas puede pasar al mes siguiente, y también puedes adelantar hasta un porcentaje definido de capacidad futura cuando aparece un pico. Los porcentajes quedan definidos por plan desde el inicio del contrato, no se negocian caso a caso. Es una cláusula que conviene preguntar siempre, a nosotros o a cualquier otro proveedor: qué pasa exactamente con las horas que no usas, y si eso está por escrito.
SLA por escrito y diferenciado por severidad, con tiempos de primera respuesta ante incidencias críticas que van desde las 12 horas en el nivel de entrada hasta 1 hora en el más alto, dentro de la cobertura horaria contratada. Y para lo que viene después de esa primera respuesta, un proceso definido de seguimiento y escalamiento.
El punto de partida
Antes de elegir un plan, la pregunta útil no es «¿cuántas horas necesito?». Nadie puede responder eso en frío.
Hay tres que sí tienen respuesta hoy mismo, y que dicen más que cualquier estimación hecha en frío:
- ¿Cuántas solicitudes de mejora tienes pendientes? No las que están en curso: las que alguien pidió y siguen esperando. Si hay que buscarlas en un correo o en la cabeza de alguien, esa ya es la respuesta.
- ¿Cuánto tardas en empezar a trabajar una iniciativa nueva? No en terminarla: en empezarla. Cuando negocio pide algo y pasan seis semanas hasta que alguien lo toca, el cuello de botella no es la capacidad técnica, es que nadie tiene ese encargo.
- ¿Cuánto hace que nadie revisa si lo que se construyó hace dos años sigue teniendo sentido?
Si las respuestas te incomodan, el problema no es de soporte. Es una cola que nadie está moviendo.
En el siguiente artículo desglosamos los cuatro niveles de servicio gestionado y qué perfil de operación encaja en cada uno.
¿Prefieres partir de tu caso concreto? Solicita una evaluación gratuita y revisamos el estado de tu plataforma antes de proponerte nada.
