Restaurant Performance Score Engine: ranking operacional de lojas

Visão geral

Produto de analytics que produz um índice de performance por loja (ex.: 0–100), combinando métricas operacionais já deriváveis do pipeline delivery. Objetivo: comparar lojas com justiça (mesma régua) e apoiar gestão de rede, franquias ou consultoria.

Problema

• Indicadores isolados geram debate (“minha loja cancela menos mas atrasa mais”).
• Falta um composite score com pesos explícitos e auditáveis.
• Redes precisam de ranking estável e explicável para ação (treinamento, meta, bônus).

Métricas componentes (exemplo)

Dimensão	Exemplos	Observação
SLA	% pedidos dentro do tempo contratual	Pode variar por modalidade
Cancelamento	Taxa e, em peso maior, cancel pós-preparo	Alinha com perda
Preparo	Tempo médio e variância	Detecta caos de cozinha
Turno	Desvio entre turnos na mesma loja	Evita média que esconde pico

Pesos são configuração de produto, não segredo técnico — devem ser versionados.

Output

• Score final por loja e por período (semana/mês).
• Decomposição: contribuição de cada eixo para o score (tipo Shap simplificado ou “pontos perdidos por métrica”).
• Opcional: percentil na rede (“top 20%”).

Monetização (hipóteses)

• Consultoria para redes: implementação + calibração de pesos.
• Licença para franqueadoras (dashboard + API de scores).
• Auditoria de performance em due diligence de expansão.

Implementação técnica

1. Camada Gold com métricas semanais por store_id.
2. Normalização (min-max ou z-score por rede) para comparabilidade.
3. Função score = f(métricas, pesos_v) com v versionado.
4. Testes unitários nos pesos e em cenários-sintéticos (“loja péssima em SLA” → score baixo).

MVP

• Score com 4 componentes, pesos fixos em YAML.
• Uma página Streamlit: tabela ranqueada + drill-down em uma loja.
• Export CSV para gestores.

Riscos

• Score vira arma política se pesos não forem negociados com stakeholders.
• Gaming: lojas podem distorcer timestamps — reforço com auditoria de sequência de eventos.

Ligação com o projeto atual

Reutiliza dim_store, tempos de etapa em fact_orders e pode consumir saída do motor de auditoria como penalidades explícitas no score.