Revisión de diseño para cambios relevantes
Todo cambio que afecte al modelo de datos, los permisos o una integración pasa por una revisión profesional antes de construirse. Este paso ahorra la mayor parte del retrabajo.
Soporte y mejora continua
Salesforce no termina el día del go-live.
La organización, los usuarios y los procesos siguen cambiando. Nuestro modelo de cuidado continuo permite mantener, mejorar y ampliar el sistema de forma documentada, priorizada y medible, sin acumular nueva deuda técnica.
Ciclo de control operativo
Un ciclo operativo, no una lista de solicitudes
La diferencia entre un soporte que apaga incendios y un cuidado que genera valor es un ciclo cerrado: cada solicitud se mide, se prioriza, se entrega y se verifica, y el resultado alimenta el siguiente ciclo.
Ciclo de control operativo
- 01
Recepción
Un único canal de solicitudes con clasificación, responsable y estado visible.
- 02
Priorización
Clasificación conjunta por impacto de negocio, riesgo y esfuerzo.
- 03
Construcción y prueba
Construido en sandbox, probado en aceptación y liberado de forma controlada.
- 04
Medición y aprendizaje
Informe de actividad, métricas de adopción y revisión de excepciones.
↻ El ciclo se repite: cada iteración alimenta la priorización de la siguiente
Alcance de responsabilidad
Qué puede incluir el cuidado continuo
- Gestión de incidencias
- Soporte a usuarios
- Cambios y ajustes
- Flows y automatización
- Desarrollo Apex y LWC
- Informes y dashboards
- Gestión de permisos
- Calidad de datos
- Monitorización de integraciones
- Gestión de releases
- Gestión de backlog
- Formación y capacitación
- Gobernanza y revisión de diseño
- Roadmap trimestral
- Reducción de deuda técnica
- Preparación para releases de Salesforce
Modelos
Elegidos según la necesidad, no según el paquete
| Modelo | Cuándo encaja | Qué obtiene | Limitación a tener en cuenta |
|---|---|---|---|
| Bolsa de horas | Necesidades pequeñas y variables | Total flexibilidad para elegir tareas | Menos adecuado para planificación a largo plazo |
| Retainer mensual | Un flujo constante de mejoras y soporte | Capacidad conocida y priorización mensual | Requiere disciplina de priorización por parte del cliente |
| Equipo de entrega continuo | Un sistema core con uso amplio | Soporte, desarrollo y mantenimiento bajo una misma gestión | Un compromiso más amplio |
| Arquitecto fraccional | Existe un equipo interno pero no un decisor técnico senior | Revisión de diseño, gobernanza y control de deuda técnica | No sustituye capacidad de entrega |
| Proyecto de mejora acotado | Un objetivo definido con inicio y fin | Alcance y entregable claros | No cubre el soporte continuo |
Bolsa de horas
- Cuándo encaja
- Necesidades pequeñas y variables
- Qué obtiene
- Total flexibilidad para elegir tareas
- Limitación a tener en cuenta
- Menos adecuado para planificación a largo plazo
Retainer mensual
- Cuándo encaja
- Un flujo constante de mejoras y soporte
- Qué obtiene
- Capacidad conocida y priorización mensual
- Limitación a tener en cuenta
- Requiere disciplina de priorización por parte del cliente
Equipo de entrega continuo
- Cuándo encaja
- Un sistema core con uso amplio
- Qué obtiene
- Soporte, desarrollo y mantenimiento bajo una misma gestión
- Limitación a tener en cuenta
- Un compromiso más amplio
Arquitecto fraccional
- Cuándo encaja
- Existe un equipo interno pero no un decisor técnico senior
- Qué obtiene
- Revisión de diseño, gobernanza y control de deuda técnica
- Limitación a tener en cuenta
- No sustituye capacidad de entrega
Proyecto de mejora acotado
- Cuándo encaja
- Un objetivo definido con inicio y fin
- Qué obtiene
- Alcance y entregable claros
- Limitación a tener en cuenta
- No cubre el soporte continuo
Las condiciones de precio y SLA se hablan en una llamada y no se publican en el sitio.
Gobernanza
Cuatro mecanismos que mantienen sano un sistema en el tiempo
Control de deuda técnica
Las automatizaciones duplicadas, los campos sin uso y los permisos demasiado amplios se miden y gestionan como elementos reales del backlog, con capacidad dedicada asignada.
Preparación para releases
Salesforce lanza tres releases al año. Revisamos con antelación qué cambia, qué puede romperse y qué merece la pena adoptar.
Medición de adopción
Las métricas de uso por rol revelan dónde el proceso realmente no funciona, antes de que los datos de los informes dejen de ser fiables.
Continúe desde aquí
Servicios y guías relacionados
Preguntas frecuentes
Soporte y cuidado continuo — preguntas habituales
¿Cuál es la diferencia entre soporte y cuidado continuo?
El soporte gestiona incidencias y dudas de usuarios y devuelve el sistema a un estado funcional. El cuidado continuo también se pregunta qué debe cambiar: priorizar mejoras, controlar la deuda técnica, revisar el diseño de los cambios de mayor calado y mantener un roadmap con visión de futuro. Una organización que solo compra soporte acaba con un sistema que funciona pero nunca mejora.
¿Qué se considera una incidencia urgente?
Un evento que bloquea un proceso de negocio para un grupo de usuarios sin una alternativa razonable: un fallo en la captación de leads, una automatización clave que deja de funcionar o una integración que se ha detenido. Una solicitud de un nuevo campo o un nuevo informe no es una incidencia, por importante que sea. Esa distinción se acuerda por escrito de antemano.
¿Todo cambio pasa por un entorno de pruebas?
Sí. Todo cambio relevante se construye en un sandbox, se prueba frente a un escenario de negocio y solo entonces se libera a producción dentro de una ventana definida. La única excepción es la corrección de una incidencia bloqueante, y aun así queda documentada y vuelve al circuito estándar en el siguiente ciclo.
¿Cómo se decide la prioridad?
Por impacto de negocio, número de usuarios afectados, riesgo y esfuerzo, en una reunión de priorización periódica con el responsable de proceso por parte del cliente. No priorizamos en solitario, porque priorizar es una decisión de negocio, no técnica.
¿Qué ocurre con la deuda técnica acumulada antes de empezar?
Al inicio del proyecto mapeamos automatizaciones duplicadas, campos sin uso, código sin probar y permisos demasiado amplios. Los hallazgos entran en una lista priorizada, y se asigna una parte fija de la capacidad mensual a reducir esa deuda; de lo contrario, solo crece.
¿Podemos empezar el cuidado continuo aunque no hayan implementado ustedes el sistema?
Sí, y es un caso habitual. En esa situación empezamos con una revisión breve del sistema que mapea el estado actual, de modo que el proyecto se basa en conocimiento y no en conjeturas.
Siguiente paso
Revisar un modelo de soporte
Analizaremos el alcance de uso, las necesidades abiertas y el nivel de gobernanza requerido, y propondremos un modelo acorde a su ritmo.