MCCO GroupMCCO-2026-GH-002datos ficticios
Garden House · Portafolio de automatización con IA

Cómo funciona
cada proyecto.

Cuatro soluciones sobre un mismo backbone — WhatsApp, IA de bajo costo y los sistemas que Garden House ya usa. Esta presentación muestra el flujo de funcionamiento de cada una: lo que ve el usuario y lo que pasa por detrás.

Un backbone · cuatro soluciones2 productos ya construidos en sus reposNavega con ← → o el índice
MCCO Group00 · El backbone común
La misma base para las cuatro soluciones

Canales conocidos, inteligencia intercambiable,
datos del cliente.

📱 Canales

donde la gente ya está
WhatsApp vía Kapso — API oficial, número propiedad de Garden House (sin lock-in)
Web — portal de contratistas, vista del guardia, tableros
Correo M365 — alertas y flujos existentes

🧠 Inteligencia

agentes especializados, una tarea cada uno
OpenRouter — modelos de IA de bajo costo con lectura/visión; se cambia de modelo en una línea; API key del cliente
Orquestador MCCO — código entregado en el handover; guardrails determinísticos por fuera de la IA
Ante baja confianza no inventa — deriva a revisión humana

🗄 Datos del cliente

en sistemas de Garden House
SharePoint / M365 — repositorio documental y tableros
SQL — bases por proyecto (contratistas, hallazgos SG)
Buk — datos del colaborador, solo lectura (P&C)
La IA ordena, el humano decide
Aprobar permisos y enviar correos externos es de una persona.
Datos ficticios primero
Se construye y prueba con datos falsos; se conecta después.
Minimización por rol
Cada vista expone solo lo necesario. Ley 19.628 / 21.719.
Sin lock-in
Número de WhatsApp, API keys y código quedan en poder de GH.
Handover total
Documentación, capacitación y credenciales entregadas.
MCCO Group01 · Personas y Cultura
Para Fabiola Steffens · P&C

RH en tu bolsillo

producto en construcción · repo propio
El colaborador pregunta por WhatsApp; P&C deja de ser mesa de ayuda.
Cómo funciona · de la pregunta a la respuesta con fuente
💬
Colaborador escribe
al número de WhatsApp de GH (Kapso)
🪪
Identidad RUT + OTP
vínculo 1:1 teléfono↔persona; nadie consulta por otro
🧠
Agentes es-CL
entienden la pregunta y buscan en documentos curados (RAG) + Buk solo lectura
🛡
Guardrails
sin montos por chat, sin datos de terceros, no inventa: sin fuente → escala
Respuesta al instante
con la fuente citada; tono humano (escribiendo…, burbujas)
🙋
Escalamiento
lo sensible o sin respuesta pasa a P&C humano con contexto

Lo que ve el colaborador

  • Responde al tiro, 24/7: beneficios, contrato, reglamento, sindicato.
  • Sus datos (vacaciones, contrato) salen de Buk, verificada su identidad.
  • Cada respuesta dice de dónde salió (documento y sección).

Lo que pasa por detrás

  • Orquestador Node/TypeScript (repo propio, se transfiere en handover).
  • Kapso webhook firmado + OpenRouter (modelo intercambiable por configuración).
  • Panel P&C, simulador de chat offline y 38 tests automatizados.
sin montos por chatsin datos de tercerosfuente citada siempreBuk solo lecturaescalamiento a humanoes-CL
MCCO Group02 · Servicios Generales
Para Camila Arlegui · SSOMA

Bot SG — el hallazgo que se gestiona solo

construido y activo · etapa 1
La ronda semanal de Facilities (4 zonas · 62 puntos, la planilla real) y los reportes del equipo se convierten solos en tareas gestionadas.
Cómo funciona · de la ronda al análisis de causa raíz
🚶
Ronda guiada
el levantador recorre por paradas desde WhatsApp; fecha automática
📸
Foto solo si algo no está OK
lo OK avanza rápido; también acepta reporte espontáneo fuera de ronda
🎯
Hallazgo → tarea
catalogada con criticidad A/B/C y SLA, sin duplicados (dedup)
🗄
Base SQL
rondas e historial en D1; escala si un punto se repite mucho
📣
Aviso al responsable
por zona; estado de gestión consultable por WhatsApp
📊
Excel / Power BI
export CSV mensual → Power Query y análisis de causa raíz

Lo que ve el equipo

  • La ronda completa sin planillas ni papel, desde el teléfono.
  • Cada hallazgo queda con foto, zona, criticidad y quién debe resolverlo.
  • El estado se consulta preguntándole al mismo bot.

Lo que pasa por detrás

  • Workflow sg-asistente en Kapso (workflow-as-code, versionado en su repo).
  • API gh-sg-api + base SQL (D1): hallazgos, SLA, deduplicación, escalamiento.
  • Los CSV alimentan el Excel que el equipo ya usa — no se les cambia la herramienta.
planilla real de Facilities · 62 ptscriticidad A/B/C + SLAdedup + escalamientocanal cerrado del equipoetapa 1: un levantador
MCCO Group03 · Seguridad Contratistas y Permisos
Para Camila Arlegui · SSOMA · usuario clave: Lucio (prevencionista)

Nadie entra con papeles vencidos

arquitectura BD + app operable · construcción con accesos
Base SQL única por RUT con estado calculado en cada consulta (cronicidad 24/7) — reemplaza el Excel de hojas infinitas.
Cómo funciona · del documento al permiso, sin bypass
📤
Contratista carga en la web
el envío se bloquea si falta algo; cada intento queda en historial
🤖
La IA lee cada documento
clasifica, extrae vencimiento, firma sí/no; dudas → en revisión (no inventa)
🗄
Base SQL viva
estados vigente / por vencer / vencido calculados al consultar, 24/7
🛃
Guardia y habilitación
consulta por RUT o empresa; vencido o incompleto = no entra
📋
Kanban + alertas
vencimientos con ~1 mes de aviso; mensaje pre-redactado, lo envía Lucio
📲
Permiso + AST digital
solo autorizable con todos al día; aprueba Lucio desde el teléfono, sin VPN

Lo que ve cada usuario

  • Contratista: qué le falta y qué le vence, y lo sube él mismo (portal).
  • Guardia: HABILITADO / NO HABILITADO gigante, por RUT o lista de empresas.
  • Lucio: kanban por empresa, próximos vencimientos y permisos listos para aprobar.

Lo que pasa por detrás

  • Esquema SQL propuesto: 17 tablas · 5 vistas · 3 roles — en sistemas de Garden.
  • La consulta clave: v_vencimientos → qué vence, de quién, en cuántos días.
  • Dos zonas: la web pública nunca toca la BD directo (pasa por la API interna).
sin bypass ≠ sin humanosin correo automático (fase 1)QR informativo, no abre puertasfirma: presencia sí/noAST digital experimentalbatch fin de semana por RUT
MCCO Group04 · Mantención
Para Byron Jones · Mantención

Pañol digital

en levantamiento
Control de bodega/pañol: inventario, retiro y devolución de herramientas e insumos con trazabilidad.
Cómo funcionará · primera iteración (a validar con Byron)
🧰
Activo registrado
repuestos, herramienta común y filtros críticos, hoy en 3 ubicaciones
📲
Retiro / devolución
app web simple: quién saca qué, para qué OT, cuándo vuelve
🗄
Inventario vivo
stock y trazabilidad por persona y activo
✉️
Notificación por correo
primera iteración sin WhatsApp: validar estructura de datos y UX

Por qué parte así

  • Está en levantamiento: la primera iteración valida datos y flujo, no el canal.
  • Cuando cierre el levantamiento, se suma al portafolio con su demo jugable.
  • Comparte el backbone: mismo patrón de agentes, SQL y handover.

Situación actual

  • Bodega de repuestos e insumos con acceso controlado, sin inventario.
  • Taller de herramienta común sin pañol ni trazabilidad de retiro.
  • Container modular con filtros GMP sin control de acceso.
app web de pruebanotificación por correoestructura de datos primeroWhatsApp en iteración siguiente
MCCO GroupEstado del portafolio
Dónde está cada proyecto hoy

Dos productos construidos, uno listo para partir,
uno en levantamiento.

ProyectoEstadoQué existe hoyQué lo destranca
🧹 Bot SGactivoWorkflow WhatsApp + base SQL + exports a Excel/Power BI · repo bot-sgUso real de la etapa 1 y feedback del equipo
💬 RH en tu bolsilloen construcciónOrquestador completo con identidad, guardrails, panel y simulador · repo rh-en-tu-bolsilloConexión a Buk real y difusión (S5)
🛡️ Seguridad Contratistaslisto para partirArquitectura SQL (17 tablas · 5 vistas) + app operable de 4 vistas · repo mcco-garden-houseAccesos S1: SharePoint/Graph, Kapso, OpenRouter, catálogo R1, nóminas, reunión TI
🧰 Pañol digitallevantamientoDiagnóstico de las 3 ubicacionesCierre del levantamiento con Byron
Datos ficticios · Ley 19.628 / 21.719 · MCCO Group SpA · GH-002
1 / 7 ← → navegar · 1-7 ir directo · F11 pantalla completa