Cómo automatizar los pedidos de venta recibidos por email con Business Central
Del correo y el PDF a un pedido validado en el ERP, sin convertir la automatización en una fábrica de errores.
La entrada manual de pedidos consume tiempo, retrasa la respuesta al cliente y esconde errores que terminan apareciendo en almacén, facturación o cobro. La solución no consiste en dejar que una IA contabilice a ciegas: consiste en diseñar un proceso conectado que capture, compruebe, proponga y escale cada excepción.
Más velocidad de respuesta
Excepciones bajo control
La idea clave
Automatizar no es saltarse el control.
El sistema debe crear una propuesta fiable, explicar qué ha validado y detenerse cuando el pedido no cumple las reglas. El objetivo es que el equipo revise excepciones, no que vuelva a teclear cada línea.
El pedido llega en segundos. Introducirlo correctamente en el ERP puede tardar mucho más.
Un cliente escribe un correo, adjunta un PDF y espera confirmación. A partir de ese momento comienza una cadena de tareas invisibles: interpretar lo que pide, identificar referencias, revisar condiciones, comprobar stock, aclarar dudas, registrar líneas y evitar que una equivocación llegue a expedición. Cuando el volumen crece, el problema deja de ser administrativo y se convierte en comercial.
Tiempo que no vende
El equipo comercial o de administración dedica horas a trasladar datos de un documento a otro. Es trabajo imprescindible, pero no genera conversación, servicio ni crecimiento.
Errores que viajan
Una referencia mal copiada, una cantidad ambigua o una dirección antigua pueden parecer detalles. Cuando llegan a almacén, transporte o factura, ya son incidencias costosas.
Respuesta lenta
Mientras nadie registra el pedido, el cliente no sabe si existe stock, si el precio es correcto ni cuándo recibirá el producto. La demora erosiona confianza y conversión.
Escala bloqueada
Más pedidos exigen más personas si el proceso sigue siendo manual. La organización crece, pero su capacidad de respuesta no aumenta al mismo ritmo.
Del email al pedido: seis etapas, no un truco de magia
La automatización fiable no empieza preguntando qué modelo de IA utilizar. Empieza describiendo el recorrido del pedido y separando captura, interpretación, validación, decisión y ejecución. Cada etapa tiene un riesgo distinto y necesita una tecnología adecuada.
En una arquitectura habitual, Outlook o un buzón compartido recibe la solicitud; una capa documental extrae el contenido; las reglas y servicios de IA lo convierten en información estructurada; Business Central aporta clientes, productos, tarifas, disponibilidad y condiciones; Power Automate orquesta el recorrido; y una persona resuelve únicamente aquello que no cumple los criterios definidos.
Cinco tipos de pedido que parecen iguales hasta que intentas automatizarlos
Dos correos pueden contener las mismas palabras —cliente, producto, cantidad y fecha— y exigir recorridos completamente distintos. La automatización debe reconocer el contexto operativo, no limitarse a rellenar campos. Antes de construir conviene analizar qué familias de pedido existen y qué riesgo representa cada una.
Pedido recurrente de catálogo
Es el candidato más claro para comenzar. El cliente es conocido, utiliza referencias habituales, las condiciones comerciales están mantenidas y la dirección de entrega es estable. La automatización puede identificar el mensaje, extraer cabecera y líneas, validar los datos en Business Central, comprobar duplicidad y preparar el borrador de manera casi inmediata.
Incluso aquí deben contemplarse cambios de unidad, cantidades inusuales, productos bloqueados o una fecha que no pueda cumplirse. Que un pedido sea recurrente no significa que todas sus combinaciones sean normales.
«>Pedido basado en oferta
El cliente acepta una propuesta previa, pero puede modificar cantidades, fechas o alcance. El proceso debe localizar la oferta correcta, comparar versiones y decidir qué diferencias son admisibles. Crear un pedido utilizando únicamente el PDF recibido puede ignorar compromisos, descuentos o condiciones que viven en el CRM o en Business Central.
Este escenario demuestra por qué la integración entre Dynamics 365 Sales y el ERP puede ser tan relevante como la captura documental.
Pedido urgente o con entrega parcial
La palabra “urgente” no contiene una fecha fiable ni explica si el cliente acepta dividir el suministro. Hay que contrastar existencias, pedidos comprometidos, rutas logísticas y prioridades comerciales. El sistema puede proponer alternativas, pero no debería alterar por sí mismo reservas que afectan a otros clientes.
Una buena experiencia devuelve opciones concretas: servir una parte ahora, completar en una fecha determinada o sustituir un artículo. Una mala automatización se limita a registrar la fecha solicitada y deja que almacén descubra después que es imposible.
Pedido con configuración o fabricación
Cuando el producto depende de medidas, variantes, componentes o instrucciones técnicas, una descripción incompleta puede cambiar coste y plazo. No basta con encontrar el artículo “más parecido”. La automatización debe comprobar que se han proporcionado todos los atributos y que la configuración es válida.
En fabricación bajo pedido, la aceptación comercial puede activar planificación, aprovisionamiento y capacidad. Por eso conviene conectar esta entrada con la lógica explicada en fabricación bajo pedido con Business Central.
Pedido nuevo, excepcional o de alto riesgo
Un nuevo cliente, un importe extraordinario, una dirección desconocida, condiciones de pago no habituales o un país diferente requieren controles adicionales. La prioridad no es procesarlo más rápido, sino verificar que la operación puede aceptarse. Puede ser necesario revisar crédito, fiscalidad, disponibilidad, exportación, consentimiento, fraude o aprobación interna.
Este pedido no representa un fracaso de la automatización. Al contrario: detectar que necesita atención y entregarlo a la persona adecuada, con todos los datos reunidos, es una de las formas más valiosas de automatizar.
Qué medir para saber si la automatización funciona de verdad
Contar correos procesados queda muy bien en una diapositiva y dice muy poco sobre el resultado. Un sistema puede procesar miles de documentos y obligar después a corregir cientos de pedidos. Las métricas deben cubrir velocidad, calidad, autonomía, riesgo y resultado comercial.
Tiempo hasta el borrador
Minutos desde la recepción hasta que existe un pedido preparado para validar. Permite separar retraso de bandeja, extracción, consultas y revisión.
Procesamiento directo
Porcentaje de pedidos que alcanzan el estado definido sin intervención. Debe medirse por cliente, formato y tipo de pedido, no solo como promedio.
Precisión por campo
Cliente, referencia, cantidad, unidad, precio, fecha y dirección tienen riesgos diferentes. Una precisión global puede ocultar fallos críticos en un único campo.
Tasa de excepción
Qué porcentaje se detiene, por qué motivo y cuánto tarda en resolverse. Las excepciones repetidas revelan datos maestros o reglas que conviene mejorar.
Correcciones posteriores
Cambios realizados después de aceptar el borrador. Si aumentan, puede existir una falsa sensación de velocidad a costa de calidad operativa.
Confirmación al cliente
Tiempo hasta una respuesta fiable con fecha y condiciones. Es el indicador que conecta eficiencia interna con experiencia comercial.
Mide antes y después
La línea base debe recogerse antes del piloto: tiempo real, errores, espera, retrabajo y volumen. Comparar la automatización con una estimación optimista del proceso manual produce un retorno ficticio.
No premies al sistema por esconder problemas
Reducir excepciones no es positivo si el sistema ha dejado de detectarlas. Los controles deben comprobar el resultado contra pedidos expedidos, incidencias, abonos y reclamaciones.
Quién puede leer, proponer, aprobar y ejecutar
El correo puede contener precios, acuerdos, datos personales, direcciones, información fiscal y condiciones confidenciales. El flujo no debe mover esos datos a servicios no autorizados ni utilizar conexiones compartidas con permisos superiores a los necesarios.
Conviene separar identidades y capacidades: una cuenta puede leer el buzón, otra consultar Business Central y otra crear borradores. La publicación o liberación final puede mantenerse bajo responsabilidad del usuario correspondiente. Este diseño limita el impacto de un error y facilita la auditoría.
También debe definirse cuánto tiempo se conserva el documento original, dónde se almacena, quién puede consultarlo y cómo se relaciona con el pedido. La trazabilidad debe permitir reconstruir qué recibió la empresa, qué interpretó el sistema, qué cambió una persona y qué se confirmó al cliente.
Decisiones que deben quedar cerradas
- Qué buzones, clientes y tipos de documento entran en el proceso.
- Qué campos puede proponer el sistema y cuáles no puede modificar.
- Qué tolerancias permiten continuar sin intervención.
- Qué identidad utiliza cada conexión y con qué permisos.
- Quién resuelve cada clase de excepción.
- Qué evidencia debe conservarse y durante cuánto tiempo.
- Cómo se avisa cuando el proceso está detenido o degradado.
- Cómo se vuelve temporalmente al procedimiento manual sin perder pedidos.
Qué información debe entender el sistema antes de crear nada
Un pedido es mucho más que cliente, producto y cantidad. Cuanto más compleja sea la operativa, más importante será definir qué campos son obligatorios, qué fuentes tienen autoridad y qué discrepancias impiden continuar.
También conviene distinguir entre información expresada por el cliente y datos calculados por el sistema. La cantidad solicitada procede del documento; el precio aplicable puede proceder de una tarifa; la fecha viable depende de disponibilidad y capacidad; los impuestos responden a la configuración fiscal. Conservar esa procedencia permite explicar el resultado, resolver discrepancias y evitar que una inferencia termine tratándose como un dato confirmado. Cuando varias fuentes discrepan, la automatización debe aplicar una jerarquía previamente acordada o solicitar intervención, nunca improvisar silenciosamente.
Datos del cliente y del acuerdo comercial
El sistema debe identificar quién compra y bajo qué condiciones. Un mismo grupo puede tener varias sociedades, centros de entrega, direcciones, listas de precios, divisas, formas de pago y reglas de descuento. El nombre escrito en el correo no siempre coincide con el nombre maestro del ERP.
La automatización necesita criterios para resolver alias, dominios de correo, códigos externos y referencias históricas. Si hay dos candidatos posibles, debe detenerse. Elegir al azar al cliente “más parecido” no es inteligencia: es una incidencia esperando a ocurrir.
Productos, variantes y unidades
Los clientes pueden pedir mediante su propia referencia, una descripción abreviada o una denominación antigua. También pueden mezclar cajas, unidades, metros, kilos o lotes. La correspondencia debe apoyarse en tablas mantenidas, referencias cruzadas y reglas verificables.
Cuando la confianza sea insuficiente, el sistema debe mostrar la línea original, la propuesta y las alternativas. La persona decide una vez; después, esa equivalencia puede incorporarse al proceso para evitar resolver el mismo caso en cada pedido.
Precio, descuento y moneda
El precio escrito por el cliente puede no coincidir con la tarifa vigente. Puede existir una oferta, un contrato, una promoción, un descuento por volumen o un acuerdo pendiente de registrar. La automatización no debería sustituir silenciosamente el dato recibido ni aceptar cualquier valor.
Conviene comparar el precio solicitado con el calculado por Business Central, medir la diferencia y definir tolerancias. Dentro del margen autorizado, se prepara el pedido. Fuera de él, se solicita validación comercial con toda la evidencia disponible.
Disponibilidad y compromiso de entrega
Crear un pedido no equivale a poder servirlo. Hay que considerar existencias, reservas, pedidos pendientes, compras en curso, producción, almacén, calendario y fecha solicitada. Prometer sin consultar la realidad operativa es automatizar una mala experiencia.
La solución puede proponer una fecha, dividir entregas o señalar qué líneas presentan riesgo. La confirmación al cliente debe producirse después de validar capacidad, no inmediatamente después de leer el PDF.
La persona no debe revisar todos los pedidos. Debe revisar los pedidos que necesitan criterio.
Una automatización mal diseñada cambia tecleo por clics: extrae datos, pero obliga a verificar cada campo porque nadie confía en el resultado. El ahorro desaparece. El diseño correcto concentra la revisión en excepciones con significado empresarial.
El objetivo es conseguir procesamiento directo para los pedidos sencillos y una bandeja priorizada para los complejos. Cada excepción debe mostrar el motivo, el dato original, la propuesta del sistema y la acción requerida. La persona no investiga desde cero: decide con contexto.
Excepciones que deben detener el proceso
- Cliente no identificado o bloqueado.
- Referencia sin correspondencia fiable.
- Precio fuera de la tolerancia autorizada.
- Límite de crédito superado.
- Dirección nueva o inconsistente.
- Cantidad, unidad o fecha ambiguas.
- Falta de stock o compromiso inviable.
- Pedido potencialmente duplicado.
Business Central, Power Automate, Copilot Studio y Azure: qué aporta cada capa
Business Central conserva la verdad transaccional
El ERP mantiene clientes, productos, tarifas, disponibilidad, impuestos, dimensiones, condiciones y pedidos. Debe seguir siendo la fuente autorizada para las reglas que afectan a la operación y a la contabilidad.
La automatización puede consultar y proponer registros mediante conectores o APIs, pero no debe duplicar en un prompt las reglas que ya gobierna el ERP. Cuando la política cambia, debe existir un lugar claro donde mantenerla.
Power Automate orquesta los pasos
Puede detectar la llegada de un correo, guardar el documento, solicitar extracción, consultar datos, aplicar condiciones, enviar una aprobación, crear un borrador y notificar el resultado. Es especialmente apropiado para secuencias predecibles.
Su valor no está en simular razonamiento. Está en garantizar que los pasos conocidos se ejecutan de manera consistente y trazable. Para profundizar en esta decisión, consulta cuándo utilizar un flujo y cuándo un agente de IA.
Copilot Studio gestiona interacción y razonamiento
Puede intervenir cuando el proceso necesita mantener una conversación, solicitar información que falta, interpretar una explicación, elegir una herramienta o ayudar a una persona a resolver excepciones.
No todos los pedidos necesitan un agente. Si el formato es estable y las reglas son claras, una automatización determinista puede ser más barata y controlable. El agente aporta valor donde existe ambigüedad real.
Azure añade capacidades de integración e IA
Servicios documentales, integración, APIs, almacenamiento, observabilidad y modelos pueden cubrir escenarios que superan una automatización sencilla: documentos heterogéneos, gran volumen, varios ERP, canales diferentes o requisitos avanzados de rendimiento.
La arquitectura adecuada depende del proceso. Diseñar todo con una sola herramienta suele trasladar complejidad de una capa a otra, no eliminarla.
No todas las empresas necesitan la misma automatización
Una empresa que recibe veinte pedidos mensuales de clientes recurrentes no necesita la misma arquitectura que un distribuidor con miles de líneas diarias. El retorno depende del volumen, la variabilidad y el coste de la excepción.
También importa la calidad del dato. Con clientes, referencias y tarifas mantenidos, el procesamiento directo puede crecer rápidamente. Con maestros duplicados y reglas informales, conviene resolver primero la base operativa.
Proceso manual frente a proceso conectado
| Momento | Proceso manual | Proceso conectado |
|---|---|---|
| Recepción | Una persona abre y clasifica el correo. | El sistema identifica el mensaje, el cliente y los documentos. |
| Captura | Se copian cabecera y líneas. | Se extraen campos y se conserva el original. |
| Validación | Depende de memoria y comprobaciones individuales. | Se aplican reglas uniformes contra datos de Business Central. |
| Excepción | Se investiga entre correos, ERP y personas. | Se muestra el motivo, la evidencia y la acción requerida. |
| Confirmación | Se redacta después de completar el registro. | Se genera tras comprobar disponibilidad y condiciones. |
| Medición | Difícil saber cuánto tarda y dónde se atasca. | Tiempos, excepciones, precisión y procesamiento directo quedan registrados. |
Cómo calcular si merece la pena automatizar
El caso de negocio no se limita a multiplicar minutos por coste laboral. También debe valorar velocidad comercial, errores, devoluciones, retrasos, capacidad de crecimiento y calidad de la información.
Volumen y tiempo
Pedidos mensuales × minutos de registro y comprobación. Conviene separar pedidos simples, complejos y excepciones para no utilizar una media engañosa.
Coste del error
Abonos, reenvíos, transporte urgente, roturas, llamadas, horas de investigación y deterioro del servicio. Un error pequeño puede recorrer toda la cadena.
Capacidad liberada
Tiempo que el equipo puede dedicar a clientes, incidencias relevantes, previsión, venta y mejora del proceso en lugar de capturar datos repetitivos.
Una fórmula útil para empezar
Ahorro anual estimado = tiempo manual evitado + errores evitados + capacidad adicional − licencias − implantación − operación. Después hay que añadir el valor comercial de responder antes y poder absorber crecimiento sin ampliar proporcionalmente el equipo.
La IA no corrige automáticamente un maestro de datos desordenado
Si cada vendedor utiliza nombres diferentes, las referencias cruzadas no están mantenidas, los precios se pactan fuera del ERP y las fechas se confirman por teléfono, la automatización encontrará demasiadas excepciones. El problema no es que la tecnología “no funcione”; es que el proceso no dispone de una verdad operativa suficientemente clara.
Por eso el proyecto debe incluir una fase corta de diagnóstico: medir variabilidad, identificar fuentes, clasificar errores y decidir qué casos se automatizan primero. Empezar por el segmento más estable permite demostrar valor y aprender antes de abordar la cola compleja.
Un recorrido sensato: empezar con evidencia y escalar con control
Medir el proceso actual
Volumen, canales, formatos, tiempo, errores, retrabajo, personas, estacionalidad y nivel de servicio. Sin línea base, cualquier ahorro será una opinión.
Clasificar pedidos
Separar los repetitivos de los variables y las excepciones. Un piloto debe centrarse en un conjunto representativo, pero controlable.
Definir las reglas
Campos obligatorios, tolerancias, autoridad del dato, bloqueos, permisos, duplicados, aprobaciones y situaciones que requieren intervención.
Construir el piloto
Captura, validación y creación de borrador. En la primera fase es preferible revisar más y observar el comportamiento antes de aumentar autonomía.
Evaluar con datos
Precisión por campo, pedidos sin intervención, excepciones, falsos positivos, tiempo de ciclo, coste y satisfacción del equipo.
Escalar por segmentos
Añadir clientes, formatos, canales y acciones cuando los indicadores demuestren que el control se mantiene. Escalar no es eliminar supervisión sin evidencia.
Los errores más habituales no están en la demo
Crear pedidos definitivos demasiado pronto
Conviene comenzar con borradores y criterios de confianza. La autonomía debe ganarse con resultados medidos, no concederse porque el piloto haya procesado correctamente cinco documentos preparados.
Confundir extracción con comprensión
Leer “100 cajas” no resuelve qué unidad utiliza Business Central, qué contiene cada caja ni si la referencia corresponde al producto exacto. La semántica empresarial necesita reglas y maestros.
Ocultar la excepción
Un sistema que “resuelve” discrepancias sin mostrar cómo lo ha hecho reduce trabajo a costa de introducir riesgo. Cada decisión relevante debe dejar evidencia suficiente.
Diseñar una isla
Si la automatización no considera CRM, disponibilidad, precios, logística y facturación, acelera únicamente una etapa y puede desplazar el cuello de botella al siguiente departamento.
Utilizar conexiones con privilegios excesivos
La identidad que crea o modifica registros debe disponer solo de los permisos necesarios. Facilitar el desarrollo concediendo acceso amplio crea un riesgo difícil de justificar.
No definir operación y soporte
Los formatos cambian, aparecen clientes nuevos y las integraciones fallan. Hay que asignar responsables, alertas, métricas, mantenimiento y un procedimiento para recuperar pedidos detenidos.
Empieza midiendo cien pedidos reales, no imaginando el pedido perfecto
Una muestra real permite descubrir formatos, excepciones, referencias, tiempos y errores. Con esa evidencia se puede diseñar un piloto acotado, estimar retorno y decidir qué combinación de Business Central, Power Platform, Copilot Studio y Azure necesita el proceso.
El pedido es un punto de entrada. El valor aparece cuando el proceso completo permanece conectado.
Una solicitud comercial termina afectando a inventario, compras, producción, logística, factura, tesorería y servicio. La capacidad de Ayesa Digital para trabajar sobre ERP, CRM, Power Platform, Azure, datos, Copilot y soluciones sectoriales permite diseñar el recorrido completo, no solo automatizar un buzón.
Business Central
Procesos financieros, comerciales, compras, inventario, fabricación y servicio conectados en una plataforma empresarial.
Power Platform conectada al ERP
Apps, automatizaciones, datos y agentes alrededor del núcleo transaccional, sin convertir cada necesidad periférica en una personalización del ERP.
ERP + IA
La IA aporta valor cuando trabaja con datos, reglas, permisos y procesos reales, no cuando permanece aislada del sistema que sostiene la operación.
Automatización de cuentas a pagar
El mismo criterio puede aplicarse al otro lado del ciclo: recepción, cotejo y gestión de facturas de proveedores.
Hay procesos que necesitan orden antes que inteligencia artificial
Automatizar puede ser una gran decisión, pero no siempre es la primera. Si la empresa recibe pocos pedidos, todos son extraordinarios o el coste del error es muy alto, quizá sea más razonable mejorar plantillas, maestros y procedimientos. La tecnología debe resolver una fricción suficiente para justificar construcción, licencias, soporte y cambio organizativo.
Volumen demasiado bajo
Si el equipo procesa unos pocos pedidos sencillos cada semana, estandarizar el formulario o mejorar el acceso a Business Central puede aportar más retorno que una arquitectura completa.
Reglas que nadie puede explicar
Cuando cada pedido se decide mediante acuerdos informales y conocimiento personal, primero hay que hacer explícitos los criterios. Automatizar una regla que cambia según quién responda es construir sobre arena.
Datos maestros sin propietario
Si nadie mantiene referencias, unidades, direcciones, tarifas o bloqueos, el sistema encontrará contradicciones constantemente. Hace falta asignar responsabilidad antes de aumentar velocidad.
Decidir no automatizar todavía también puede ser una conclusión profesional. El diagnóstico debe determinar si conviene construir una solución, corregir el proceso, activar capacidades ya disponibles o combinar varias medidas. La oportunidad comercial no está en vender siempre más tecnología, sino en resolver el problema con una arquitectura proporcionada.
Lo que conviene aclarar antes de automatizar pedidos
¿Business Central lee por sí solo cualquier pedido recibido por email?
No debe plantearse así. Business Central conserva y procesa los datos empresariales, pero la recepción, extracción e interpretación pueden requerir Outlook, Power Automate, servicios documentales, Copilot Studio, Azure u otras capacidades. La solución concreta depende del formato y del nivel de automatización.
¿Puede crearse directamente un pedido definitivo?
Técnicamente pueden automatizarse acciones, pero normalmente conviene comenzar creando borradores. Solo después de medir precisión, excepciones y controles tendría sentido aumentar el procesamiento sin intervención.
¿Funciona si cada cliente utiliza un PDF diferente?
Es posible trabajar con documentos variables, pero la arquitectura y el esfuerzo aumentan. Hay que estudiar la diversidad real, la calidad de los documentos y los datos que deben extraerse. Un piloto con muestras representativas es esencial.
¿Qué sucede cuando el cliente usa sus propias referencias?
Deben mantenerse equivalencias fiables entre referencias del cliente y artículos del ERP. La IA puede proponer coincidencias, pero los casos dudosos necesitan revisión y aprendizaje controlado.
¿Puede comprobar stock y fecha de entrega?
Puede consultar información del ERP y aplicar reglas, pero una fecha fiable puede depender de reservas, compras, producción, almacenes y calendarios. La confirmación debe utilizar la disponibilidad relevante para cada negocio.
¿Es necesario utilizar inteligencia artificial?
No siempre. Para formatos estructurados y reglas estables puede bastar una integración o flujo. La IA es útil cuando hay lenguaje libre, documentos variables, correspondencias complejas o decisiones que requieren contexto.
¿Cómo se evita que se duplique un pedido?
Mediante identificadores del cliente, número de pedido externo, remitente, contenido, fechas y reglas de duplicidad. Si la coincidencia no es concluyente, la operación debe bloquearse para revisión.
¿Qué debería medir el piloto?
Precisión de extracción, porcentaje de pedidos sin intervención, tiempo medio, excepciones, errores evitados, velocidad de confirmación, coste por pedido y aceptación del equipo.
Ayesa Digital, partner Microsoft para conectar proceso, dato, automatización e IA
Automatizar pedidos puede involucrar ERP, CRM, Microsoft 365, Power Platform, Azure, seguridad, integración y operación. Un enfoque end-to-end reduce puntos ciegos y permite diseñar la solución desde el resultado empresarial, no desde una herramienta aislada.
¿Cuántas horas y cuántos errores esconde tu buzón de pedidos?
Podemos revisar una muestra real, identificar patrones y excepciones, estimar el potencial de automatización y definir un piloto conectado con Business Central. Sin promesas vacías: proceso, arquitectura, controles y retorno.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)