Pular para conteúdo

Dashboard Operacional — Live Status do ClickUp

Dashboard read-only que mostra o estado em tempo real das 22 listas do ClickUp que receberam o fluxo de revisão padronizado. Identifica gargalos (revisão parada, cliente lento, tasks órfãs).

Sem cache. Cada request faz snapshot ao vivo na API do ClickUp.

URLs

Endpoint Tipo Uso
/operacional/dashboard?token=… HTML (tema escuro) Abrir no browser pra visualizar
/operacional/status?token=… JSON cru Scripts, análise externa, alertas

Token: DASHBOARD_TOKEN (mesmo do /dashboard financeiro e /grupos-clientes/health).

O que mostra

Cabeçalho

  • Horário do snapshot (BRT)
  • Total de tasks ativas (não-closed) somando todas as 22 listas
  • Distribuição por área: Criação · Tráfego · Backoffice · Sucesso do Cliente

3 painéis de gargalos (no topo, prioridade visual)

Painel Critério Ação esperada
🟠 Revisão interna parada task em status em revisão interna há > STALE_REVISION_DAYS dias (default: 2d) Revisor designado precisa agir ou destravar
🔵 Cliente não responde task em status em aprovação cliente há > STALE_APPROVAL_DAYS dias (default: 3d) Tati / account faz follow-up no grupo
⚠️ Em revisão interna sem Revisor designado task com status em revisão interna E custom field Revisor Interno vazio Atribuir alguém antes de seguir

Cada painel mostra até 15 tasks com link direto pra task no ClickUp, ordenadas das mais antigas pras mais novas.

Grade de cards (1 por lista)

Para cada uma das 22 listas: - Nome da lista (link clicável pra ClickUp) - Total de tasks ativas - Distribuição de tasks por status (barras horizontais coloridas) - Badge amarelo N sem Revisor se houver tasks em revisão sem revisor designado

Listas monitoradas

Hardcoded em LISTS em server/automations/operacional-status.js.

Área Listas (6 + 11 + 5 = 22)
Criação Design · Vídeo · Copy · Planejamento e Estratégia
Tráfego Gestão de Campanhas · Relatórios Tráfego
Backoffice RH / Vagas · Gestão Contratual · R [Financeiro] · Contas a Receber · Contas a Pagar · R [Administrativo] · Time GITA · Onboarding · Cultura e Rituais · Recrutamento e Seleção · R [Direção]
Sucesso do Cliente Gestão de Clientes · NPS · Entrada do novo cliente · R [Pós Venda] · Relatórios de Entregas

Não monitora ainda: Publicação, R [Criação], R [Tráfego e Infra], R [Web], Produção de Páginas, listas de Lançamentos, R [Jurídico] (sem permissão), R [Tecnologia e IA], R [Tech GITA], Sistemas em Desenvolvimento, Manutenção e Suporte, Agentes Claude Code, Automações Internas, Stack e Infraestrutura, listas do folder Lançamento LS, listas do folder Estruturação Inicial - Cliente.

Como ajustar

Mudar thresholds de gargalos

Editar constantes no topo de operacional-status.js:

const STALE_REVISION_DAYS = 2     // tasks em "em revisão interna" há mais de X dias
const STALE_APPROVAL_DAYS = 3     // tasks em "em aprovação cliente" há mais de X dias

Adicionar/remover lista do monitoramento

Editar array LISTS no mesmo arquivo:

const LISTS = [
  { id: '<list_id>', name: '<nome>', area: '<Criação|Tráfego|Backoffice|Sucesso>', color: '<hex>' },
  // ...
]

Cores das áreas (em areaColor()): - Criação: #e9c162 (amarelo) - Tráfego: #3e63dd (azul) - Backoffice: #6647f0 (roxo) - Sucesso: #30a46c (verde)

Mudar lógica de agrupamento de status

A função statusGroup(statusName) classifica nomes de status em buckets normalizados: - revisao_interna — para tasks aguardando revisão humana - aprovacao_cliente — para tasks aguardando cliente responder - alteracao — em alteração & ajuste (loop) - aprovado — concluído / aprovado / finalizada / deu certo - publicado — publicado / agendado - producao — em produção / em andamento / fazendo / em gravação / em edição - aguardando — fallback (não classificado)

Se uma lista usa nomenclatura diferente que não bate com nenhum padrão (ex: "Em aguardo"), basta adicionar a regra correspondente em statusGroup().

Mudar cores das barras de status

Função statusColor(statusName) mapeia substrings de status pra cores. Adicione regras conforme novos statuses aparecerem nas listas.

Como funciona internamente

Pipeline de cada request

GET /operacional/dashboard ou /status
  ↓
buildSnapshot()
  ↓
para cada uma das 22 listas (sequencial):
  fetchListTasks(listId) → GET /api/v2/list/{id}/task
  ↓ resposta tem array de tasks com:
    - status.status (nome do status)
    - date_updated (timestamp ms)
    - custom_fields (array — busca "Revisor Interno")
    - url (link pra task)
  ↓ para cada task:
    statusGroup(status) → bucket
    daysAgo(date_updated) → idade do status atual
    if revisao_interna & idade > 2 → adiciona em gargalos.revisao_parada
    if aprovacao_cliente & idade > 3 → adiciona em gargalos.cliente_lento
    if revisao_interna & sem revisor → adiciona em gargalos.orfas_sem_revisor
  ↓
ordena gargalos por idade decrescente
  ↓
retorna JSON (status) ou renderHtml(snapshot) (dashboard)

Por que sequencial e não paralelo

22 listas × ~5ms cada = ~110ms — performance OK. Paralelizar daria <50ms mas pode hitar rate limit do ClickUp (100 req/min em token pessoal). Se virar gargalo no futuro: usar Promise.all com semáforo de 5.

Sem cache

Cada request faz 22 chamadas ao ClickUp. Se virar lento (>3s), opções: 1. Cache de 60-120s in-memory (suficiente pra dashboard) 2. Pré-calcular via cron a cada N min e servir do Supabase

Env vars necessárias

Já configuradas no Easypanel apiclickup (não precisa adicionar nada novo):

Var Função
CLICKUP_TOKEN Token de acesso ClickUp REST API (Personal Token)
DASHBOARD_TOKEN Auth do dashboard (query string ?token=…)

Limitações conhecidas

  • Não rastreia tasks fechadas (include_closed=false na query) — só ativas. Tasks "Aprovado" / "Publicado" geralmente são closed e somem do dashboard. Pode ser intencional (foco em fluxo ativo) ou ajustar conforme necessidade.
  • date_updated reflete a última modificação da task, não a mudança de status específica — tasks com edições recentes podem aparecer "fresh" mesmo estando no mesmo status há dias. Pra precisão, ClickUp tem endpoint /task/{id}/history mas é 1 request a mais por task (não escala).
  • Custom field Revisor Interno lê só primeira pessoa do array (single_user: true na config do field).
  • Listas com 0 tasks aparecem como cards com "(sem tasks ativas)" — bom pra ver cobertura, mas polui visual. Pode ser ocultado por flag se virar problema.

Próximas evoluções possíveis

  • Alertas Slack/WhatsApp quando gargalo crescer (cron 8h-20h)
  • Histórico — salvar snapshot diário em Supabase pra ver tendência
  • Filtros na UI — por área, por cliente (custom field Empresa), por revisor
  • Drill-down por lista — clicar numa lista abre detalhe com lista de tasks
  • Métricas por cliente — tempo médio de revisão interna por cliente
  • Indicador de saúde do cliente — clientes com tasks em aprovação >5d podem indicar problema de relacionamento

Arquivos no código

Ver também