Solicitações de Serviço
Uma Solicitação de Serviço (SR) é uma tarefa ou ticket criada contra um entitlement. Ela representa uma unidade discreta de trabalho: uma dúvida de suporte, uma alteração de configuração, uma correção de bug, uma solicitação de funcionalidade ou qualquer outro entregável. Solicitações de serviço possuem rastreamento de SLA, faturamento baseado em créditos e um fluxo definido da criação ao faturamento.
O código SR
Toda solicitação de serviço possui um código único no formato SR-YYYYNNNN (ex.: SR-20260042). O código é gerado atomicamente e é utilizado em todas as comunicações — portal, e-mails, Jira e faturas.
Fluxo de trabalho
Solicitações de serviço percorrem um conjunto definido de estados:
| Estado | O que significa |
|---|---|
| Draft | Criada, ainda não submetida para aprovação. |
| Pending approval | Aguardando aprovação do cliente (com créditos estimados). |
| Approved | Cliente aprovou, pronta para execução. |
| In progress | Trabalho está ativamente em andamento. |
| On hold | Bloqueada por dependência externa ou aguardando o cliente. |
| Completed | Trabalho finalizado. Créditos reais registrados. |
| Billed | Incluída na fatura do cliente. Estado terminal. |
| Closed | Rejeitada ou cancelada sem execução. Estado terminal. |
Trabalho pré-aprovado
Se os créditos estimados estiverem dentro de um limite pré-aprovado para o entitlement, a SR pula a etapa de aprovação e vai diretamente de draft para approved. Isso reduz a fricção para tarefas rotineiras de baixo custo.
Rastreamento de SLA
Cada solicitação de serviço está sujeita a metas de SLA determinadas pela classe de serviço do entitlement pai (Free, Basic, Flex, Business, Enterprise ou Government):
| Métrica de SLA | O que mede |
|---|---|
| Tempo de resposta | Tempo desde a criação da SR até a primeira resposta significativa. |
| Tempo de resolução | Tempo desde a criação da SR até a conclusão. |
Os relógios de SLA são gerenciados pelo Jira (que possui aplicação nativa de regras de SLA). O MIDDAG Account lê o estado do SLA via webhooks e o exibe no portal. O MIDDAG Account não executa seus próprios relógios de SLA para evitar divergência.
Níveis de prioridade
| Prioridade | Quando usar |
|---|---|
| Low | Sem urgência. Pode aguardar o próximo slot disponível. |
| Normal | Solicitação padrão. Prioridade default. |
| High | Impacto nos negócios. Precisa de atenção dentro do dia corrente. |
| Urgent | Problema crítico. Degradação ou indisponibilidade do serviço. |
O cliente sugere uma prioridade ao criar a SR. O admin pode reclassificá-la com base no impacto real.
Faturamento por créditos
Solicitações de serviço consomem créditos do saldo de créditos do cliente:
- Na criação — créditos estimados são reservados (soft-lock) do saldo.
- Na conclusão — créditos reais são debitados. Se o real exceder o estimado, a diferença é debitada do saldo disponível ou cobrada separadamente.
- No cancelamento — créditos reservados são devolvidos ao saldo.
O valor faturado é calculado como: créditos_reais x multiplicador_de_complexidade x valor_base_do_crédito. O valor base é capturado como snapshot quando a SR é criada, então mudanças futuras de preço não afetam SRs existentes.
Análise como SR separada
Alguns serviços requerem uma fase de análise detalhada antes da execução (análise de requisitos, avaliação de impacto, especificação técnica). Nesses casos, a análise é criada como uma SR separada vinculada à SR de execução:
- A SR de análise é faturada independentemente.
- Se o cliente aprovar a análise mas rejeitar a execução, apenas a análise é faturada.
- Isso protege ambas as partes: o cliente paga apenas pelo trabalho realizado, e a MIDDAG é compensada pelo esforço de análise.
Dois modos de operação
| Modo | Contexto | Quem cria |
|---|---|---|
| Standalone | Vinculada diretamente a um entitlement ENV. Usada para manutenção de ambientes. | Cliente (pelo portal) ou admin. |
| Service-linked | Vinculada a um contêiner de Serviço sob um entitlement SVC. Usada para trabalho de projeto. | Apenas admin. |
No modo standalone, o cliente clica em "Solicitar Serviço" na página de detalhes de um ambiente e preenche título, descrição e prioridade. No modo service-linked, o admin cria SRs como parte do fluxo de trabalho do projeto.
Integração com Jira
Solicitações de serviço sincronizam bidirecionalmente com o Jira:
| Dados | Fonte de verdade | Direção |
|---|---|---|
| Status | Jira | Jira --> MIDDAG Account |
| Créditos estimados | MIDDAG Account | MIDDAG Account --> Jira |
| Créditos reais | MIDDAG Account | Calculados a partir de worklogs |
| Valor faturado | MIDDAG Account | Não sincronizado (apenas faturamento) |
| Tarefas e subtarefas | Jira | Não sincronizado |
| Regras de SLA | Jira | Jira --> MIDDAG Account (exibição) |
O MIDDAG Account é a autoridade financeira. O Jira é a autoridade operacional.
O que os clientes veem
No portal, clientes veem:
- Código SR, título e descrição
- Status, prioridade e data de vencimento
- Notas do cliente (thread de comunicação)
- Créditos consumidos (após faturamento)
Clientes não veem: notas internas, horas reais, atribuição da equipe ou valor faturado antes da SR atingir o estado billed.
O que os admins veem
No admin do WordPress, a lista de SRs mostra:
- Código SR e título
- Organização e entitlement vinculado
- Serviço (se service-linked)
- Prioridade e status
- Créditos estimados e reais
- Chave do issue no Jira
- Atribuição
Páginas relacionadas
- Serviços — o contêiner de serviço que agrupa SRs
- Ambientes — as instalações que SRs standalone visam
- Saldo de Créditos — como créditos são reservados e consumidos
- Entitlements — o registro de acesso pai
- Contratos — o acordo cujo SLA governa a SR