La primera consulta técnica suele ser el punto donde se definen el alcance y las prioridades de una integración. Si llegas con una idea vaga de lo que necesitas, la conversación se va por las ramas y terminas con más dudas que respuestas. Por eso conviene dedicar una hora antes de la llamada a ordenar lo que ya tienes.
Empieza por el inventario de sistemas. Anota qué plataformas intervienen, quién las administra y qué versión de API expone cada una. No hace falta documentación perfecta: un listado con nombres, URLs base y responsables alcanza para que el equipo técnico sepa por dónde empezar a mirar.
Después revisa los esquemas de datos. Si vas a conectar un ERP con un middleware, lleva los modelos de las entidades principales: clientes, pedidos, facturas o el dominio que corresponda. Marca qué campos son obligatorios, cuáles pueden venir vacíos y si existen transformaciones de formato que ya hayas detectado.
También conviene preparar ejemplos reales de tráfico. Un par de peticiones y respuestas capturadas de tu entorno de pruebas ayudan más que cualquier descripción verbal. Con eso el consultor puede ver el formato exacto de los payloads, los códigos de error que aparecen y el comportamiento de los reintentos.
Finalmente, define qué significa "funcionar" para tu caso. ¿Es sincronizar catálogos cada noche? ¿Procesar pedidos en menos de dos segundos? ¿Tener un registro auditable de cada llamada? Cuando el objetivo está expresado en términos medibles, la consulta termina con un plan accionable y no con una lista de opciones.
Si ya tienes una integración en producción y el problema es recurrente, trae también el historial de incidentes. Las fechas, los mensajes de error y las horas pico suelen revelar patrones que no aparecen en una revisión estática del código. Con ese material, la primera consulta se convierte en una sesión de diagnóstico real.