Casi todas las agencias VTEX en Colombia muestran los mismos logos y prometen los mismos plazos. Lo que las diferencia se ve en cinco cosas verificables: el nivel de partner registrado en VTEX, quién compone el equipo asignado, dónde vive el código, cómo está escrito el SLA, y qué dicen los clientes que se fueron.
Esta guía la escribimos siendo parte interesada: ePartner es una de esas agencias. Por eso incluimos también los criterios donde nosotros no siempre somos la mejor opción. Un artículo que solo se elogia a sí mismo no le sirve a nadie que esté decidiendo.
1. Certificación: verifícala en la fuente, no en la web del proveedor
VTEX clasifica a sus partners por niveles y publica el listado en su propio directorio. Un logo en un pie de página no prueba nada. Pide dos cosas concretas: el nivel actual de partner, y los nombres de los desarrolladores certificados en VTEX IO que van a estar asignados a tu proyecto.
La pregunta que incomoda y que hay que hacer: "¿las personas que me están presentando la propuesta son las mismas que van a ejecutar el proyecto?". En muchas agencias la respuesta honesta es no.
2. Composición real del equipo
| Perfil | Qué debe cubrir | Señal de alarma |
|---|---|---|
| Tech lead VTEX IO | Arquitectura del theme, apps custom, revisión de código | No existe, o es compartido entre seis proyectos |
| Desarrollador frontend | Componentes, performance, accesibilidad | El mismo perfil hace frontend, catálogo y soporte |
| Especialista de catálogo/OMS | Modelado de categorías, SKUs, políticas comerciales | Se asume que lo hace el cliente sin acompañamiento |
| Integraciones | ERP, pasarelas, logística | Se subcontrata sin visibilidad para el cliente |
| QA | Pruebas de checkout, pagos, promociones | No hay rol de QA; lo prueba el desarrollador |
No todos los proyectos necesitan los cinco perfiles a tiempo completo, pero todos necesitan que alguien sea responsable de cada uno. Si la propuesta no dice quién, la respuesta es "nadie".
3. Propiedad del código: el punto que más caro sale ignorar
El repositorio del theme y de las apps custom debe vivir en una organización de tu empresa, con el partner invitado como colaborador. También el acceso de administrador a la cuenta VTEX, las credenciales de las integraciones y la documentación de despliegue.
Si el código vive en el repositorio del proveedor, cambiar de proveedor deja de ser una decisión comercial y se convierte en un proyecto de recuperación. Es la forma más común y silenciosa de quedar amarrado.
4. El SLA, leído con lupa
- Severidades definidas. "Tienda caída" y "un banner desalineado" no pueden tener el mismo tiempo de respuesta.
- Respuesta y solución separadas. Responder en una hora y resolver en tres semanas cumple un SLA mal escrito.
- Qué consume horas. ¿Las reuniones? ¿El diagnóstico de un incidente que resultó ser de un tercero? Defínelo antes, no después.
- Horas no consumidas. Si se pierden cada mes, el modelo empuja a inventar trabajo. Si acumulan sin límite, el proveedor no puede planear. Un tope de acumulación razonable resuelve ambos.
- Ventana de cobertura y escalamiento. Especialmente relevante si vendes en fechas pico o en varios husos horarios.
5. Referencias: pregunta por los clientes que se fueron
Las referencias que ofrece una agencia son siempre sus mejores casos. La pregunta útil es otra: "¿qué cliente los dejó en los últimos dos años y por qué?". Una agencia con historia tiene esa respuesta. Una que dice que nunca perdió un cliente está omitiendo algo o es demasiado nueva.
Cuándo un partner grande no es la mejor opción
Si tu proyecto es una tienda B2C de catálogo acotado con un presupuesto ajustado, una agencia grande te va a asignar su equipo más junior y vas a competir por atención con cuentas mayores. En ese escenario un partner pequeño y enfocado suele darte mejor servicio. Vale también para nosotros: no todos los proyectos son para ePartner.
Checklist para la reunión de selección
- ¿En qué nivel están registrados en el directorio de partners de VTEX?
- ¿Quiénes son, con nombre, los certificados asignados a mi proyecto?
- ¿En qué organización de Git vive el código y quién es el dueño?
- ¿Cómo están definidas las severidades y los tiempos del SLA?
- ¿Qué pasa con las horas no consumidas del mes?
- ¿Qué cliente los dejó recientemente y por qué?
- ¿Qué parte del alcance está subcontratada?
- ¿Cómo se ve el traspaso si decidimos cambiar de proveedor?
Cómo leer una propuesta: las señales están en el documento
Una propuesta dice más por lo que omite que por lo que promete. Cinco cosas que conviene buscar antes de comparar precios:
- Supuestos declarados. Una propuesta seria dice de qué depende el plazo: cantidad de SKUs, existencia de conector de ERP, número de pasarelas. Una que da una fecha sin supuestos está adivinando o está dejando espacio para cobrar los cambios después.
- Qué está explícitamente fuera de alcance. La ausencia de esta sección casi siempre significa que la discusión sobre el alcance se va a dar a mitad del proyecto, en el peor momento.
- Entregables por fase, no solo un total. Si no se puede verificar el avance a mitad de camino, el riesgo es todo tuyo.
- Responsabilidades del cliente. Los proyectos se atrasan tanto por el proveedor como por el cliente. Una propuesta que no dice qué necesita de ti y para cuándo, va a atrasarse y la conversación de culpas será incómoda.
- Qué pasa después del go-live. La transición de proyecto a soporte debería estar descrita antes de firmar el proyecto, no negociarse cuando la tienda ya está en producción y tu posición para negociar es la más débil posible.
Modelos de contratación y cuándo conviene cada uno
| Modelo | Cómo funciona | Cuándo conviene | Riesgo principal |
|---|---|---|---|
| Precio fijo por alcance | Alcance cerrado, precio cerrado | Proyectos con requisitos claros y estables | Todo cambio es una orden de cambio; incentiva interpretar el alcance de forma estrecha |
| Célula dedicada | Un equipo fijo por mes, con backlog priorizado por el cliente | Operaciones que evolucionan de forma continua | Sin gobierno del backlog, se paga capacidad que no produce valor |
| Bolsa de horas | Horas prepagadas que se consumen por demanda | Soporte y evolutivos después del go-live | Sin definición de qué consume horas, la bolsa se agota en actividades difusas |
| Mixto | Precio fijo para el core, célula para la evolución | La mayoría de implementaciones grandes | Requiere claridad sobre dónde termina uno y empieza el otro |
El error frecuente es contratar precio fijo para un proyecto cuyo alcance todavía se está descubriendo. El resultado predecible son órdenes de cambio mensuales y una relación tensa desde el mes dos. Si el alcance no está claro, conviene pagar primero un descubrimiento acotado y cerrar el precio después, con información.
Gobierno: la parte que decide si el proyecto sale a tiempo
Los proyectos rara vez fracasan por incapacidad técnica. Fracasan porque las decisiones tardan. Antes de arrancar conviene tener resuelto:
- Quién decide del lado del cliente. Una persona con autoridad real, no un comité que se reúne cada quince días.
- Cadencia de revisión. Una demo funcional cada dos semanas, con la tienda real, no con presentaciones.
- Criterio de aceptación por fase. Definido antes de empezar la fase, no negociado al final.
- Ruta de escalamiento. A quién se llama cuando algo se traba, en ambas direcciones.
Si la aprobación de un diseño toma tres semanas, ningún equipo técnico compensa esa demora. El gobierno del proyecto es responsabilidad compartida, y conviene decirlo antes de firmar.
El traspaso: qué debe existir desde el día uno
La medida más honesta de la calidad de un partner es qué tan fácil sería reemplazarlo. No porque planees hacerlo, sino porque un proveedor que construye para ser reemplazable construye ordenado. Lo mínimo que debe existir y estar actualizado:
- Repositorio en la organización del cliente, con historial completo y README de despliegue.
- Inventario de integraciones: qué se conecta con qué, con qué credenciales y quién las administra.
- Documentación del modelo de catálogo: categorías, atributos, especificaciones y por qué se decidieron así.
- Accesos de administrador de la cuenta VTEX en manos del cliente, no solo del partner.
- Registro de decisiones técnicas relevantes y sus razones.
Pedir esto en la reunión de selección tiene un efecto secundario útil: la respuesta revela de inmediato cómo trabaja la agencia. Quien ya lo hace, lo responde en un minuto.
Qué hacemos nosotros al respecto
En ePartner el código vive en la organización del cliente desde el primer commit, el equipo asignado se nombra en la propuesta y las severidades del SLA se firman antes de arrancar. Puedes ver nuestras marcas cliente, cómo estructuramos el soporte técnico VTEX, o pedirnos las referencias directamente.