Ticket vs Projeto: Como Definir o Escopo Correto

Suporte recebe ticket:

“Preciso de integração com Slack.”

Agente pensa:

É um ticket?
É um projeto?
Vira roadmap de produto?

Responda errado, você:

Aceita um projeto de 3 semanas como “ticket” → agente sobrecarregado
Nega um ticket simples com “isso é projeto” → cliente irritado
Mistura tudo → caos

Framework: Diferencie. Com 3 perguntas.

As 3 Perguntas

1. Quanto Tempo?

TICKET (< 8h de trabalho):
├─ Dúvida de uso: "Como configurar notificação?"
├─ Bug simples: "Login não funciona no Firefox"
├─ Integração pronta: "Adicione Slack ao suporte"
└─ Resposta: Agente resolve sozinho

PROJETO (> 8h):
├─ Integração customizada: "Integrar com sistema legado X"
├─ Desenvolvimento: "Nova feature no portal"
├─ Consultoria: "Redesenhar fluxo de suporte"
└─ Resposta: Time + PM + roadmap

2. Quantos Recursos?

TICKET (1 recurso):
├─ Agente de suporte
├─ Sem dependências
└─ Funciona em isolamento

PROJETO (3+ recursos):
├─ Dev backend
├─ Dev frontend
├─ PM / Product owner
├─ Tester
├─ Documentação
└─ Coordenação necessária

3. Quanto Impacto?

TICKET (Impacto 1 cliente ou < 10 clientes):
├─ Solução específica para A
├─ Não afeta arquitetura geral
└─ Revertível fácil

PROJETO (Impacto > 10 clientes ou mudança arquitetural):
├─ Feature que beneficia múltiplos
├─ Muda fluxo geral
├─ Difícil de reverter
└─ Precisa testes, docs, roadmap

Framework Visual: Matriz Ticket × Projeto

         TEMPO
         ↑
    8h   | PROJETO
         | ░░░░░░░
         | ░ D1 ░░
    2h   |░ T1 ░░
         |TICKET
    ─────┴──────────────→ COMPLEXIDADE
         1   3   5   10

Mapeamento:

T1 (Tempo 2h, Complexidade 1): Ticket clássico
D1 (Tempo 8h, Complexidade 5): Projeto clássico

Decisão:

Se tempo < 4h E complexidade < 3 → TICKET
Se tempo > 8h OU complexidade > 5 → PROJETO
Entre 4h-8h: Depende de impacto

Exemplo: Integração com Slack

Cenário A: “Integre Slack em 1h”

Cliente: “Quero receber notificações de ticket crítico no Slack.”

Análise:

Tempo estimado: 1h (usar Zapier, API webhook simples)
Complexidade: 1 (integração template)
Recursos: 1 (agente)
Impacto: 1 cliente

RESULTADO: TICKET

Ação:

Agente configura Zapier (templates prontos)
Cliente notificado em 2h
Ticket fechado

Cenário B: “Slack customizado com 10 integrações”

Cliente: “Quero Slack integrado com TUDO: tickets, CRM, automação, analytics com dashboard customizado.”

Análise:

Tempo estimado: 40h (dev, testes, docs)
Complexidade: 8 (custom SDK, webhooks, polling, retry logic)
Recursos: 4 (Dev, PM, Tester, Docs)
Impacto: Sistema inteiro, múltiplos clientes depois

RESULTADO: PROJETO

Ação:

PM escreve especificação
Dev estima (2 sprints)
Entra em roadmap
Cliente entra em waitlist

Tabela de Decisão Rápida

Característica	TICKET	PROJETO
Tempo	< 8h	> 8h
Recursos	1 agente	3+ pessoas
Impacto	1 cliente	Múltiplos / Architecture
Testes	Simples	Completo
Documentação	Não	Sim
Aprovação	Agente	PM + Exec
Timeline	Horas/dias	Semanas
Reversível	Fácil	Difícil
SLA	Sim	Não (roadmap)

Erros Comuns

❌ “Vou aceitar como ticket, depois vira projeto”
→ Agente se perde. Cliente frustrado. Deliverable atrasado.

❌ “Cada pedido é projeto, custa R$ 50k”
→ Perdem vendas. Cliente grita “é só integração!”

❌ “Projeto tem SLA de 2h”
→ Impossível. Projeto = “best effort”, sem SLA.

✅ “Ticket < 8h, projeto ≥ 8h”
→ Simples, objetivo.

✅ “Quando vira projeto, mudo para PM”
→ Suporte entrega rápido, PM cuida do complexo.

Processo: De Ticket Para Projeto

SEMANA 1:
├─ Ticket chega
├─ Agente analisa: "Será projeto?"
├─ Simples? Resolve como ticket (< 8h)
└─ Complexo? Avança para Projeto

SEMANA 2:
├─ PM qualifica
├─ PM estima escopo (40h? 80h? 160h?)
├─ Entra em roadmap
├─ Cliente notificado: "Roadmap Q3"

SEMANA 3+:
├─ PM planeja sprint
├─ Dev começa
├─ Testes em paralelo
└─ Entrega com docs

CTA

Seu time está confuso ticket vs projeto?

O Lucy oferece classificação automática (tempo + complexidade + impacto), rota inteligente (ticket → agente, projeto → PM), e workflow específico para cada.

Classificação inteligente com Lucy →