La respuesta breve
Las propuestas que presentan los diferentes integradores de Salesforce suelen parecer casi idénticas: utilizan los mismos términos, como Discovery, Agile, Best Practice, y prometen el mismo "acompañamiento cercano". La verdadera diferencia se revela solo cuando se examina cada propuesta con preguntas concretas que exponen la forma de pensar del proveedor, no solo lo que ofrece entregar. El objetivo de las siguientes 15 preguntas es identificar las brechas antes de firmar, y no después de que el proyecto ya esté estancado.
Las preguntas se dividen en seis temas: equipo, metodología, arquitectura, datos, condiciones comerciales y continuidad. Cada pregunta incluye una breve explicación de por qué es importante y una descripción de cómo sonaría una respuesta débil, para que sea fácil identificarla en tiempo real, ya sea en una reunión o en un documento de propuesta.
Las implicaciones prácticas de la elección en todo el proceso de implementación se detallaron por separado en Empresa de implementación de Salesforce.
Por qué 15 preguntas y no una lista de requisitos técnicos
Una lista de requisitos técnicos —cuántos Sandbox, qué licencias, tiempos de SLA— es importante, pero no suficiente. Verifica lo que el proveedor dice que hará, no cómo abordará la situación si la planificación original resulta imprecisa. Las preguntas aquí se seleccionaron porque revelan patrones de trabajo: cómo el equipo documenta las decisiones, cómo maneja los datos sucios y qué sucede cuando algo no sale según lo planeado.
Tabla resumen: respuesta fuerte vs. respuesta débil
| Tema | Una respuesta fuerte suena así | Una respuesta débil suena así |
|---|---|---|
| Equipo | "La consultora X lidera la arquitectura, el desarrollador Y ejecuta, enviaremos CV y permitiremos una breve entrevista" | "Tenemos un equipo experimentado, asignaremos al adecuado durante el Kickoff" |
| Metodología | "Sprints de dos semanas, demo real al final de cada sprint, backlog compartido en Jira" | "Trabajamos con metodología Agile, es flexible y se adapta a cualquier proyecto" |
| Arquitectura | "Crearemos un ADR para cada decisión clave, incluyendo la alternativa descartada y la razón" | "Elegiremos la mejor solución según nuestra experiencia" |
| Datos | "Ejecutaremos Data Profiling antes de la propuesta final, le informaremos sobre la calidad de las fuentes" | "Nos ocuparemos de la limpieza de datos durante el desarrollo" |
| Comercial | "Precio fijo para un Scope definido, horas extra según Change Request documentado" | "T&M flexible para no limitarle" |
| Continuidad | "Documento de traspaso, capacitación para Admin interno, dos semanas de Hypercare después del Go Live" | "Siempre estaremos aquí para usted, no hace falta un protocolo de despedida" |
Equipo: quién trabajará realmente en el proyecto
1. Quién acompañará realmente el proyecto, no solo la propuesta
Esta pregunta es crítica porque muchas propuestas presentan al miembro sénior del equipo en la reunión de ventas y lo reemplazan por un consultor júnior después de la firma. Una respuesta sólida incluye nombres, roles y el porcentaje de dedicación asignado. Una respuesta débil suena a "elegiremos al más adecuado según la disponibilidad", lo que significa que no hay una asignación real hasta el último momento.
2. Cuántos proyectos paralelos maneja cada consultor al mismo tiempo
Un consultor que gestiona cinco proyectos simultáneamente no puede prestar atención a los detalles. Una respuesta sólida reconocerá esta limitación y presentará un número razonable (generalmente dos o tres proyectos). Una respuesta débil evade o contesta "depende de la carga de trabajo", sin un número concreto.
3. Qué sucede si el consultor principal se va a mitad del proyecto
Una respuesta sólida describe un proceso de traspaso documentado, una superposición de dos semanas y una documentación continua que permite la sustitución sin pérdida de conocimiento. Una respuesta débil afirma que "esto casi nunca ocurre con nosotros" sin un plan de contingencia. Se puede encontrar más información sobre una estructura de trabajo adecuada con un consultor de Salesforce.
Metodología: cómo se desarrolla el trabajo en la práctica
4. Cómo es un sprint típico, qué sucede cuando algo no está listo a tiempo
Una respuesta sólida describe la Planificación del Sprint, un Daily breve, Demo y Retrospectiva, y también qué sucede cuando una tarea se atasca: si se pospone al siguiente sprint de forma transparente. Una respuesta débil se limita a "trabajamos con metodología Agile" sin detallar un ritual concreto.
5. Cómo es la comunicación continua: canal, frecuencia y responsable
Una respuesta sólida detalla el canal (Slack, Teams), una reunión de estado semanal fija y un único punto de contacto para escalaciones. Una respuesta débil responde "estaremos disponibles siempre por correo electrónico", lo que en la práctica significa que no hay un SLA para la respuesta.
6. Cómo se prueba el trabajo antes de presentarse al cliente como terminado
Una respuesta sólida describe una revisión de QA interna, una Checklist de aceptación y una revisión de acceso y permisos antes de la Demo. Una respuesta débil admite indirectamente que la primera Demo para el cliente es también la primera prueba.
Arquitectura: cómo se toman las decisiones
7. Cómo se documentan las decisiones arquitectónicas y quién las aprueba
Una respuesta sólida presenta un formato breve para la decisión —problema, alternativas, elección y razón— que se guarda y es accesible para el cliente. Una respuesta débil dice "elegimos la solución correcta" sin documentar por qué se descartaron otras alternativas.
8. Cómo afrontará la solución la carga y el crecimiento en dos o tres años
Una respuesta sólida aborda las limitaciones de Governor Limits, el volumen de datos esperado y la planificación de la expansión. Una respuesta débil responde "Salesforce es escalable por naturaleza" sin relacionarlo con el caso específico.
9. Qué sucede cuando un nuevo requisito entra en conflicto con una decisión anterior
Una respuesta sólida describe un proceso de Change Request que evalúa el impacto en lo que ya se ha construido. Una respuesta débil simplemente promete "nos adaptaremos a cualquier cambio", lo que generalmente termina en una deuda técnica que se acumula silenciosamente.
Datos: el punto donde la mayoría de los proyectos se estancan
10. Cómo se verifica la calidad de los datos antes de empezar a construir
Una respuesta sólida incluye una etapa temprana de Profiling —duplicados, campos vacíos, formatos inconsistentes— y un cronograma para la corrección. Una respuesta débil lo pospone a "lo abordaremos durante la migración", lo que casi siempre prolonga el proyecto.
11. Cuál es la fuente de verdad para cada tipo de dato, y cómo se gestiona la duplicidad entre sistemas
Una respuesta sólida identifica de antemano qué sistemas "prevalecen" en caso de conflicto (por ejemplo, ERP frente a Salesforce para un cliente existente) y documenta la regla. Una respuesta débil responde "Salesforce será la fuente de verdad" de manera general sin verificar si esto es cierto para cada objeto.
12. Cuál es el plan de respaldo y recuperación, y quién es responsable de él después de la implementación
Una respuesta sólida detalla las herramientas de respaldo, la frecuencia y quién realiza la recuperación en la práctica cuando es necesario. Una respuesta débil asume que Salesforce "ya se encarga de eso" sin distinguir entre el respaldo de la plataforma y el respaldo a nivel de organización.
Comercial y continuidad: qué sucede después de la firma
13. Cómo se estructura el precio: fijo, T&M o combinado, y qué incluye realmente
Una respuesta sólida desglosa el precio en Workstreams con horas estimadas para cada uno, y define qué se considera un Change Request con costo adicional. Una respuesta débil proporciona una cifra global sin desglosarla, lo que dificulta la comparación entre propuestas.
14. Qué sucede si el proyecto se excede en tiempo: quién asume el costo
Una respuesta sólida distingue entre un excedente causado por el proveedor (a su cargo) y un excedente causado por un cambio de requisitos del cliente (con costo). Una respuesta débil se formula de manera ambigua, permitiendo al proveedor trasladar cualquier retraso al cliente.
15. Qué sucede al finalizar el proyecto: qué soporte, por cuánto tiempo y a qué tarifa
Una respuesta sólida incluye un período definido de Hypercare (generalmente de dos a cuatro semanas), un documento de traspaso y capacitación para el Admin interno. Una respuesta débil promete "soporte continuo" sin una tarifa, alcance o fecha de finalización claros. Se puede encontrar más información sobre la redacción adecuada de tales cláusulas contractuales en SOW de proyectos de Salesforce.
Escenario organizacional de ejemplo
Una empresa de servicios financieros recibió tres propuestas para fusionar dos sistemas CRM antiguos en un único Salesforce. Dos de las propuestas eran un 20%-25% más bajas en precio que la tercera. Cuando el CIO preguntó la pregunta 10 (prueba de calidad de datos temprana), los dos proveedores más económicos respondieron "lo abordaremos como parte de la migración", mientras que el proveedor más caro presentó un plan de Profiling de una semana antes de que se acordara el monto final.
La organización eligió al proveedor más caro. La semana de Profiling reveló aproximadamente 12.000 registros duplicados y un campo de fecha con formato inconsistente en 3 de las fuentes de datos. Esta corrección temprana se incluyó en el precio original; con los otros dos proveedores, se habría descubierto durante la migración, como un cambio de Scope con costo adicional.
La lección aquí no es que "lo barato siempre es malo", sino que la brecha entre una respuesta detallada y una respuesta general equivale a dinero real, y solo se puede descubrir con preguntas enfocadas antes de la firma, no después.
Checklist para la comparación de propuestas
- ☐ Hemos recibido los nombres y los porcentajes de dedicación del equipo propuesto, no solo una descripción general.
- ☐ Hemos verificado cómo cada proveedor documenta las decisiones arquitectónicas.
- ☐ Hemos solicitado un plan de Profiling de datos antes de firmar.
- ☐ Hemos desglosado el precio en Workstreams con horas estimadas.
- ☐ Hemos aclarado quién asume el costo de un excedente que no es culpa del cliente.
- ☐ Hemos recibido una descripción explícita del período de Hypercare y sus condiciones.
- ☐ Hemos consultado referencias de clientes con un alcance de proyecto similar.
- ☐ Hemos confirmado que el consultor presentado en la reunión es quien trabajará realmente.
- ☐ Hemos verificado cuántos proyectos paralelos maneja cada consultor principal.
- ☐ Hemos definido de antemano qué evidencia demostrará el éxito al finalizar el proyecto.
Nota final: las preguntas son una herramienta, no un ritual
El propósito de las 15 preguntas no es avergonzar a un proveedor ni alargar innecesariamente el proceso de selección. Se trata de revelar de antemano dónde la propuesta se basa en una suposición no escrita. Un buen proveedor no se ofenderá por las preguntas, se complacerá en responderlas porque le reducen el riesgo a largo plazo. Un proveedor que las evade, o que responde con generalidades recurrentes, da con ello una respuesta por sí mismo.
Cuando no se cuenta con la capacidad interna para llevar a cabo un proceso de comparación de este tipo, el servicio de consultoría y definición de requisitos es el camino práctico a seguir, que incluye la elaboración de un Scorecard ponderado, el acompañamiento en las reuniones con los oferentes y la comparación de las respuestas con criterios objetivos.
Fuentes profesionales
- HPI Pro – Consultoría y definición de requisitos — https://hpi.pro/consulting-discovery
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Servicios de Salesforce — https://hpi.pro/services