Spec | Facilities Management Colliers (CREMS) — AS-IS v1
colliers crems facilities-management spec
Autor: Pedro Villa Versão: AS-IS v1 (consolidada após discovery 28/04 com Gianlucca Piva) Status: AS-IS validada com owner — TO-BE pendente Empresa: colliers Divisão: CREMS — Colliers Real Estate Management Services Owner Colliers: Gianlucca Piva (Head CREMS) Owner operacional Mele: Ricardo Miranda (Gerente Executivo Mercado Livre — a cadastrar) Prioridade: Alta — definida pelo Ricardo Betancourt como foco da semana 2
Este documento substitui em valor a prep de discovery (histórico). Consolidar achados da 04 em um spec AS-IS, base para spec TO-BE da Onda 1.
1. Definição de produto
Facilities Management é o serviço da Colliers para o ocupante de um imóvel — empresa que aluga ou possui o espaço e contrata a Colliers para manter as áreas privativas funcionando. Cobre serviços que não são core business do cliente: copa, limpeza, manutenção elétrica em conformidade com norma técnica, áreas verdes, AVCB interno, plano de manutenção anual assinado por engenheiro, etc.
Diferença essencial vs Property Management (validada pelo Gianlucca):
| Dimensão | Property Management | Facilities Management |
|---|---|---|
| Cliente | Proprietário | Ocupante |
| Foco | Áreas comuns + administração condominial | Áreas privativas (e além, no caso ML) |
| Mercado | Oceano vermelho — commodity | Oceano azul — custom made |
| Modelo de operação | Padronizável | Por cliente |
| KPI predominante | % atingimento budget | SLAs contratuais (com penalidades) |
| Volumetria de clientes | ~35 | 5–6 |
| Volumetria de pessoas | 50–55 | ~123 (120+ no Mercado Livre) |
Posicionamento de mercado (palavras do Gianlucca): “se você se adapta muito bem, resolve as dores deles com tecnologia e conhecimento específico, propõe soluções que não são encontradas no mercado, esse cliente é fidelizado.”
2. Carteira AS-IS
| Métrica | Valor |
|---|---|
| Clientes ativos | 5–6 |
| Mercado Livre — pessoas Colliers alocadas | 120+ (de 123 da divisão) |
| Crescimento operacional ML | 35 → 123 pessoas; <30 → ~100 operações desde início do contrato |
| Outras contas (não-ML) | Centro de inovação P&D Ilha do Fundão (RJ) — produtos de beleza, 5 estoques, alguns controlados pelo Exército (química regulada) |
Concentração crítica: Mercado Livre representa quase toda a divisão em volume de pessoas. Qualquer arquitetura precisa pensar em Mercado Livre como caso primário e generalizar com cautela.
3. Modelo operacional Mercado Livre — caso primário
3.1 Estrutura organizacional
graph TB A[Mercado Livre — Head Admin] -->|reunião<br/>quinzenal| B["Gerente Executivo Mele<br/>(Ricardo Miranda)<br/>responde direto p/ Gianlucca"] A -.->|reunião<br/>semanal seg 9h| C[Gestão Média ML] C --- D[Lideranças locais Colliers] B --> E["Frente 1<br/>Fretados<br/>(gestão contratos<br/>operadores ônibus)"] B --> F["Frente 2<br/>Restaurantes / Food<br/>(gestão contratos<br/>operadores restauração)"] B --> G["Frente 3<br/>CX (helpdesk 24x7)<br/>chatbot WhatsApp +<br/>atendimento humano"] H["Estrutura adjacente:<br/>Analytics & Qualidade"] -.- E H -.- F H -.- G
| Frente | Escopo |
|---|---|
| Fretados | Gestão dos contratos com operadores de ônibus que transportam colaboradores ML para os centros de distribuição. Onboarding (1º dia: ônibus garantido). Telemetria nos veículos onde existe (SP/Cajamar). Penalidades por SLAs definidas no contrato pós-ADT. |
| Food / Restaurantes | Gestão dos contratos com operadores de restauração nos sites ML. Garante refeição adequada (alguns colaboradores fazem só uma refeição/dia — restauração é estratégica para produtividade). |
| CX (Customer Experience / Helpdesk) | 24x7, primeiro contato via chatbot WhatsApp com script estruturado. Humano só se chatbot não resolve. Funções: orientação onboarding, problemas com fretado, com refeição, escalação. |
| Analytics & Qualidade (adjacente) | Estrutura técnica que garante qualidade e ingestão dos dados, BI, automação de relatórios. Camada técnica crítica que Anouk precisa conhecer a fundo via Ricardo Miranda. |
3.2 Caso especial — vouchers Uber para colaboradores novos
Antes de o colaborador ser encaixado na rota de fretamento, ele recebe 2 dias de Uber.
flowchart LR A[Mercado Livre<br/>fornece planilha<br/>colaboradores novos] --> B[Sistema Colliers<br/>transforma planilha<br/>em vouchers Uber] B --> C[Voucher entregue<br/>para cada colaborador] C --> D[Após 2 dias<br/>colaborador entra<br/>em rota fretamento]
Sistema já em produção — exemplo concreto de automação custom-made fidelizando o cliente.
3.3 Telemetria fretados
| Local | Estado |
|---|---|
| SP / Cajamar | Sensor em todos os ônibus → telemetria em nuvem → indicadores em tempo real |
| Interior de Santa Catarina | ”Os ônibus às vezes nem chegam ao local de trabalho porque eles quebram antes” — controle manual em prancheta/planilha |
Há heterogeneidade técnica que vai persistir — Anouk precisa pensar em pipeline que lide com fontes de qualidade desigual.
4. Casos não-ML
4.1 Centro de inovação P&D Ilha do Fundão (RJ)
- Cliente recebe materiais para protótipos de produtos de beleza
- Alguns insumos químicos controlados pelo Exército dependendo da composição
- 5 estoques sob administração Colliers
- Foco operacional: gestão dos estoques + conformidade legal
4.2 Outras contas (4–5 clientes)
- Não detalhados em profundidade nesta sessão
- Cada qual com gerente regional próprio
- Liturgia padrão: HOP mensal + visitas quinzenais (varia por cliente)
5. Stack tecnológico AS-IS
5.1 Visão de sistemas (Mercado Livre)
flowchart TB subgraph PROD ["Em produção (ativos digitais existentes)"] CB[Chatbot WhatsApp CX<br/>script estruturado · histórico extraível] VU[Sistema Voucher Uber<br/>planilha ML → vouchers] TEL[Telemetria fretados<br/>SP/Cajamar · nuvem] end subgraph CONSTR ["Em construção"] BI["BI Report Heads<br/>(equipe Analytics ML)"] end subgraph MANUAL ["Ainda manual / heterogêneo"] PRANCH[Prancheta / planilha<br/>SC interior · fretados] RH_MAN[Atualização semanal<br/>Report Heads pré-BI] SUMEX[Sumex semanal<br/>bullet point manuscrito] end subgraph EXT ["Externo"] WPP[WhatsApp] EMAIL[E-mail] FORN[~Fornecedores<br/>(99% das informações)] end CB <--> WPP SUMEX --> WPP SUMEX --> EMAIL FORN -.->|dados manuais ou via planilha| RH_MAN FORN -.->|dados telemetria| TEL PRANCH -.->|dados manuais| RH_MAN RH_MAN --> BI TEL --> BI
5.2 Detalhamento
| Sistema | Status | Notas |
|---|---|---|
| Chatbot WhatsApp CX | Em produção | Primeiro contato; humano apenas se script não resolve. Histórico extraível — fonte rica para análise de demanda/qualidade. |
| Sistema voucher Uber | Em produção | Conversão automatizada planilha ML → vouchers. Já é um agente em operação. |
| Telemetria fretados | Em produção em SP/Cajamar | Sensor → nuvem → KPIs tempo real. Não cobre interior SC — aí ainda manuscrito. |
| BI Report Heads | Em construção pelo Analytics ML | Automação do relatório semanal de SLAs (~2.400 informações/semana — ver §6.1). |
| Sumex (sumário executivo) | Manual | Lista bullet point, semanal sextas, via WhatsApp/e-mail. Candidato direto a automação. |
6. Reportes ao cliente AS-IS
6.1 Report Heads (Mercado Livre — semanal)
| Item | Valor |
|---|---|
| Frequência | Semanal |
| Estrutura | 2 slides por operação (fretados + restaurantes) |
| Densidade | 8–16 indicadores por slide |
| Operações cobertas | ~100 |
| Volume total | ~200 slides × ~12 indicadores = ~2.400 informações/semana |
| Estado | Foi dor por meses; em automação via BI pelo Analytics ML |
| Observação | Cliente questiona não só atingimento, mas confiabilidade dos dados (“será que isso é real?“) |
6.2 Sumex (Sumário Executivo) — semanal
| Item | Valor |
|---|---|
| Frequência | Semanal (sextas) |
| Estrutura | Lista bullet point, escrita linha a linha — descrição do que aconteceu na semana no empreendimento |
| Sem fotos / sem narrativa | Apenas log textual |
| Canal | WhatsApp + e-mail |
| Audiência | Cliente acompanha em viagem etc. |
| Estado | Manual |
| Visão Gianlucca | ”Atividade que poderia ser automatizada” — verbatim |
6.3 HOP (Relatório de Operações) — mensal
- Mesmo formato do PM (relatório fotográfico antes/depois, indicadores operacionais)
- Aplicável a contas FM não-ML
- Apresentado pelo gerente regional + gerente local
- Hoje montado manualmente
6.4 Liturgia de reuniões com cliente
| Cliente | Cadência | Participantes Colliers | Participantes cliente | Pauta |
|---|---|---|---|---|
| Mercado Livre | Semanal seg 9h | Lideranças locais | Gestão média (fretados + restaurantes) | Operacional |
| Mercado Livre | Quinzenal | Ricardo Miranda (gerente exec) | Head Admin ML | Apresentação SLA mensal alterna com discussão dia a dia / visão futuro |
| Outros (não-ML) | Variável (quinzenal a mensal) | Gerente regional + gerente local | Cliente | HOP + reclamações + demandas |
7. SLAs e contrato (Mercado Livre)
- Contrato passou por aditivo recente (ADT) que redefiniu SLAs
- Antes: Colliers absorvia penalidades por falhas que não eram dela (problema fornecedor virava problema gestão Colliers)
- Agora: ADT separa gestão Colliers (multável p/ Colliers) vs execução fornecedor (multável p/ fornecedor)
- 99% das informações de SLA vêm de fornecedores (palpite Gianlucca) — qualidade dos dados é o problema-chave
- Não existe ainda dicionário canônico de dados dos SLAs — quando construído, precisará ser continuamente atualizado pela taxa de crescimento ML
8. Pessoas e estrutura
graph TB Ricardo["Ricardo Betancourt<br/>(prioriza CREMS na semana 2)"] --> Gianlucca[Gianlucca Piva<br/>Head CREMS] Gianlucca --> Mele["Ricardo Miranda<br/>Gerente Exec. Mele<br/>(a cadastrar)"] Gianlucca --> Outros[Gerentes regionais<br/>contratos não-ML] Mele --> Fretados[Frente Fretados] Mele --> Food[Frente Food] Mele --> CX[Frente CX 24x7] Mele --> Analytics[Estrutura Analytics<br/>& Qualidade] Outros --> Fundao[Centro P&D<br/>Ilha do Fundão] Outros --> Contratos["Demais contratos FM<br/>(4-5 clientes)"]
Atores externos críticos:
- Operadores de ônibus (fretamento) — fonte de 99% dos dados
- Operadores de restauração — fonte de dados de cumprimento de cardápio/atendimento
- Equipe analytics interna ML que recebe nossa interface técnica
9. Documentos canônicos disponíveis
A coletar via Rafael por e-mail (ação aberta com Gianlucca — cf. T-106):
- Fluxogramas de processos (PM e FM)
- Plano de ação corretivo
- Kit implantação
- Playbook
- Exemplos de Sumex semanal — clientes não-ML
- Exemplos de HOP mensal — clientes não-ML
- Dicionário de SLAs vigentes pós-ADT — estrutura, não dados (com Ricardo Miranda — cf. T-107)
- Estrutura técnica de telemetria fretados — schema, não dados operacionais
⚠ Decisão de escopo (Pedro 28/04): o projeto Anouk NÃO acessará dados do Mercado Livre. Apenas dados internos da Colliers — exemplos canônicos de outros clientes + estruturas técnicas (dicionários, schemas) sem dados operacionais ML. A discovery com Ricardo Miranda foca em entender a estrutura analítica e o dicionário de SLAs, não em consumir dados ML.
Implicação: dados de Report Heads ML, histórico do chatbot CX ML, telemetria operacional ML — todos fora do escopo Anouk. Os ativos digitais ML descritos em §5 e §11 entram como referência de modelo, não como fonte de dados.
10. Dores AS-IS identificadas
| # | Dor | Severidade | Detalhe |
|---|---|---|---|
| D1 | Confiabilidade dos dados dos fornecedores | Crítica | Cliente questiona se dados de SLA são reais — risco reputacional |
| D2 | Report Heads com volume gigantesco (~2.400 infos/semana) | Crítica | Foi dor por meses; em automação mas ainda não-completa |
| D3 | Sumex manual semanal | Alta | Atividade explicitamente endossada como automatizável pelo Gianlucca |
| D4 | HOP montado manualmente (clientes não-ML) | Alta | Mesma dor herdada de Property — falta de padronização |
| D5 | Heterogeneidade técnica entre operações (telemetria SP vs prancheta SC) | Alta | Pipeline precisa lidar com fontes de qualidade desigual |
| D6 | Falta de dicionário canônico de SLAs | Alta | Sem dicionário, indicadores se renomeiam silenciosamente |
| D7 | Tempo real para argumentação em reunião | Crítica | Liderança ML precisa responder “ônibus chegou no horário; atraso veio de outro fato” — hoje é reativo, exige consulta humana |
11. Trabalho em curso (a aproveitar)
| Iniciativa | Owner | Estado | Aproveitar como |
|---|---|---|---|
| BI Report Heads | Analytics ML | Em construção | Acelerar via data lake Bronze/Silver/Gold; avaliar ganho marginal Anouk |
| Telemetria fretados SP | Operadores + Analytics ML | Em produção | Fonte rica para Bronze; modelo a generalizar para SC interior |
| Chatbot WhatsApp CX | Equipe CX | Em produção | Histórico para análise de demanda + treinamento de agentes mais sofisticados |
| Sistema voucher Uber | Equipe FM ML | Em produção | Padrão de automação custom-made bem-sucedida; vitrine |
| ADT SLAs | Gianlucca + ML | Concluído | Base para o dicionário canônico de dados |
12. Hipóteses de IA / automação validadas para Onda 1
Filtro de escopo aplicado: iniciativas que dependem de consumir dados ML estão FORA da Onda 1 (cf. §9). Mantidas apenas como referência arquitetural / aprendizado generalizável.
| # | Iniciativa | Escopo Anouk | Esforço | Impacto | Justificativa |
|---|---|---|---|---|---|
| O1 | Sumex automatizado (data lake Gold → bullet list semanal por empreendimento) — clientes não-ML | ✅ dentro | P | Alto | Endossado verbatim pelo Gianlucca · entrega visível ao cliente · baixo risco |
| O2 | Dicionário canônico de SLAs — estrutura, não dados ML (saída da T-107 com Ricardo Miranda) | ✅ dentro | P | Crítico | Pré-requisito de qualquer agente que consuma SLAs em qualquer cliente FM |
| O3 | Padrão arquitetural Bronze/Silver/Gold documentado a partir do que ML construiu (referência sem dados) | ✅ dentro | M | Alto | Aprendizado generalizável para outros 4-5 contratos FM e para PM |
| O4 | Catálogo unificado de fornecedores (PM + FM + Compras Tatiana) | ✅ dentro | P | Médio | Compartilhado com PM; mesmo trabalho |
| O5 | HOP automatizado para clientes FM não-ML (alinhar com PM) | ✅ dentro | M | Alto | Mesmo trabalho do PM; reuso direto |
| O6 | Pipeline ingestão dados de fornecedores com validação de qualidade — modelo replicável para qualquer cliente FM | ✅ dentro | M | Alto | Resolve D1 generalizada (confiabilidade); aplicável a contas não-ML |
| O7 | ❌ fora | — | — | Fora do escopo — não consumiremos dados ML | |
| O8 | ❌ fora | — | — | Fora do escopo — não consumiremos dados ML | |
| O9 | ❌ fora | — | — | Fora do escopo — trabalho interno ML segue independente | |
| O10 | ❌ fora | — | — | Fora do escopo — não consumiremos dados ML |
13. Lacunas conhecidas (a resolver antes do TO-BE)
- Discovery dedicada com Ricardo Miranda — analytics ML, estrutura técnica, dicionário SLAs
- Receber pacote de exemplos de Report Heads (últimos 6 meses)
- Receber exemplos de Sumex semanal
- Receber estrutura técnica da telemetria fretados (schema, freqüência, fonte)
- Receber lista de SLAs vigentes pós-ADT (com penalidades)
- Receber histórico do chatbot CX (volume, categorização, escalações)
- Mapear contratos não-ML (4–5 clientes) com gerentes regionais — particularidades por cliente
- Aprofundar Centro P&D Ilha do Fundão — gestão de 5 estoques + conformidade Exército
- OK do Mercado Livre para integração ao data lake Colliers (dado considerado confidencial pelo cliente)
14. Próximos passos pós-AS-IS
| # | Passo | Task | Owner | Prazo |
|---|---|---|---|---|
| 1 | Cadastrar Ricardo Miranda + Robson no diretório de pessoas | T-105 | Pedro | 2026-05-02 |
| 2 | E-mail Rafael → Gianlucca + Robson em CC (docs FM clientes não-ML) | T-106 | Rafael | 2026-05-02 |
| 3 | Discovery Ricardo Miranda — Analytics Mele + ADT SLAs (estrutura, não dados) | T-107 | Pedro/Rafael | 2026-05-08 |
| 4 | Spec TO-BE Facilities Management (com priorização O1–O6 + arquitetura proposta para clientes não-ML) | a criar | Pedro | 2 semanas pós-T-107 |
| 5 | Discovery com gerentes regionais (não-ML) | a criar | Rafael | onda-1 |
| 6 | Decisão de quais hipóteses entram em Onda 1 | a criar | Pedro + Igor + Ricardo | pós-blueprint 16/05 |
15. Risco operacional e escopo
- Escopo Anouk × Mercado Livre (decisão Pedro 28/04): o projeto não consumirá dados ML. Dados confidenciais do contrato Mercado Livre seguem fora do escopo. Anouk extrai apenas:
- Estruturas técnicas (dicionário SLAs, schema telemetria) — forma, não conteúdo
- Aprendizados arquiteturais (modelo Bronze/Silver/Gold já implementado)
- Padrões generalizáveis para outros 4–5 clientes FM
- Concentração ML: ~120 das 123 pessoas estão num único contrato. Qualquer ruptura/movimento de SLAs nesse contrato afeta toda a divisão. Risco operacional para Colliers, não risco para o projeto Anouk.
- Heterogeneidade técnica: o que funciona em Cajamar não funciona em SC interior. Soluções precisam ser graceful degradation (onde tem telemetria, usa; onde não tem, fica explícito que dado é manual e baixa confiabilidade). Aplicável a qualquer cliente FM.
- Trabalho interno em curso: Anouk não canibaliza o BI que o Analytics ML já está construindo. Não é mais um risco — é a posição do projeto: ML segue trabalho próprio, Anouk extrai aprendizado e aplica em outros clientes.
16. Ver também
- 04
- Transcrição bruta
- Spec irmã: Property Management AS-IS
- Prep histórico de discovery (substituído por este spec)
- Estrutura Colliers
- AE CREMS
- Gianlucca Piva
- Tatiana Souza — Compras (catálogo unificado)
- 04 — origem da priorização CREMS
Spec consolidado por Pedro Villa em 2026-04-28, a partir de discovery efetuado em 28/04 com Gianlucca Piva. AS-IS validada com owner. TO-BE pendente discovery dedicada com Ricardo Miranda + coleta de documentos canônicos.