Discovery: Catálogo de Serviços & Modelo UST — MIDDAG Account

Scope: Product discovery — modelo de precificação UST, catálogo de serviços, níveis de complexidade, tiers de plano, mapeamento para domínios Service/ServiceRequest Context: A MIDDAG Services utiliza um modelo UST (Unidade de Serviço Técnico) para trabalhos de projeto. Serviços catalogados com 3 níveis de complexidade. O plugin deve tornar isso mensurável, rastreável e automatizável. A equipe é mínima — a padronização do catálogo reduz escalonamentos do tipo "pergunte ao Michael".

Nota: Plugin domain mapping → ver docs/adrs/ADR-501.md e REFs. Jira integration → ver docs/adrs/ref/REF-901-03.md.

1. O Modelo UST

1.1 O Que É uma UST?

UST = Unidade de Serviço Técnico. Uma unidade padronizada de trabalho utilizada em todos os engajamentos de projeto da MIDDAG Services.

Terminologia: UST é o nome interno (código, banco, docs técnicos). Para o cliente, o termo é crédito (PT) / credit (EN) — universal, padrão da indústria. Crédito é sempre inteiro (sem frações). 1 crédito = $10 USD = R$70 BRL. Consumo segue FIFO (mais antigo primeiro). Regras de expiração, rollover e carência configuráveis via CreditPolicy — ver ../adrs/ref/REF-501-03.md (CreditBalance & CreditPolicy) e ../adrs/ref/REF-202-04.md (Policy Engine).

Mínimo por SR:

Tier 4 (projetos): mínimo 10 créditos por service request (R$700)
Tier 2 (suporte): mínimo segue o valor do catálogo por tipo de serviço

O crédito é uma unidade abstrata de entrega — não representa horas humanas. Um serviço de 5 créditos pode levar 30 minutos ou 3 horas dependendo da complexidade real. O catálogo define créditos por tipo de serviço com base no custo fully-loaded de entrega (role, duração, formato) mais margem operacional.

O valor base do crédito é configurável no admin do plugin — não consta na documentação.

O insight principal: em vez de cotar horas (que variam por pessoa, humor e complexidade), a MIDDAG cota créditos de entrega. Uma "Atualização de Plugin" sempre custa 4 créditos, independentemente de levar 3 ou 6 horas para o Michael. Isso protege o cliente contra ineficiência e protege a MIDDAG contra subestimativa de escopo.

1.2 Roles & Touch Level

Cada serviço é definido por quem executa (role), formato de entrega e nível de toque:

Role	Descrição	Exemplos de serviço
Junior/Ops	Suporte operacional, tarefas definidas	#1 Suporte Operacional
Specialist	Execução técnica, configuração avançada	#2 Serviço Básico, #8 Customização Visual
Senior Specialist	Investigação, desenvolvimento, infra	#3-#7, #12 Integração API
Principal	Arquitetura, requisitos, estratégia	#9-#11, #13 Dev Plugin

Touch Level	Descrição	Interações típicas
Low	Execute and report	1 interação
Medium	Análise + execução	2-3 interações
High	Múltiplas iterações, aprovações	4+ interações
Very High	Projeto completo	Contínuo

1.3 Por Que Isso Importa para o Plugin

O plugin deve:

Armazenar o valor base da UST como configuração editável (pode mudar ao longo do tempo).
Aplicar multiplicadores de complexidade no nível do ServiceRequest.
Calcular valores de referência dinamicamente: USTs x complexity_factor x base_value.
Rastrear taxas históricas — quando um ServiceRequest foi criado com determinado valor base, ele é cobrado nessa taxa mesmo se o valor base mudar depois.

2. Catálogo de Serviços

2.1 Tabela Completa do Catálogo

CEO Review 2026-04-29: Catálogo recalibrado com custo fully-loaded 3x. Créditos inteiros, sem frações, sem multiplicador de complexidade. Valores antigos subprecificavam em 10-15x.

#	Serviço	Role	Touch	Duração	Créditos	R$ (×R$70)	Requer Análise
1	Suporte Técnico Operacional	Junior	Low	0.5-1h	5	R$350	Não
2	Serviço Operacional (Básico)	Specialist	Low	1-2h	10	R$700	Não
3	Suporte Técnico Especializado	Senior	Medium	1-3h	20	R$1.400	Não
4	Serviço Operacional (Avançado)	Senior	Medium	3-6h	35	R$2.450	Sim
5	Atualização e Manutenção de Plugin	Senior	Medium	4-8h	45	R$3.150	Sim
6	Otimização de Performance de Plugin	Senior+Pri	Medium	4-10h	50	R$3.500	Sim
7	Evolução Funcional de Plugin	Senior	High	8-16h	65	R$4.550	Sim
8	Customização Visual	Spec+Sen	High	16-24h	90	R$6.300	Sim
9	Especificação Técnica	Pri+Sen	Medium	6-12h	65	R$4.550	Não
10	Análise de Requisitos	Principal	High	8-16h	90	R$6.300	Sim
11	Análise de Impacto	Pri+Sen	High	10-20h	110	R$7.700	Sim
12	Integração de API	Senior	High	20-40h	160	R$11.200	Sim
13	Desenvolvimento de Plugin	Sen+Pri	V.High	80-160h	500	R$35.000	Sim

Nota: Catálogo é um documento vivo — serviços podem ser adicionados ou desativados conforme evolução do negócio. Valor de referência = créditos × valor_base_crédito — calculado dinamicamente pelo plugin. Créditos já incluem o custo fully-loaded por role e margem operacional de 40%.

2.2 Observações do Catálogo

Low Touch (#1-#2) — Junior/Specialist:

Sem necessidade de análise. São os itens "simplesmente faça".
Menores valores de crédito (5-10 cr).
Alvo de automação: solicitação self-service do cliente sem aprovação necessária se dentro do orçamento pré-aprovado.

Medium Touch (#3-#6, #9) — Senior/Principal:

Serviços avançados (#4 em diante) requerem análise detalhada antes da execução.
Especificação Técnica (#9) NÃO requer análise — ela É a análise.
Tier mais comum — cobre suporte especializado, manutenção, otimização.
Faixa: 20-65 créditos (R$1.400-R$4.550).

High/Very High Touch (#7-#8, #10-#13) — Senior + Principal:

Trabalho em nível de arquitetura ou projeto. Todos exceto Especificação requerem análise prévia.
Desenvolvimento de Plugin (#13) é o maior item unitário (500 créditos / R$35.000).
Faixa: 65-500 créditos (R$4.550-R$35.000).

2.3 Cálculo do Valor de Referência

Valor de referência = créditos × valor_base_crédito

O multiplicador de complexidade foi eliminado. Os créditos por serviço já incorporam o custo por role e nível de complexidade.

Suporte Operacional:      5 × R$70 =  R$350
Manutenção de Plugin:    45 × R$70 =  R$3.150
Desenvolvimento Plugin: 500 × R$70 = R$35.000

2.4 Service Cards (Definição Detalhada)

CEO Review 2026-04-29: Cada serviço definido por Quem faz × Formato × Duração × I/O × Touch Level. Créditos derivados do custo fully-loaded por role + margem 40%.

#1 — Suporte Técnico Operacional (5 cr / R$350)

Quem: Junior/Specialist
Formato: Async (ticket) ou sync (call 15-30min)
Duração: 30min-1h
Input: Ticket com descrição do problema
Output: Problema resolvido + ticket fechado
Touch: Low (1 interação)
Exemplos: Reset senha admin, config de plugin, erro básico

#2 — Serviço Operacional Básico (10 cr / R$700)

Quem: Specialist
Formato: Execução de tarefa definida
Duração: 1-2h
Input: Instrução clara do que executar
Output: Tarefa executada + confirmação
Touch: Low (execute and report)
Pré-req: Acesso ao ambiente
Exemplos: Backup manual, atualização menor, config avançada

#3 — Suporte Técnico Especializado (20 cr / R$1.400)

Quem: Senior Specialist
Formato: Ticket + investigação + call se necessário
Duração: 1-3h
Input: Problema que Junior não resolveu, ou complexo desde início
Output: Root cause + resolução + documentação
Touch: Medium (2-3 interações)
Pré-req: Acesso ao ambiente + logs
Exemplos: Performance issue, conflito de plugins, erro de BD

#4 — Serviço Operacional Avançado (35 cr / R$2.450)

Quem: Senior Specialist
Formato: Execução com análise prévia
Duração: 3-6h
Input: Descrição do problema + análise aprovada
Output: Implementação + testes + documentação
Touch: Medium-High (requer análise + aprovação)
Pré-req: Análise aprovada (pode ser SR separada)
Exemplos: Migração de dados, reestruturação de cursos, batch operations

#5 — Atualização e Manutenção de Plugin (45 cr / R$3.150)

Quem: Senior Specialist (dev)
Formato: Execução planejada (staging → aprovação → produção)
Duração: 4-8h
Input: Plugin + versão target + ambiente staging
Output: Plugin atualizado + testes + deploy em produção
Touch: Medium
Pré-req: Ambiente staging, backup recente
Exemplos: Moodle 4.3→4.5, plugin major version update

#6 — Otimização de Performance de Plugin (50 cr / R$3.500)

Quem: Senior Specialist + Principal (review)
Formato: Análise + implementação
Duração: 4-10h
Input: Relatório de performance ou queixa específica
Output: Otimizações implementadas + métricas before/after
Touch: Medium-High
Pré-req: Acesso completo ao ambiente + métricas baseline
Exemplos: Query slow, caching, código custom ineficiente

#7 — Evolução Funcional de Plugin (65 cr / R$4.550)

Quem: Senior Specialist (dev)
Formato: Spec → dev → test → deploy
Duração: 8-16h
Input: Requisito funcional aprovado
Output: Feature implementada + testes + documentação
Touch: High (múltiplas iterações)
Pré-req: Análise de requisitos aprovada (#10)
Exemplos: Novo campo no formulário, integração simples, workflow novo

#8 — Customização Visual (90 cr / R$6.300)

Quem: Specialist (front) + Senior (review)
Formato: Design → implementação → revisão
Duração: 16-24h
Input: Briefing visual + brand guidelines
Output: Theme customizado + assets + documentação
Touch: High (design iterations)
Pré-req: Brand guidelines, aprovação de mockup
Exemplos: Custom Moodle theme, landing page LMS, portal branded

#9 — Especificação Técnica (65 cr / R$4.550)

Quem: Principal + Senior
Formato: Análise → documento técnico
Duração: 6-12h
Input: Requisito de negócio ou problema técnico
Output: Documento de especificação técnica completo
Touch: Medium (1-2 reuniões + async)
Pré-req: Escopo definido
Exemplos: Spec de integração, arquitetura de migração, design de API

#10 — Análise de Requisitos (90 cr / R$6.300)

Quem: Principal
Formato: Reuniões + análise + documento
Duração: 8-16h
Input: Necessidade de negócio do cliente
Output: Documento de requisitos + estimativa de esforço
Touch: High (múltiplas reuniões com stakeholders)
Pré-req: Stakeholder disponível
Exemplos: Levantamento para novo projeto, redefinição de escopo

#11 — Análise de Impacto (110 cr / R$7.700)

Quem: Principal + Senior
Formato: Investigação técnica + documento de riscos
Duração: 10-20h
Input: Proposta de mudança (migração, upgrade, refactor)
Output: Documento de impacto + riscos + rollback plan
Touch: High
Pré-req: Acesso ao código + ambiente + documentação existente
Exemplos: Impacto migração Moodle 3→4, troca de hosting, refatoração

#12 — Integração de API (160 cr / R$11.200)

Quem: Senior Specialist (dev)
Formato: Spec → dev → testes → deploy → documentação
Duração: 20-40h
Input: Spec de integração aprovada (#9) + credenciais API
Output: Integração funcional + testes + documentação
Touch: High (múltiplas iterações + debugging)
Pré-req: Especificação técnica aprovada
Exemplos: Stripe, HubSpot, SSO SAML, API customizada, webhook

#13 — Desenvolvimento de Plugin (500 cr / R$35.000)

Quem: Senior + Principal (arquitetura)
Formato: Arquitetura → dev → code review → QA → deploy
Duração: 80-160h
Input: Documento de requisitos completo (#10)
Output: Plugin funcional + testes + documentação + suporte pós-entrega
Touch: Very High (projeto completo)
Pré-req: Análise de requisitos aprovada + contrato
Exemplos: Plugin Moodle novo, extensão complexa, módulo custom

3. Estrutura de Precificação de Projetos

3.1 Custos Fixos

Custo	Recorrência	Descrição
Taxa de Adesão	Única	Onboarding + setup de ferramenta de gestão de projeto (workspace Jira, etc.)
Mensalidade Base	Mensal	Disponibilidade + reunião periódica + faturamento de créditos consumidos

Valores configuráveis no admin. Não constam na documentação.

3.2 Custos Variáveis

Os custos variáveis são puro consumo de UST:

Monthly variable = SUM( completed_SRs x USTs x complexity_factor x base_value )

3.3 Fatura Mensal Total

Total = Mensalidade Base + Consumo Variável de Créditos
      = base + SUM( SR_i.ust_actual × SR_i.complexity_factor × valor_base_credito )

Exemplo de estrutura mensal:

Mensalidade base:                                (fixo mensal)
SR-20260401: Serviço Operacional (Básico)         1 crédito  × 1.0
SR-20260402: Atualização e Manutenção de Plugin   4 créditos × 1.5
SR-20260403: Integração de API                   10 créditos × 2.0
─────────────────────────────────────────────────────────
TOTAL = base + (15 créditos consumidos × fator × valor base)

4. Fluxo da Ordem de Serviço (OS)

4.1 Diagrama Completo do Fluxo

Cliente/MIDDAG registra OS no JIRA
    │
    ▼
MIDDAG triagem: validar, determinar complexidade
    │
    ├── USTs pré-aprovadas E adequadas? ──────────► Execução Direta
    │                                                    │
    │                                                    ▼
    │                                              Executar + faturar
    │
    ├── USTs divergem? ──────────► Solicitação de Aprovação de Execução
    │                             (nova proposta de UST + cronograma)
    │                                    │
    │                                    ├── Aprovado ──► Executar + faturar
    │                                    │
    │                                    └── Rejeitado ──► OS encerrada
    │
    └── Serviço avançado? ──────► Aprovação de Análise Detalhada
                                  (Espec. Técnica / Requisitos / Impacto)
                                         │
                                         ├── Cliente aprova análise
                                         │        │
                                         │        ▼
                                         │   Executar análise
                                         │        │
                                         │        ▼
                                         │   Análise concluída ──► Aprovação de Execução
                                         │                               │
                                         │                    ┌──────────┴──────────┐
                                         │                    │                     │
                                         │                Aprovado              Rejeitado
                                         │                    │                     │
                                         │                    ▼                     ▼
                                         │          Faturar análise +       Faturar SOMENTE análise
                                         │          execução
                                         │
                                         └── Cliente rejeita ──► OS encerrada

4.2 Regras de Negócio Principais

USTs pré-aprovadas: Cada projeto (Service/Entitlement) pode ter um orçamento mensal de UST pré-aprovado. Se a OS couber nesse orçamento, a execução inicia imediatamente.
Divergência de UST: Quando as USTs estimadas excedem o que foi pré-aprovado ou esperado, uma etapa explícita de aprovação é necessária antes de qualquer trabalho começar.
Análise detalhada é faturada independentemente: Se um cliente aprova uma fase de análise mas rejeita a execução subsequente, a análise ainda é faturada. Isso é crítico — o plugin deve suportar faturamento de uma SR de análise separadamente da sua SR de execução pai.
Encerramento de OS sem faturamento: Se o cliente rejeita antes de qualquer trabalho começar, a OS é encerrada com faturamento zero.

4.3 Fluxo de Status do ServiceRequest

                                  ┌──── rejected ────► CLOSED
                                  │
DRAFT ──► PENDING_APPROVAL ──► APPROVED ──► IN_PROGRESS ──► COMPLETED ──► BILLED
                                                │
                                                └──── blocked ────► ON_HOLD

6. Planos de Assinatura (Não-UST)

6.1 Visão Geral

Nem tudo é baseado em créditos. A MIDDAG também vende planos de assinatura com precificação mensal fixa. Estes mapeiam para Entitlements com classes ENV ou ORD.

Planos de serviço estão sendo redefinidos. A nomenclatura genérica BASIC/PLUS/PREMIUM foi deprecada. Novos planos serão definidos em docs/commerce/services/.

6.2 Categorias de Plano

Categoria de Serviço	Classe Entitlement	Status
Hospedagem Gerenciada	ENV	A redefinir
Suporte Técnico	ORD (suporte)	A redefinir
Gestão de Infraestr.	ENV	A redefinir
Gestão de Ambiente	ENV	A redefinir

Valores de planos são configuráveis no admin. Desconto para compromisso anual é configurável por produto.

6.3 Plano vs Créditos: Como Coexistem

Organization: Acme Corp
│
├── Entitlement ENV-2026040001 (Hospedagem Gerenciada)
│   ├── Assinatura: mensal fixa (WC Subscription)
│   ├── Ambiente: production.acme.com
│   └── ServiceRequests: tickets de suporte (não-UST, inclusos no plano)
│
└── Entitlement SVC-2026040001 (Projeto Services)
    ├── Adesão: taxa única
    ├── Mensalidade base: fixa
    ├── Service: "Redesign Portal Acme"
    └── ServiceRequests: itens de trabalho baseados em créditos

7. Taxas Horárias (Fora do UST)

7.1 Tabela de Taxas

Função	Modelo	Observações
Hora Técnica	In-plan < avulso	Suporte básico e trabalho operacional
Hora Especialista	In-plan < avulso	Habilidades especializadas (segurança, perf.)
Hora Consultoria	In-plan < avulso	Arquitetura, estratégia, consultoria

Valores por função configuráveis no admin. Clientes com entitlement ativo (in-plan) pagam taxa reduzida; avulso sempre mais caro.

7.2 Quando as Taxas Horárias se Aplicam

In-plan: Cliente possui um entitlement ativo de suporte/hospedagem. Taxa com desconto.
Avulso: Sem entitlement ativo. Taxa integral aplicada.
Serviços UST 1 e 3 (Suporte Técnico Operacional e Especializado) são cobrados por hora mas utilizam precificação UST, não a tabela de taxas horárias. A tabela de taxas horárias é para trabalho ad-hoc, fora do catálogo.

7.3 Implicação para o Plugin

O plugin deve distinguir entre:

Cobrança baseada em UST (ServiceRequest com tipo de serviço do catálogo)
Cobrança por hora (ServiceRequest com billing_mode: hourly, taxa consultada por função + status do entitlement)
Cobrança por assinatura (Entitlement com mensalidade fixa, gerenciado via WooCommerce Subscriptions)

8. Alvos de Automação Low-Touch

8.1 Problema: Equipe Mínima

A equipe atual não consegue absorver overhead manual para cada interação com cliente. Cada evento "liga pro Michael pra perguntar" é uma falha do sistema.

8.2 Mapa de Automação

Processo Manual Atual	Automação v5
Cliente liga pra perguntar "quanto custa X?"	Catálogo de serviços visível no portal. Selecionar serviço -> ver estimativa de UST -> solicitar cotação.
Michael estima UST para cada OS	Plugin mostra USTs de referência do catálogo. Admin só sobrescreve para fora do catálogo.
Rastreamento de consumo de UST em planilhas	ServiceRequest rastreia `ust_estimated` vs `ust_actual`. Dashboard mostra consumo mensal.
Faturamento mensal requer cálculo manual	Auto-calcular: mensalidade base + (soma das SRs concluídas x USTs x complexidade). Gerar fatura.
"Qual o status do meu projeto?"	Portal mostra Service com ServiceRequests filhas, cada uma com status e progresso de UST.
Agendamento de reunião semanal	Lembrete automatizado. Atas de reunião anexadas ao Service no plugin.

8.3 Matriz de Prioridade de Automação

            Alto Impacto
                 │
   Auto-cálculo  │   Catálogo Self-Service
   de Fatura     │   (solicitação de cotação)
                 │
   Dashboard de  │   Portal de Status
   UST           │   do Projeto
                 │
Baixo Esforço ───┼────────── Alto Esforço
                 │
   Lembretes de  │   Sincronização
   Reunião       │   Bidirecional Jira
                 │
   Notificações  │   Recomendações
   por Email     │   Inteligentes de UST
                 │
            Baixo Impacto

10. Curadoria do Catálogo

10.1 Governança

Conforme os termos da Ficha Técnica: "A MIDDAG faz curadoria contínua do catálogo para manter posicionamento competitivo."

Isso significa que o catálogo é um documento vivo. O plugin deve suportar evolução sem quebrar dados históricos.

10.2 Requisitos do Plugin para Gestão do Catálogo

Requisito	Prioridade	Observações
Admin gerencia catálogo de serviços (CRUD)	P0	Adicionar, editar, desativar serviços. Nunca excluir permanentemente.
Histórico de versões dos valores de UST	P0	Quando o valor base muda, SRs antigas mantêm a taxa do momento da criação.
Histórico de versões de mudanças de complexidade	P1	Se um serviço passa de medium para high, SRs existentes não são afetadas.
Serviços marcados como "requer análise detalhada"	P0	Direciona o fluxo de aprovação — não pode ser ignorado.
Serviços customizados (fora do catálogo)	P1	Admin pode criar serviço avulso com atribuição manual de UST.
Exportação do catálogo (CSV/JSON)	P2	Para auditoria e ferramentas externas.
Exibição do catálogo no portal do cliente	P0	Visualização somente leitura para clientes. Sem preços a menos que configurado.

10.3 Desativação vs Exclusão

Serviço #8 "Customização Visual" é desativado:

Antes da desativação:
  - SRs existentes com serviço #8 → permanecem intactas, totalmente faturáveis
  - Novas SRs → serviço #8 disponível no dropdown

Após a desativação:
  - SRs existentes com serviço #8 → permanecem intactas, totalmente faturáveis
  - Novas SRs → serviço #8 NÃO disponível no dropdown
  - Dashboard admin → aparece como "inativo" com data de desativação
  - Relatórios → ainda incluem dados históricos do serviço #8

11. Notas Pendentes

NFSe: Os códigos de serviço NFSe (city_service_code, federal_service_code) nos YAMLs de produtos ainda não foram definidos. Estes códigos dependem da classificação fiscal de cada serviço junto à Secretaria de Fazenda de Brasília/DF e devem ser preenchidos quando a emissão automática de NFSe for implementada via integração ISSNet.

12. Referências

Documento	Localização
Ficha Técnica Gestão de Projeto	`/private/var/www/middag.termos.localhost/draft/[Ficha Técnica] Gestão de Projeto.md`
Todas as fichas técnicas	`/private/var/www/middag.termos.localhost/draft/`
Modelo de domínio (Entitlement)	`../adrs/ADR-202.md`
Linhas de negócio	`02-business-lines.md`
Visão do produto	`../adrs/ADR-101.md`

Discovery: Catálogo de Serviços & Modelo UST — MIDDAG Account ​

1. O Modelo UST ​

1.1 O Que É uma UST? ​

1.2 Roles & Touch Level ​

1.3 Por Que Isso Importa para o Plugin ​

2. Catálogo de Serviços ​

2.1 Tabela Completa do Catálogo ​

2.2 Observações do Catálogo ​

2.3 Cálculo do Valor de Referência ​

2.4 Service Cards (Definição Detalhada) ​

3. Estrutura de Precificação de Projetos ​

3.1 Custos Fixos ​

3.2 Custos Variáveis ​

3.3 Fatura Mensal Total ​

4. Fluxo da Ordem de Serviço (OS) ​

4.1 Diagrama Completo do Fluxo ​

4.2 Regras de Negócio Principais ​

4.3 Fluxo de Status do ServiceRequest ​

6. Planos de Assinatura (Não-UST) ​

6.1 Visão Geral ​

6.2 Categorias de Plano ​

6.3 Plano vs Créditos: Como Coexistem ​

7. Taxas Horárias (Fora do UST) ​

7.1 Tabela de Taxas ​

7.2 Quando as Taxas Horárias se Aplicam ​

7.3 Implicação para o Plugin ​

8. Alvos de Automação Low-Touch ​

8.1 Problema: Equipe Mínima ​

8.2 Mapa de Automação ​

8.3 Matriz de Prioridade de Automação ​

10. Curadoria do Catálogo ​

10.1 Governança ​

10.2 Requisitos do Plugin para Gestão do Catálogo ​

10.3 Desativação vs Exclusão ​

11. Notas Pendentes ​

12. Referências ​