O que é o app Hypercare

O deploy terminou, o sistema novo está no ar, e começa a parte que ninguém vê no cronograma: conferir se tudo funciona em produção, atender os primeiros chamados, corrigir o que escapou dos testes e decidir quando a equipe do projeto pode entregar o sistema para a sustentação. Esse período de suporte reforçado e com prazo definido se chama hypercare. ^{[4] [5]}

O app Hypercare organiza esse período em um único arquivo HTML. ^[1] Você registra as atividades do pós-deploy, os incidentes com severidade e SLA, as pendências que ficaram para depois e as reuniões de follow-up. O app calcula tempos de resposta e de resolução, aponta o que pede atenção, sugere a pauta da reunião, diz se já dá para encerrar o hypercare e monta o pós-mortem e a documentação.

Abrir o app Hypercare →

Como o app trata os seus dados

• Os dados ficam no navegador. Cada alteração é salva sozinha no armazenamento local do navegador, no mesmo computador. Não há botão Salvar.
• Nada vai para a rede. O app não usa servidor, conta nem biblioteca externa, e bloqueia conexões pela política de segurança do próprio arquivo.
• Cópia e troca são por JSON. Para guardar uma versão, levar para outro computador ou passar para um colega, exporte o JSON e importe do outro lado.
• Quatro idiomas. A interface está em português, inglês, italiano e espanhol. Troque no seletor do topo. Um link que termina em #en, #it ou #es já abre no idioma.
• Tema claro e escuro. O botão ◐ alterna o tema, e o app lembra a escolha.

Conceitos em cinco minutos

As quatro fases

O app acompanha o projeto em quatro fases. Você avança de uma para a outra com o botão Avançar para … → no Painel, e o app grava a data e a hora de cada mudança.

Atividade, incidente e pendência

São três tipos de registro, e confundir um com o outro é o erro mais comum.

• Atividade é trabalho planejado: algo que se sabia que precisava ser feito, como “Executar smoke tests em produção”. Tem fase, responsável, prazo e status (a fazer, em andamento, bloqueada, concluída, não se aplica).
• Incidente é algo que não deveria ter acontecido: erro, lentidão, dado errado. Tem severidade, horários e SLA. O relógio começa na detecção.
• Pendência é algo que ficou para resolver e que não está interrompendo ninguém agora: uma melhoria, um ajuste de configuração, uma documentação, uma decisão. Tem tipo, prioridade, prazo e destino (resolver no hypercare ou transferir para a sustentação). Uma pendência pode nascer de um incidente.

Severidade e SLA

Cada incidente recebe uma severidade de S1 (crítico) a S4 (baixo), e cada severidade tem dois prazos: o de resposta (até alguém começar a tratar) e o de resolução. Os valores abaixo são o padrão do app, e você pode mudá-los na aba Projeto para refletir o acordo da sua organização. Eles são um ponto de partida, não uma norma.

O ciclo de vida de um incidente, MTTA e MTTR

Quando o status sai de Aberto, o app preenche o início do tratamento. Quando chega a Resolvido ou Fechado, preenche a resolução. Você também pode digitar esses horários no formulário, por exemplo para registrar um incidente que aconteceu de madrugada.

Com esses horários o app calcula duas médias. O MTTA (mean time to acknowledge) é o tempo médio entre a detecção e o início do tratamento. O MTTR é o tempo médio entre a detecção e a resolução. A sigla MTTR tem vários significados no mercado (recuperar, reparar, responder, resolver), por isso vale dizer qual se usa. ^[3] Neste app, MTTR é sempre da detecção à resolução.

Critérios de saída

O hypercare termina quando condições combinadas antes são atendidas, e não só quando acaba o prazo. ^{[5] [6]} Um projeto novo já começa com quatro critérios, que você pode editar: nenhum S1 ou S2 aberto há pelo menos 5 dias; pendências de prioridade alta resolvidas ou transferidas; monitoramento e alertas validados em produção; equipe de sustentação treinada e com runbook.

Pós-mortem sem culpados

O pós-mortem registra o que aconteceu, o impacto, as causas e as ações para que não se repita. Ele é sem culpados (blameless): procura as causas no processo, nos sistemas e nas decisões, sem acusar pessoas, porque quem teme punição esconde informação. ^[2] O app traz esse lembrete no topo da aba Pós-mortem.

Passo a passo

O roteiro abaixo cobre um hypercare inteiro, do deploy ao encerramento. Se quiser só conhecer o app, faça o passo 1 e passeie pelas abas.

Passo 1. Conheça o app com o exemplo

1. Abra o app e clique em Carregar exemplo.
2. O app carrega o projeto fictício “Novo portal de pedidos B2B”, com deploy nove dias antes da data de hoje, 8 incidentes, pendências, atividades, dois follow-ups e critérios de saída. As datas acompanham o dia em que você abre o exemplo.
3. Passeie pelas abas. Quando terminar, vá em Projeto → Apagar todos os dados para começar o seu.

Passo 2. Comece o seu projeto

1. Na tela inicial, preencha Nome do projeto, Sistema / serviço, Versão, Data e hora do deploy, Fim previsto do hypercare e Responsável pelo hypercare.
2. Clique em Começar. O projeto nasce na fase Pós-deploy, com quatro critérios de saída e cinco atividades de pós-deploy, todas a fazer, com prazo no dia seguinte ao deploy.

Passo 3. Ajuste SLA e critérios de saída

1. Abra a aba Projeto. Em SLA por severidade, troque os prazos de resposta e de resolução, se o seu acordo for outro, e clique em Aplicar.
2. No mesmo quadro, ajuste Alertar incidente sem atualização após (h). O padrão é 24 horas.
3. Em Critérios de saída do hypercare, apague o que não serve com ×, escreva novos critérios no campo e clique em + Critério. Bons critérios são verificáveis: “taxa de erro da API abaixo de 0,5% por 3 dias seguidos” é melhor que “sistema estável”.

Passo 4. Execute o checklist do pós-deploy

1. Abra a aba Atividades. As cinco atividades padrão estão lá.
2. Clique em uma atividade para abrir o formulário. Preencha o responsável, ajuste o prazo e troque o status para Em andamento ou Concluída. Clique em Salvar.
3. Para incluir outra, use + Atividade. Escolha a fase: atividades de hypercare também cabem aqui, como “Atualizar o runbook com os incidentes do hypercare”.
4. Se algo impede o avanço, marque Bloqueada: o item vai para “Pede atenção agora” no Painel e entra na pauta do follow-up.
5. Com o checklist feito, volte ao Painel e clique em Avançar para Hypercare →. Confirme. A data e a hora ficam na linha das fases.

Passo 5. Registre um incidente

1. Abra a aba Incidentes e clique em + Incidente.
2. Preencha o Título de forma que qualquer pessoa entenda (“ERP rejeita pedidos com desconto progressivo”), a Severidade, o Componente, o Responsável e o Detectado em, que é a hora em que o problema foi percebido, não a hora em que você está digitando.
3. Marque Regressão causada pelo deploy se algo que funcionava deixou de funcionar com a versão nova.
4. Descreva o problema e, se houver, o Contorno (workaround). Clique em Salvar.

Passo 6. Trate e resolva o incidente

1. Na lista de incidentes, clique na linha (ou use Tab até ela e tecle Enter).
2. Troque o status para Em análise. Escreva no campo Nova atualização o que mudou e o próximo passo. Salve. A nota vai para o Histórico com data e hora.
3. Se encontrar um contorno, use Contornado: o usuário consegue trabalhar, mas a causa ainda não foi corrigida.
4. Quando corrigir, preencha Causa raiz e Solução, troque para Resolvido e salve. Depois da confirmação do usuário, use Fechado.
5. Se o problema voltar, volte o status para um estado ativo. O app apaga a hora de resolução, marca o incidente como reaberto e conta a reabertura no pós-mortem.

Passo 7. Registre pendências

1. Abra a aba Pendências e clique em + Pendência.
2. Escolha o Tipo (correção, melhoria, configuração, dados, documentação, treinamento, decisão), a Prioridade e o Destino: Hypercare, se precisa ser resolvida antes de encerrar, ou Sustentação, se pode ficar para a equipe que assume depois.
3. Em Incidente de origem, ligue a pendência ao incidente que a criou, se houver. Assim o pós-mortem mostra de onde veio cada pendência.
4. Ao passar o item para a equipe de sustentação, use o status Transferida p/ sustentação: ele sai da contagem de abertas e aparece no pós-mortem como transferido.

Passo 8. Conduza a reunião de follow-up

1. Abra a aba Follow-ups e clique em + Nova. Ajuste o título, a data e os participantes.
2. Os indicadores do topo comparam com a reunião anterior: 3 +2 quer dizer 3 incidentes abertos, 2 a mais que no último follow-up.
3. Siga a Pauta sugerida: incidentes graves e com SLA estourado, itens bloqueados e atrasados, incidentes sem atualização, situação dos critérios de saída e ações pendentes de reuniões anteriores.
4. Em Atualização rápida, troque o status de cada item ali mesmo e escreva a nota no campo ao lado. A nota é salva ao teclar Enter e vai para o histórico do item.
5. Escreva as Anotações e as Decisões (uma por linha). Em Ações, use + Ação para registrar o que será feito, por quem e até quando.
6. Ao final, clique em 📝 Gerar ata para copiar ou baixar o texto, em 📄 PDF da reunião para salvar o PDF pela janela de impressão, ou em ⬇ Relatório HTML.

Passo 9. Decida se o hypercare pode terminar

1. Na aba Projeto, marque os critérios de saída já atendidos. O app grava a data de cada um.
2. No Painel, leia o último item dos Insights. Ele diz “Pronto para encerrar o hypercare” ou lista o que falta.
3. Com o critério atendido e a concordância de quem responde pelo sistema, clique em Avançar para Pós-mortem →.

Passo 10. Escreva o pós-mortem

1. Abra a aba Pós-mortem. Os indicadores do topo já estão calculados: incidentes no período, MTTR, SLA, regressões, pendências e critérios.
2. Preencha Resumo, Impacto no negócio e nos usuários, O que funcionou, O que não funcionou, Causas raiz e Lições aprendidas. O texto é salvo ao sair de cada campo.
3. Confira a Linha do tempo, montada sozinha com o deploy, as mudanças de fase, os incidentes e as resoluções.
4. Registre as Ações de melhoria com responsável e prazo.
5. Escolha a Decisão: encerrar o hypercare, estendê-lo até uma data ou reverter o deploy. Escreva a justificativa e a aprovação.
6. Gere o 📄 PDF do pós-mortem ou o ⬇ Documento do pós-mortem (HTML) e circule.

Passo 11. Encerre e guarde

1. No Painel, clique em Avançar para Encerrado →.
2. Em ⬇ Exportar, baixe a 📘 Documentação completa (HTML) ou a versão em PDF, e o JSON (backup completo). Guarde os dois junto com a documentação do projeto.

As abas do app

Teclado: as setas ← e → trocam de aba quando o foco está na barra de abas; Enter abre a linha da lista em foco; Esc fecha o formulário.

Como ler o painel

A situação: estável, atenção ou crítica

A faixa colorida do Painel resume o momento com regras fixas, que você pode conferir:

Pronto para encerrar?

Nas fases Pós-deploy e Hypercare, o último insight diz se o hypercare pode terminar. O app só diz “pronto” quando tudo isto vale ao mesmo tempo:

• nenhum incidente S1 ou S2 aberto;
• pelo menos um critério de saída cadastrado, e todos atendidos;
• nenhuma pendência de prioridade alta aberta com destino Hypercare;
• os incidentes detectados nos últimos 3 dias não superam os dos 3 dias anteriores.

Se faltar algo, ele lista os motivos. O app não avança de fase sozinho: a decisão é das pessoas.

Os insights

Os insights são frases montadas com os registros: dias desde o deploy e até o fim previsto, total e abertos por severidade, tendência dos últimos 3 dias, MTTR, MTTA e SLA cumprido, incidentes com SLA estourado, dias sem S1 ou S2, componente que concentra incidentes, regressões, reaberturas, incidentes sem atualização, pendências, atividades, pessoas com quatro ou mais itens abertos, critérios e ações em aberto.

Como interpretar os números

• MTTR alto com poucos incidentes costuma vir de um caso longo. Abra a lista e veja qual puxa a média.
• Componente com metade dos incidentes pede uma conversa com quem cuida dele, e talvez uma pendência de melhoria.
• Muitas regressões apontam para os testes antes do deploy. É assunto para o pós-mortem.
• Muitos “sem atualização” indicam que os incidentes estão parados ou que ninguém está registrando o andamento. Os dois casos merecem atenção.
• Incidentes em alta no fim do prazo são o sinal mais forte para estender o hypercare.

O SLA cumprido é calculado só sobre incidentes já resolvidos. Os abertos com prazo estourado aparecem à parte, no indicador e em “Pede atenção agora”.

Boas práticas e erros comuns

Boas práticas

• Combine os critérios de saída antes do deploy. Discutir critério com o sistema já no ar vira negociação de prazo. ^{[5] [6]}
• Registre a hora real da detecção. Lançar o incidente horas depois, com a hora do lançamento, faz o SLA parecer melhor do que foi.
• Uma atualização por dia, no mínimo, em todo incidente aberto. O alerta “sem atualização” ajuda a lembrar.
• Follow-up curto e frequente. Diário na primeira semana, depois conforme a tendência. Use a pauta sugerida e feche cada reunião com ações que tenham responsável e prazo.
• Exporte o JSON ao fim de cada dia. Os dados vivem no navegador; o JSON é a sua cópia.

Erros comuns

• “Registro tudo como incidente.”

  Melhorias e dúvidas viram pendências. Incidente demais distorce o MTTR e esconde os problemas reais.

• “Classifico tudo como S1 para ser atendido mais rápido.”

  Quando tudo é crítico, nada é. A situação do painel fica vermelha o tempo todo e perde o valor de alerta.

• “O prazo acabou, então o hypercare acabou.”

  O fim previsto é uma data; o encerramento depende dos critérios. Se não foram atendidos, estenda e registre a decisão.

• “O pós-mortem é para achar o responsável.”

  Um pós-mortem que procura culpados faz as pessoas esconderem informação, e as causas reais ficam sem tratamento. ^[2]

• “Fecho o incidente e abro outro igual.”

  Se o problema voltou, reabra o mesmo. Assim a reabertura é contada e o histórico fica inteiro.

Prompts para acelerar o trabalho

Os prompts abaixo usam o que o app produz: a ata, o JSON e os textos dos incidentes. Troque os trechos entre colchetes. Para escrever prompts melhores, veja o tutorial de prompts deste site. ^[7]

Antes de colar: incidentes e atas costumam ter nomes de clientes, dados de usuários e detalhes de infraestrutura. Troque por dados fictícios e siga a política da sua organização para uso de IA. O app não envia nada para a rede, mas o serviço de IA recebe o que você colar.

1. Critérios de saída para o seu sistema

Vou colocar em produção [descreva o sistema, os usuários e as integrações].
Proponha de 5 a 8 critérios de saída do hypercare.
Cada critério precisa ser verificável, com número e período (ex.: "taxa de erro abaixo de 0,5% por 3 dias seguidos").
Inclua critérios técnicos, de suporte e de negócio.
Para cada um, diga de onde vem o dado e quem confirma.
Não invente valores do meu sistema: quando não souber, escreva [definir].

2. Escrever um incidente claro

Abaixo está a descrição de um problema, do jeito que chegou do usuário.
Reescreva para registrar como incidente, com:
- título de até 80 caracteres, que diga o que falha e onde;
- descrição em até 5 linhas: o que acontece, desde quando, quem é afetado, como reproduzir;
- severidade sugerida (S1 a S4) e o motivo, usando esta régua: [cole a régua da sua equipe];
- perguntas que faltam responder.
Não invente fatos que não estejam no texto.

Texto: [cole aqui]

3. Resumo executivo a partir da ata

Abaixo está a ata gerada pelo app Hypercare (dados anonimizados).
Escreva um resumo para [diretoria / área de negócio], em até 150 palavras:
situação geral, o que melhorou, o que preocupa, decisões e o que precisamos deles.
Use só os números da ata. Não arredonde nem estime números que não estão lá.

Ata: [cole aqui]

4. Rascunho do pós-mortem

Abaixo está o JSON exportado do app Hypercare (dados anonimizados).
Ajude a preparar o pós-mortem sem culpados:
1. Agrupe os incidentes por causa provável e diga quais dados sustentam cada grupo.
2. Proponha textos curtos para "O que funcionou" e "O que não funcionou".
3. Sugira até 5 ações de melhoria, cada uma ligada a um grupo de incidentes.
Descreva processos e sistemas, nunca pessoas.
Marque como [hipótese] tudo o que não estiver nos dados.

JSON: [cole aqui]

Confira sempre o que a IA devolver. Os números do app vêm dos registros; os da IA podem ser inventados.

Dados, exportação e documentos

Os PDFs usam a janela de impressão do navegador: escolha Salvar como PDF como destino. Os documentos HTML abrem em qualquer navegador e não dependem do app.

Importar

⬆ Importar JSON substitui os dados atuais pelos do arquivo. Exporte antes, se quiser guardar o que está na tela. Arquivos que não são JSON do app são recusados com aviso.

Limitações e solução de problemas

• Um projeto por navegador. Para acompanhar dois deploys, use navegadores ou perfis diferentes, ou alterne pelo JSON.
• Não é multiusuário. Duas pessoas não editam o mesmo projeto ao mesmo tempo. Combine quem registra e circule o JSON ou os documentos.
• Não integra com ferramentas de chamados ou de monitoramento. Os incidentes são digitados no app.
• Limpar os dados do navegador apaga o projeto. A navegação anônima também não guarda nada depois de fechada. Exporte o JSON.
• Horários no fuso do computador. Os cálculos usam o relógio e o fuso da máquina. Equipes em fusos diferentes devem combinar a referência.

Glossário

Revisão rápida

Referências

1. Giovani Perotto Mesquita, “Hypercare”, app deste site, giovanipm.github.io/hypercare.html.
2. John Lunney e Sue Lueder, “Postmortem Culture: Learning from Failure”, cap. 15 de Site Reliability Engineering, O’Reilly/Google, 2016, acesso em 12/11/2026, sre.google/sre-book/postmortem-culture.
3. Atlassian, “Common incident management metrics”, acesso em 12/11/2026, atlassian.com/incident-management/kpis/common-metrics.
4. ERP Research, “What is Hypercare?”, glossário de ERP, acesso em 12/11/2026, erpresearch.com/glossary/hypercare.
5. Panorama Consulting Group, “ERP Hypercare Checklist to Help You Stabilize Fast”, acesso em 12/11/2026, panorama-consulting.com.
6. Eric Klimuk, “What Is Hypercare? Definition, Timeline & Exit Criteria for B2B Support Teams”, Supportbench, 2026, acesso em 12/11/2026, supportbench.com. As referências 4 a 6 são de fornecedores e consultorias, não de norma. Elas concordam que o hypercare tem prazo e termina por critérios combinados, mas divergem na duração típica: de 2 a 8 semanas para a ERP Research, de 2 a 6 semanas para a Supportbench, e “várias semanas”, conforme a complexidade, para a Panorama.
7. Giovani Perotto Mesquita, “Tutorial de prompts”, tutorial deste site, giovanipm.github.io/PromptTutorial.html.

What the Hypercare app is

The deploy is done, the new system is live, and the part nobody sees on the schedule begins: checking that everything works in production, handling the first tickets, fixing what slipped past testing, and deciding when the project team can hand the system over to support. This time-limited period of reinforced support is called hypercare. ^{[4] [5]}

The Hypercare app organises this period in a single HTML file. ^[1] You record the post-deploy activities, the incidents with severity and SLA, the open items left for later and the follow-up meetings. The app calculates response and resolution times, points out what needs attention, suggests the meeting agenda, tells you whether hypercare can close, and builds the post-mortem and the documentation.

Open the Hypercare app →

How the app handles your data

• The data stays in the browser. Every change is saved automatically in the browser’s local storage, on the same computer. There is no Save button for the project.
• Nothing goes over the network. The app uses no server, account or external library, and the file’s own security policy blocks connections.
• Copies and handovers use JSON. To keep a version, move to another computer or pass the project to a colleague, export the JSON and import it on the other side.
• Four languages. The interface is available in Portuguese, English, Italian and Spanish. Switch in the selector at the top. A link ending in #en, #it or #es opens in that language.
• Light and dark theme. The ◐ button toggles the theme, and the app remembers your choice.

Concepts in five minutes

The four phases

The app tracks the project in four phases. You move from one to the next with the Move to … → button on the Dashboard, and the app records the date and time of each change.

Activity, incident and open item

There are three kinds of record, and mixing them up is the most common mistake.

• Activity is planned work: something you knew had to be done, such as “Run smoke tests in production”. It has a phase, owner, due date and status (to do, in progress, blocked, done, not applicable).
• Incident is something that should not have happened: an error, slowness, wrong data. It has a severity, timestamps and an SLA. The clock starts at detection.
• Open item is something left to resolve that is not stopping anyone right now: an improvement, a configuration change, documentation, a decision. It has a type, priority, due date and target (resolve during hypercare or hand over to support). An open item can come from an incident.

Severity and SLA

Each incident gets a severity from S1 (critical) to S4 (low), and each severity has two limits: response (until someone starts working on it) and resolution. The values below are the app’s defaults, and you can change them on the Project tab to match your organisation’s agreement. They are a starting point, not a standard.

An incident’s life cycle, MTTA and MTTR

When the status leaves Open, the app fills in Acknowledged at. When it reaches Resolved or Closed, it fills in Resolved at. You can also type these times in the form, for instance to record an incident that happened overnight.

From these timestamps the app calculates two averages. MTTA (mean time to acknowledge) is the average time from detection to acknowledgement. MTTR is the average time from detection to resolution. The acronym MTTR has several meanings in the industry (recover, repair, respond, resolve), so it is worth saying which one you use. ^[3] In this app, MTTR is always from detection to resolution.

Exit criteria

Hypercare ends when conditions agreed in advance are met, not just when the time runs out. ^{[5] [6]} A new project starts with four criteria, which you can edit: no S1 or S2 incident open for at least 5 days; high-priority open items resolved or handed over; monitoring and alerts validated in production; support team trained and with a runbook.

Blameless post-mortem

The post-mortem records what happened, the impact, the causes and the actions to prevent a repeat. It is blameless: it looks for causes in processes, systems and decisions without accusing people, because people who fear punishment hide information. ^[2] The app shows this reminder at the top of the Post-mortem tab.

Step by step

The walkthrough below covers a whole hypercare, from deploy to closure. If you just want to look around, do step 1 and browse the tabs.

Step 1. Get to know the app with the sample

1. Open the app and click Load sample.
2. The app loads the fictitious project “New B2B ordering portal”, deployed nine days before today, with 8 incidents, open items, activities, two follow-ups and exit criteria. The dates follow the day you open the sample.
3. Browse the tabs. When you are done, go to Project → Delete all data to start your own.

Step 2. Start your project

1. On the start screen, fill in Project name, System / service, Release, Deploy date and time, Planned end of hypercare and Hypercare lead.
2. Click Start. The project begins in the Post-deploy phase, with four exit criteria and five post-deploy activities, all to do, due the day after the deploy.

Step 3. Adjust the SLA and exit criteria

1. Open the Project tab. Under SLA by severity, change the response and resolution limits if your agreement is different, and click Apply.
2. In the same panel, adjust Flag incidents with no update after (h). The default is 24 hours.
3. Under Hypercare exit criteria, remove what does not fit with ×, type new criteria in the field and click + Criterion. Good criteria can be checked: “API error rate below 0.5% for 3 days in a row” beats “stable system”.

Step 4. Run the post-deploy checklist

1. Open the Activities tab. The five default activities are there.
2. Click an activity to open the form. Fill in the owner, adjust the due date and change the status to In progress or Done. Click Save.
3. To add another, use + Activity. Choose the phase: hypercare activities fit here too, such as “Update the runbook with the hypercare incidents”.
4. If something is holding it up, mark it Blocked: the item goes to “Needs attention now” on the Dashboard and onto the follow-up agenda.
5. With the checklist done, go back to the Dashboard and click Move to Hypercare →. Confirm. The date and time appear in the phase row.

Step 5. Record an incident

1. Open the Incidents tab and click + Incident.
2. Fill in a Title anyone can understand (“ERP rejects orders with tiered discount”), the Severity, Component, Owner and Detected at, which is when the problem was noticed, not when you are typing.
3. Tick Regression caused by the deploy if something that used to work stopped working with the new release.
4. Describe the problem and, if there is one, the Workaround. Click Save.

Step 6. Handle and resolve the incident

1. In the incident list, click the row (or Tab to it and press Enter).
2. Change the status to Investigating. Write what changed and the next step in the New update field. Save. The note goes to the History with date and time.
3. If you find a workaround, use Workaround: users can work, but the cause has not been fixed yet.
4. When it is fixed, fill in Root cause and Resolution, change to Resolved and save. After the user confirms, use Closed.
5. If the problem comes back, set the status back to an active state. The app clears the resolution time, marks the incident as reopened and counts the reopening in the post-mortem.

Step 7. Record open items

1. Open the Open items tab and click + Open item.
2. Choose the Type (fix, improvement, configuration, data, documentation, training, decision), the Priority and the Target: Hypercare if it must be resolved before closing, or Support if it can wait for the team that takes over.
3. Under Source incident, link the item to the incident that created it, if any. The post-mortem then shows where each item came from.
4. When you pass the item to the support team, use the status Handed to support: it leaves the open count and shows up in the post-mortem as handed over.

Step 8. Run the follow-up meeting

1. Open the Follow-ups tab and click + New. Adjust the title, date and participants.
2. The indicators at the top compare with the previous meeting: 3 +2 means 3 open incidents, 2 more than at the last follow-up.
3. Follow the Suggested agenda: serious incidents and breached SLAs, blocked and overdue items, incidents with no update, the state of the exit criteria and pending actions from previous meetings.
4. In Quick update, change each item’s status right there and write the note in the field beside it. The note is saved when you press Enter and goes to the item’s history.
5. Write the Notes and Decisions (one per line). Under Actions, use + Action to record what will be done, by whom and by when.
6. At the end, click 📝 Generate minutes to copy or download the text, 📄 Meeting PDF to save the PDF through the print dialog, or ⬇ HTML report.

Step 9. Decide whether hypercare can end

1. On the Project tab, tick the exit criteria already met. The app records the date of each one.
2. On the Dashboard, read the last item in Insights. It says “Ready to close hypercare” or lists what is missing.
3. With the criteria met and the agreement of whoever is accountable for the system, click Move to Post-mortem →.

Step 10. Write the post-mortem

1. Open the Post-mortem tab. The indicators at the top are already calculated: incidents in the period, MTTR, SLA, regressions, open items and criteria.
2. Fill in Summary, Impact on business and users, What went well, What went wrong, Root causes and Lessons learned. The text is saved when you leave each field.
3. Check the Timeline, built automatically from the deploy, phase changes, incidents and resolutions.
4. Record the Improvement actions with owner and due date.
5. Choose the Decision: close hypercare, extend it to a date, or roll back the deploy. Write the rationale and the sign-off.
6. Generate the 📄 Post-mortem PDF or the ⬇ Post-mortem document (HTML) and circulate it.

Step 11. Close and keep the records

1. On the Dashboard, click Move to Closed →.
2. Under ⬇ Export, download the 📘 Full documentation (HTML) or the PDF version, and the JSON (full backup). Keep both with the project documentation.

The app’s tabs

Keyboard: the ← and → arrows switch tabs when the focus is on the tab bar; Enter opens the focused list row; Esc closes the form.

How to read the dashboard

Status: stable, attention or critical

The coloured band on the Dashboard sums up the moment with fixed rules you can check:

Ready to close?

In the Post-deploy and Hypercare phases, the last insight says whether hypercare can end. The app only says “ready” when all of these hold at the same time:

• no open S1 or S2 incident;
• at least one exit criterion recorded, and all of them met;
• no open high-priority item with the Hypercare target;
• incidents detected in the last 3 days do not exceed those in the 3 days before.

If something is missing, it lists the reasons. The app never changes phase on its own: the decision belongs to people.

The insights

The insights are sentences built from the records: days since deploy and until the planned end, total and open incidents by severity, the trend over the last 3 days, MTTR, MTTA and SLA met, incidents with a breached SLA, days without S1 or S2, the component with the most incidents, regressions, reopenings, incidents with no update, open items, activities, people with four or more open items, criteria and open actions.

How to interpret the numbers

• High MTTR with few incidents usually comes from one long case. Open the list and see which one pulls the average up.
• One component with half the incidents calls for a talk with whoever looks after it, and perhaps an improvement item.
• Many regressions point to the testing before the deploy. That is a topic for the post-mortem.
• Many “no update” tags mean incidents are stuck or nobody is recording progress. Both deserve attention.
• Incidents rising near the planned end is the strongest signal to extend hypercare.

SLA met is calculated only over incidents already resolved. Open incidents past their limit are shown separately, in the indicator and under “Needs attention now”.

Good practices and common mistakes

Good practices

• Agree the exit criteria before the deploy. Discussing criteria with the system already live turns into a deadline negotiation. ^{[5] [6]}
• Record the real detection time. Logging an incident hours later with the logging time makes the SLA look better than it was.
• At least one update a day on every open incident. The “no update” flag helps you remember.
• Short, frequent follow-ups. Daily in the first week, then according to the trend. Use the suggested agenda and end every meeting with actions that have an owner and a date.
• Export the JSON at the end of each day. The data lives in the browser; the JSON is your copy.

Common mistakes

• “I record everything as an incident.”

  Improvements and questions are open items. Too many incidents distort MTTR and hide the real problems.

• “I mark everything S1 so it gets handled faster.”

  When everything is critical, nothing is. The dashboard stays red all the time and loses its value as an alert.

• “The time is up, so hypercare is over.”

  The planned end is a date; closing depends on the criteria. If they are not met, extend and record the decision.

• “The post-mortem is for finding who is responsible.”

  A post-mortem that looks for culprits makes people hide information, and the real causes go untreated. ^[2]

• “I close the incident and open an identical one.”

  If the problem came back, reopen the same incident. That way the reopening is counted and the history stays whole.

Prompts to speed up the work

The prompts below use what the app produces: the minutes, the JSON and the incident texts. Replace the parts in square brackets. To write better prompts, see this site’s prompt tutorial. ^[7]

Before you paste: incidents and minutes often contain customer names, user data and infrastructure details. Replace them with fictitious data and follow your organisation’s AI policy. The app sends nothing over the network, but the AI service receives whatever you paste.

1. Exit criteria for your system

I am about to put [describe the system, its users and its integrations] into production.
Propose 5 to 8 hypercare exit criteria.
Each criterion must be verifiable, with a number and a period (e.g. "error rate below 0.5% for 3 days in a row").
Include technical, support and business criteria.
For each one, say where the data comes from and who confirms it.
Do not invent values for my system: when you do not know, write [define].

2. Write a clear incident

Below is the description of a problem, as it came from the user.
Rewrite it to record as an incident, with:
- a title of up to 80 characters that says what fails and where;
- a description of up to 5 lines: what happens, since when, who is affected, how to reproduce;
- a suggested severity (S1 to S4) and the reason, using this scale: [paste your team's scale];
- the questions still to be answered.
Do not invent facts that are not in the text.

Text: [paste here]

3. Executive summary from the minutes

Below are the minutes generated by the Hypercare app (anonymised data).
Write a summary for [leadership / business area], in up to 150 words:
overall status, what improved, what worries us, decisions and what we need from them.
Use only the numbers in the minutes. Do not round or estimate numbers that are not there.

Minutes: [paste here]

4. Post-mortem draft

Below is the JSON exported from the Hypercare app (anonymised data).
Help me prepare a blameless post-mortem:
1. Group the incidents by likely cause and say which data supports each group.
2. Propose short texts for "What went well" and "What went wrong".
3. Suggest up to 5 improvement actions, each linked to a group of incidents.
Describe processes and systems, never people.
Mark as [hypothesis] anything that is not in the data.

JSON: [paste here]

Always check what the AI returns. The app’s numbers come from the records; the AI’s may be made up.

Data, export and documents

The PDFs use the browser’s print dialog: choose Save as PDF as the destination. The HTML documents open in any browser and do not depend on the app.

Import

⬆ Import JSON replaces the current data with the file’s data. Export first if you want to keep what is on screen. Files that are not the app’s JSON are rejected with a message.

Limitations and troubleshooting

• One project per browser. To track two deploys, use different browsers or profiles, or switch via JSON.
• Not multi-user. Two people cannot edit the same project at the same time. Agree who records and circulate the JSON or the documents.
• No integration with ticketing or monitoring tools. Incidents are typed into the app.
• Clearing the browser’s data deletes the project. A private window also keeps nothing once closed. Export the JSON.
• Times in the computer’s time zone. The calculations use the machine’s clock and time zone. Teams in different time zones should agree on a reference.

Glossary

Quick review

References

1. Giovani Perotto Mesquita, “Hypercare”, app on this site, giovanipm.github.io/hypercare.html.
2. John Lunney and Sue Lueder, “Postmortem Culture: Learning from Failure”, ch. 15 of Site Reliability Engineering, O’Reilly/Google, 2016, accessed 12 November 2026, sre.google/sre-book/postmortem-culture.
3. Atlassian, “Common incident management metrics”, accessed 12 November 2026, atlassian.com/incident-management/kpis/common-metrics.
4. ERP Research, “What is Hypercare?”, ERP glossary, accessed 12 November 2026, erpresearch.com/glossary/hypercare.
5. Panorama Consulting Group, “ERP Hypercare Checklist to Help You Stabilize Fast”, accessed 12 November 2026, panorama-consulting.com.
6. Eric Klimuk, “What Is Hypercare? Definition, Timeline & Exit Criteria for B2B Support Teams”, Supportbench, 2026, accessed 12 November 2026, supportbench.com. References 4 to 6 come from vendors and consultancies, not from a standard. They agree that hypercare is time-limited and ends by agreed criteria, but differ on the typical length: 2 to 8 weeks for ERP Research, 2 to 6 weeks for Supportbench, and “several weeks”, depending on complexity, for Panorama.
7. Giovani Perotto Mesquita, prompt tutorial on this site, giovanipm.github.io/PromptTutorial.html.

Che cos’è l’app Hypercare

Il rilascio è finito, il nuovo sistema è in produzione e comincia la parte che nessuno vede nel cronoprogramma: verificare che tutto funzioni, gestire le prime segnalazioni, correggere ciò che è sfuggito ai test e decidere quando il team di progetto può consegnare il sistema al supporto. Questo periodo di supporto rafforzato e a tempo si chiama hypercare. ^{[4] [5]}

L’app Hypercare organizza questo periodo in un unico file HTML. ^[1] Registri le attività del post-rilascio, gli incidenti con gravità e SLA, le pendenze rimaste e le riunioni di follow-up. L’app calcola i tempi di risposta e di risoluzione, indica ciò che richiede attenzione, suggerisce l’ordine del giorno, dice se l’hypercare può chiudersi e prepara il post-mortem e la documentazione.

Apri l’app Hypercare →

Come l’app tratta i tuoi dati

• I dati restano nel browser. Ogni modifica viene salvata da sola nella memoria locale del browser, sullo stesso computer. Non c’è un pulsante Salva per il progetto.
• Niente va in rete. L’app non usa server, account né librerie esterne, e la politica di sicurezza del file stesso blocca le connessioni.
• Copie e passaggi avvengono con il JSON. Per conservare una versione, spostarti su un altro computer o passare il progetto a un collega, esporta il JSON e importalo dall’altra parte.
• Quattro lingue. L’interfaccia è in portoghese, inglese, italiano e spagnolo. Cambia lingua dal selettore in alto. Un link che termina con #en, #it o #es si apre già nella lingua.
• Tema chiaro e scuro. Il pulsante ◐ cambia il tema, e l’app ricorda la scelta.

I concetti in cinque minuti

Le quattro fasi

L’app segue il progetto in quattro fasi. Passi dall’una all’altra con il pulsante Passa a … → nel Cruscotto, e l’app registra data e ora di ogni cambio.

Attività, incidente e pendenza

Sono tre tipi di registrazione, e confonderli è l’errore più comune.

• Attività è lavoro pianificato: qualcosa che si sapeva di dover fare, come “Eseguire smoke test in produzione”. Ha fase, responsabile, scadenza e stato (da fare, in corso, bloccata, completata, non applicabile).
• Incidente è qualcosa che non sarebbe dovuto succedere: errore, lentezza, dato sbagliato. Ha gravità, orari e SLA. Il cronometro parte dal rilevamento.
• Pendenza è qualcosa da risolvere che ora non blocca nessuno: un miglioramento, una configurazione, una documentazione, una decisione. Ha tipo, priorità, scadenza e destinazione (risolvere durante l’hypercare o passare al supporto). Una pendenza può nascere da un incidente.

Gravità e SLA

Ogni incidente riceve una gravità da S1 (critico) a S4 (basso), e ogni gravità ha due limiti: quello di risposta (finché qualcuno non inizia a lavorarci) e quello di risoluzione. I valori qui sotto sono quelli predefiniti dell’app, e puoi cambiarli nella scheda Progetto secondo l’accordo della tua organizzazione. Sono un punto di partenza, non una norma.

Il ciclo di vita di un incidente, MTTA e MTTR

Quando lo stato esce da Aperto, l’app compila la presa in carico. Quando arriva a Risolto o Chiuso, compila il campo Risolto il. Puoi anche digitare questi orari nel modulo, per esempio per registrare un incidente avvenuto di notte.

Con questi orari l’app calcola due medie. L’MTTA (mean time to acknowledge) è il tempo medio tra il rilevamento e la presa in carico. L’MTTR è il tempo medio tra il rilevamento e la risoluzione. La sigla MTTR ha vari significati nel settore (ripristinare, riparare, rispondere, risolvere), quindi conviene dire quale si usa. ^[3] In questa app, MTTR è sempre dal rilevamento alla risoluzione.

Criteri di uscita

L’hypercare finisce quando si soddisfano condizioni concordate prima, non solo quando scade il tempo. ^{[5] [6]} Un progetto nuovo parte con quattro criteri modificabili: nessun incidente S1 o S2 aperto da almeno 5 giorni; pendenze ad alta priorità risolte o trasferite; monitoraggio e allarmi validati in produzione; team di supporto formato e con runbook.

Post-mortem senza colpevoli

Il post-mortem registra cosa è successo, l’impatto, le cause e le azioni per evitare che si ripeta. È senza colpevoli (blameless): cerca le cause nei processi, nei sistemi e nelle decisioni, senza accusare le persone, perché chi teme una punizione nasconde informazioni. ^[2] L’app mostra questo promemoria in cima alla scheda Post-mortem.

Passo dopo passo

Il percorso qui sotto copre un intero hypercare, dal rilascio alla chiusura. Se vuoi solo conoscere l’app, fai il passo 1 e gira tra le schede.

Passo 1. Conosci l’app con l’esempio

1. Apri l’app e fai clic su Carica esempio.
2. L’app carica il progetto fittizio “Nuovo portale ordini B2B”, rilasciato nove giorni prima di oggi, con 8 incidenti, pendenze, attività, due follow-up e criteri di uscita. Le date seguono il giorno in cui apri l’esempio.
3. Gira tra le schede. Quando hai finito, vai in Progetto → Cancella tutti i dati per avviare il tuo.

Passo 2. Avvia il tuo progetto

1. Nella schermata iniziale, compila Nome del progetto, Sistema / servizio, Versione (release), Data e ora del rilascio, Fine prevista dell’hypercare e Responsabile dell’hypercare.
2. Fai clic su Inizia. Il progetto nasce nella fase Post-rilascio, con quattro criteri di uscita e cinque attività di post-rilascio, tutte da fare, con scadenza il giorno dopo il rilascio.

Passo 3. Regola SLA e criteri di uscita

1. Apri la scheda Progetto. In SLA per gravità, cambia i limiti di risposta e di risoluzione se il tuo accordo è diverso, e fai clic su Applica.
2. Nello stesso riquadro, regola Segnala incidenti senza aggiornamento dopo (h). Il valore predefinito è 24 ore.
3. In Criteri di uscita dall’hypercare, elimina ciò che non serve con ×, scrivi nuovi criteri nel campo e fai clic su + Criterio. I buoni criteri sono verificabili: “tasso di errore dell’API sotto lo 0,5% per 3 giorni di fila” è meglio di “sistema stabile”.

Passo 4. Esegui la checklist del post-rilascio

1. Apri la scheda Attività. Ci sono le cinque attività predefinite.
2. Fai clic su un’attività per aprire il modulo. Inserisci il responsabile, regola la scadenza e cambia lo stato in In corso o Completata. Fai clic su Salva.
3. Per aggiungerne un’altra, usa + Attività. Scegli la fase: anche le attività di hypercare stanno qui, come “Aggiornare il runbook con gli incidenti dell’hypercare”.
4. Se qualcosa impedisce di andare avanti, segna Bloccata: l’elemento va in “Richiede attenzione” nel Cruscotto ed entra nell’ordine del giorno del follow-up.
5. Completata la checklist, torna al Cruscotto e fai clic su Passa a Hypercare →. Conferma. Data e ora compaiono nella riga delle fasi.

Passo 5. Registra un incidente

1. Apri la scheda Incidenti e fai clic su + Incidente.
2. Scrivi un Titolo che chiunque capisca (“L’ERP rifiuta gli ordini con sconto progressivo”), la Gravità, il Componente, il Responsabile e il Rilevato il, cioè quando il problema è stato notato, non quando stai digitando.
3. Spunta Regressione causata dal rilascio se qualcosa che funzionava ha smesso di funzionare con la nuova versione.
4. Descrivi il problema e, se c’è, la Soluzione temporanea. Fai clic su Salva.

Passo 6. Gestisci e risolvi l’incidente

1. Nell’elenco degli incidenti, fai clic sulla riga (o raggiungila con Tab e premi Invio).
2. Cambia lo stato in In analisi. Scrivi nel campo Nuovo aggiornamento cosa è cambiato e il prossimo passo. Salva. La nota va nello Storico con data e ora.
3. Se trovi un aggiramento, usa Aggirato: l’utente riesce a lavorare, ma la causa non è ancora corretta.
4. Quando hai corretto, compila Causa principale e Soluzione, passa a Risolto e salva. Dopo la conferma dell’utente, usa Chiuso.
5. Se il problema ritorna, riporta lo stato a uno stato attivo. L’app cancella l’ora di risoluzione, segna l’incidente come riaperto e conta la riapertura nel post-mortem.

Passo 7. Registra le pendenze

1. Apri la scheda Pendenze e fai clic su + Pendenza.
2. Scegli il Tipo (correzione, miglioramento, configurazione, dati, documentazione, formazione, decisione), la Priorità e la Destinazione: Hypercare se va risolta prima di chiudere, o Supporto se può restare al team che subentra.
3. In Incidente di origine, collega la pendenza all’incidente che l’ha generata, se c’è. Così il post-mortem mostra da dove viene ogni pendenza.
4. Quando passi l’elemento al team di supporto, usa lo stato Passata al supporto: esce dal conteggio delle aperte e compare nel post-mortem come trasferita.

Passo 8. Conduci la riunione di follow-up

1. Apri la scheda Follow-up e fai clic su + Nuova. Regola titolo, data e partecipanti.
2. Gli indicatori in alto si confrontano con la riunione precedente: 3 +2 significa 3 incidenti aperti, 2 in più dell’ultimo follow-up.
3. Segui l’Ordine del giorno suggerito: incidenti gravi e con SLA superato, elementi bloccati e in ritardo, incidenti senza aggiornamento, stato dei criteri di uscita e azioni in sospeso delle riunioni precedenti.
4. In Aggiornamento rapido, cambia lo stato di ogni elemento lì stesso e scrivi la nota nel campo accanto. La nota viene salvata premendo Invio e va nello storico dell’elemento.
5. Scrivi le Note e le Decisioni (una per riga). In Azioni, usa + Azione per registrare cosa verrà fatto, da chi e entro quando.
6. Alla fine, fai clic su 📝 Genera verbale per copiare o scaricare il testo, su 📄 PDF della riunione per salvare il PDF dalla finestra di stampa, o su ⬇ Report HTML.

Passo 9. Decidi se l’hypercare può finire

1. Nella scheda Progetto, spunta i criteri di uscita già soddisfatti. L’app registra la data di ciascuno.
2. Nel Cruscotto, leggi l’ultima voce delle Osservazioni. Dice “Pronto a chiudere l’hypercare” o elenca cosa manca.
3. Con i criteri soddisfatti e l’accordo di chi risponde del sistema, fai clic su Passa a Post-mortem →.

Passo 10. Scrivi il post-mortem

1. Apri la scheda Post-mortem. Gli indicatori in alto sono già calcolati: incidenti nel periodo, MTTR, SLA, regressioni, pendenze e criteri.
2. Compila Sintesi, Impatto su business e utenti, Cosa ha funzionato, Cosa non ha funzionato, Cause principali e Lezioni apprese. Il testo viene salvato quando esci da ogni campo.
3. Controlla la Cronologia, costruita da sola con il rilascio, i cambi di fase, gli incidenti e le risoluzioni.
4. Registra le Azioni di miglioramento con responsabile e scadenza.
5. Scegli la Decisione: chiudere l’hypercare, estenderlo fino a una data o annullare il rilascio. Scrivi la motivazione e l’approvazione.
6. Genera il 📄 PDF del post-mortem o il ⬇ Documento del post-mortem (HTML) e fallo circolare.

Passo 11. Chiudi e conserva

1. Nel Cruscotto, fai clic su Passa a Chiuso →.
2. In ⬇ Esporta, scarica la 📘 Documentazione completa (HTML) o la versione PDF, e il JSON (backup completo). Conservali insieme alla documentazione del progetto.

Le schede dell’app

Tastiera: le frecce ← e → cambiano scheda quando il fuoco è sulla barra delle schede; Invio apre la riga dell’elenco con il fuoco; Esc chiude il modulo.

Come leggere il cruscotto

La situazione: stabile, attenzione o critica

La fascia colorata del Cruscotto riassume il momento con regole fisse, che puoi verificare:

Pronti a chiudere?

Nelle fasi Post-rilascio e Hypercare, l’ultima osservazione dice se l’hypercare può finire. L’app dice “pronto” solo quando vale tutto questo insieme:

• nessun incidente S1 o S2 aperto;
• almeno un criterio di uscita registrato, e tutti soddisfatti;
• nessuna pendenza ad alta priorità aperta con destinazione Hypercare;
• gli incidenti rilevati negli ultimi 3 giorni non superano quelli dei 3 giorni precedenti.

Se manca qualcosa, elenca i motivi. L’app non cambia fase da sola: la decisione spetta alle persone.

Le osservazioni

Le osservazioni sono frasi costruite con le registrazioni: giorni dal rilascio e fino alla fine prevista, totale e aperti per gravità, tendenza degli ultimi 3 giorni, MTTR, MTTA e SLA rispettato, incidenti con SLA superato, giorni senza S1 o S2, componente che concentra gli incidenti, regressioni, riaperture, incidenti senza aggiornamento, pendenze, attività, persone con quattro o più elementi aperti, criteri e azioni aperte.

Come interpretare i numeri

• MTTR alto con pochi incidenti di solito dipende da un caso lungo. Apri l’elenco e guarda quale alza la media.
• Un componente con metà degli incidenti richiede una conversazione con chi lo segue, e forse una pendenza di miglioramento.
• Molte regressioni indicano i test prima del rilascio. È un tema per il post-mortem.
• Molti “senza aggiornamento” indicano incidenti fermi o che nessuno registra l’avanzamento. Entrambi i casi meritano attenzione.
• Incidenti in aumento verso la fine prevista sono il segnale più forte per estendere l’hypercare.

Lo SLA rispettato è calcolato solo sugli incidenti già risolti. Quelli aperti oltre il limite compaiono a parte, nell’indicatore e in “Richiede attenzione”.

Buone pratiche ed errori comuni

Buone pratiche

• Concorda i criteri di uscita prima del rilascio. Discutere i criteri con il sistema già in produzione diventa una trattativa sulle scadenze. ^{[5] [6]}
• Registra l’ora reale del rilevamento. Inserire l’incidente ore dopo, con l’ora dell’inserimento, fa sembrare lo SLA migliore di com’era.
• Almeno un aggiornamento al giorno per ogni incidente aperto. La segnalazione “senza aggiornamento” aiuta a ricordarlo.
• Follow-up brevi e frequenti. Ogni giorno nella prima settimana, poi secondo la tendenza. Usa l’ordine del giorno suggerito e chiudi ogni riunione con azioni che abbiano responsabile e scadenza.
• Esporta il JSON alla fine di ogni giornata. I dati vivono nel browser; il JSON è la tua copia.

Errori comuni

• “Registro tutto come incidente.”

  Miglioramenti e domande sono pendenze. Troppi incidenti distorcono l’MTTR e nascondono i problemi reali.

• “Metto tutto S1 per essere servito prima.”

  Quando tutto è critico, niente lo è. Il cruscotto resta rosso sempre e perde il valore di allarme.

• “Il tempo è scaduto, quindi l’hypercare è finito.”

  La fine prevista è una data; la chiusura dipende dai criteri. Se non sono soddisfatti, estendi e registra la decisione.

• “Il post-mortem serve a trovare il responsabile.”

  Un post-mortem che cerca colpevoli fa nascondere informazioni, e le cause reali restano senza rimedio. ^[2]

• “Chiudo l’incidente e ne apro uno uguale.”

  Se il problema è tornato, riapri lo stesso. Così la riapertura viene contata e lo storico resta intero.

Prompt per accelerare il lavoro

I prompt qui sotto usano ciò che l’app produce: il verbale, il JSON e i testi degli incidenti. Sostituisci le parti tra parentesi quadre. Per scrivere prompt migliori, vedi il tutorial sui prompt di questo sito. ^[7]

Prima di incollare: incidenti e verbali contengono spesso nomi di clienti, dati di utenti e dettagli dell’infrastruttura. Sostituiscili con dati fittizi e segui la politica della tua organizzazione sull’uso dell’IA. L’app non invia nulla in rete, ma il servizio di IA riceve ciò che incolli.

1. Criteri di uscita per il tuo sistema

Sto per mettere in produzione [descrivi il sistema, gli utenti e le integrazioni].
Proponi da 5 a 8 criteri di uscita dall'hypercare.
Ogni criterio deve essere verificabile, con un numero e un periodo (es.: "tasso di errore sotto lo 0,5% per 3 giorni di fila").
Includi criteri tecnici, di supporto e di business.
Per ciascuno, indica da dove viene il dato e chi lo conferma.
Non inventare valori del mio sistema: quando non lo sai, scrivi [definire].

2. Scrivere un incidente chiaro

Qui sotto c'è la descrizione di un problema, così come è arrivata dall'utente.
Riscrivila per registrarla come incidente, con:
- un titolo di massimo 80 caratteri che dica cosa non funziona e dove;
- una descrizione di massimo 5 righe: cosa succede, da quando, chi è coinvolto, come riprodurlo;
- la gravità suggerita (da S1 a S4) e il motivo, usando questa scala: [incolla la scala del tuo team];
- le domande ancora senza risposta.
Non inventare fatti che non sono nel testo.

Testo: [incolla qui]

3. Sintesi per la direzione a partire dal verbale

Qui sotto c'è il verbale generato dall'app Hypercare (dati anonimizzati).
Scrivi una sintesi per [direzione / area di business], in massimo 150 parole:
situazione generale, cosa è migliorato, cosa preoccupa, decisioni e cosa ci serve da loro.
Usa solo i numeri del verbale. Non arrotondare né stimare numeri che non ci sono.

Verbale: [incolla qui]

4. Bozza del post-mortem

Qui sotto c'è il JSON esportato dall'app Hypercare (dati anonimizzati).
Aiutami a preparare il post-mortem senza colpevoli:
1. Raggruppa gli incidenti per causa probabile e indica quali dati sostengono ogni gruppo.
2. Proponi testi brevi per "Cosa ha funzionato" e "Cosa non ha funzionato".
3. Suggerisci fino a 5 azioni di miglioramento, ognuna legata a un gruppo di incidenti.
Descrivi processi e sistemi, mai persone.
Segna come [ipotesi] tutto ciò che non è nei dati.

JSON: [incolla qui]

Controlla sempre ciò che l’IA restituisce. I numeri dell’app vengono dalle registrazioni; quelli dell’IA possono essere inventati.

Dati, esportazione e documenti

I PDF usano la finestra di stampa del browser: scegli Salva come PDF come destinazione. I documenti HTML si aprono in qualsiasi browser e non dipendono dall’app.

Importare

⬆ Importa JSON sostituisce i dati attuali con quelli del file. Esporta prima, se vuoi conservare ciò che è sullo schermo. I file che non sono JSON dell’app vengono rifiutati con un avviso.

Limiti e soluzione dei problemi

• Un progetto per browser. Per seguire due rilasci, usa browser o profili diversi, oppure alterna tramite il JSON.
• Non è multiutente. Due persone non modificano lo stesso progetto contemporaneamente. Concordate chi registra e fate circolare il JSON o i documenti.
• Nessuna integrazione con strumenti di ticketing o di monitoraggio. Gli incidenti si digitano nell’app.
• Cancellare i dati del browser elimina il progetto. Anche la navigazione in incognito non conserva nulla dopo la chiusura. Esporta il JSON.
• Orari nel fuso del computer. I calcoli usano l’orologio e il fuso della macchina. Team in fusi diversi devono concordare il riferimento.

Glossario

Ripasso rapido

Riferimenti

1. Giovani Perotto Mesquita, “Hypercare”, app di questo sito, giovanipm.github.io/hypercare.html.
2. John Lunney e Sue Lueder, “Postmortem Culture: Learning from Failure”, cap. 15 di Site Reliability Engineering, O’Reilly/Google, 2016, consultato il 12/11/2026, sre.google/sre-book/postmortem-culture.
3. Atlassian, “Common incident management metrics”, consultato il 12/11/2026, atlassian.com/incident-management/kpis/common-metrics.
4. ERP Research, “What is Hypercare?”, glossario ERP, consultato il 12/11/2026, erpresearch.com/glossary/hypercare.
5. Panorama Consulting Group, “ERP Hypercare Checklist to Help You Stabilize Fast”, consultato il 12/11/2026, panorama-consulting.com.
6. Eric Klimuk, “What Is Hypercare? Definition, Timeline & Exit Criteria for B2B Support Teams”, Supportbench, 2026, consultato il 12/11/2026, supportbench.com. I riferimenti da 4 a 6 vengono da fornitori e società di consulenza, non da una norma. Concordano che l’hypercare è a tempo e finisce con criteri concordati, ma divergono sulla durata tipica: da 2 a 8 settimane per ERP Research, da 2 a 6 settimane per Supportbench e “diverse settimane”, secondo la complessità, per Panorama.
7. Giovani Perotto Mesquita, tutorial sui prompt di questo sito, giovanipm.github.io/PromptTutorial.html.

Qué es el app Hypercare

El despliegue terminó, el sistema nuevo está en producción y empieza la parte que nadie ve en el cronograma: comprobar que todo funciona, atender los primeros tickets, corregir lo que se escapó de las pruebas y decidir cuándo el equipo del proyecto puede entregar el sistema a soporte. Este período de soporte reforzado y con plazo definido se llama hypercare. ^{[4] [5]}

El app Hypercare organiza ese período en un único archivo HTML. ^[1] Registras las actividades del post-despliegue, los incidentes con severidad y SLA, los pendientes que quedaron y las reuniones de seguimiento. El app calcula los tiempos de respuesta y de resolución, señala lo que requiere atención, sugiere la agenda de la reunión, dice si ya se puede cerrar el hypercare y arma el post-mortem y la documentación.

Abrir el app Hypercare →

Cómo trata el app tus datos

• Los datos quedan en el navegador. Cada cambio se guarda solo en el almacenamiento local del navegador, en el mismo equipo. No hay botón Guardar para el proyecto.
• Nada sale a la red. El app no usa servidor, cuenta ni biblioteca externa, y la política de seguridad del propio archivo bloquea las conexiones.
• Las copias y los traspasos se hacen con JSON. Para guardar una versión, llevar el proyecto a otro equipo o pasarlo a un colega, exporta el JSON e impórtalo del otro lado.
• Cuatro idiomas. La interfaz está en portugués, inglés, italiano y español. Cambia en el selector de arriba. Un enlace que termina en #en, #it o #es ya abre en ese idioma.
• Tema claro y oscuro. El botón ◐ cambia el tema, y el app recuerda la elección.

Conceptos en cinco minutos

Las cuatro fases

El app sigue el proyecto en cuatro fases. Pasas de una a otra con el botón Avanzar a … → del Panel, y el app registra la fecha y la hora de cada cambio.

Actividad, incidente y pendiente

Son tres tipos de registro, y confundirlos es el error más común.

• Actividad es trabajo planificado: algo que se sabía que había que hacer, como “Ejecutar smoke tests en producción”. Tiene fase, responsable, plazo y estado (por hacer, en curso, bloqueada, terminada, no aplica).
• Incidente es algo que no debería haber pasado: un error, lentitud, un dato equivocado. Tiene severidad, horarios y SLA. El reloj empieza en la detección.
• Pendiente es algo por resolver que ahora no detiene a nadie: una mejora, un ajuste de configuración, una documentación, una decisión. Tiene tipo, prioridad, plazo y destino (resolver en el hypercare o traspasar a soporte). Un pendiente puede nacer de un incidente.

Severidad y SLA

Cada incidente recibe una severidad de S1 (crítico) a S4 (bajo), y cada severidad tiene dos plazos: el de respuesta (hasta que alguien empieza a atenderlo) y el de resolución. Los valores de abajo son los predeterminados del app, y puedes cambiarlos en la pestaña Proyecto según el acuerdo de tu organización. Son un punto de partida, no una norma.

El ciclo de vida de un incidente, MTTA y MTTR

Cuando el estado sale de Abierto, el app completa el Inicio de atención. Cuando llega a Resuelto o Cerrado, completa el Resuelto el. También puedes escribir esos horarios en el formulario, por ejemplo para registrar un incidente que ocurrió de madrugada.

Con esos horarios el app calcula dos promedios. El MTTA (mean time to acknowledge) es el tiempo medio entre la detección y el inicio de la atención. El MTTR es el tiempo medio entre la detección y la resolución. La sigla MTTR tiene varios significados en el sector (recuperar, reparar, responder, resolver), así que conviene decir cuál se usa. ^[3] En este app, MTTR es siempre de la detección a la resolución.

Criterios de salida

El hypercare termina cuando se cumplen condiciones acordadas antes, no solo cuando se acaba el plazo. ^{[5] [6]} Un proyecto nuevo empieza con cuatro criterios, que puedes editar: ningún incidente S1 o S2 abierto desde hace al menos 5 días; pendientes de prioridad alta resueltos o traspasados; monitoreo y alertas validados en producción; equipo de soporte capacitado y con runbook.

Post-mortem sin culpables

El post-mortem registra qué pasó, el impacto, las causas y las acciones para que no se repita. Es sin culpables (blameless): busca las causas en los procesos, los sistemas y las decisiones, sin acusar a personas, porque quien teme un castigo oculta información. ^[2] El app muestra este recordatorio arriba de la pestaña Post-mortem.

Paso a paso

El recorrido de abajo cubre un hypercare completo, del despliegue al cierre. Si solo quieres conocer el app, haz el paso 1 y recorre las pestañas.

Paso 1. Conoce el app con el ejemplo

1. Abre el app y haz clic en Cargar ejemplo.
2. El app carga el proyecto ficticio “Nuevo portal de pedidos B2B”, desplegado nueve días antes de hoy, con 8 incidentes, pendientes, actividades, dos seguimientos y criterios de salida. Las fechas acompañan el día en que abres el ejemplo.
3. Recorre las pestañas. Cuando termines, ve a Proyecto → Borrar todos los datos para empezar el tuyo.

Paso 2. Empieza tu proyecto

1. En la pantalla inicial, completa Nombre del proyecto, Sistema / servicio, Versión (release), Fecha y hora del despliegue, Fin previsto del hypercare y Responsable del hypercare.
2. Haz clic en Empezar. El proyecto nace en la fase Post-despliegue, con cuatro criterios de salida y cinco actividades de post-despliegue, todas por hacer, con plazo al día siguiente del despliegue.

Paso 3. Ajusta el SLA y los criterios de salida

1. Abre la pestaña Proyecto. En SLA por severidad, cambia los plazos de respuesta y de resolución si tu acuerdo es otro, y haz clic en Aplicar.
2. En el mismo cuadro, ajusta Marcar incidentes sin actualización después de (h). El valor predeterminado es 24 horas.
3. En Criterios de salida del hypercare, borra lo que no sirve con ×, escribe criterios nuevos en el campo y haz clic en + Criterio. Los buenos criterios se pueden verificar: “tasa de error de la API por debajo del 0,5% durante 3 días seguidos” es mejor que “sistema estable”.

Paso 4. Ejecuta el checklist del post-despliegue

1. Abre la pestaña Actividades. Ahí están las cinco actividades predeterminadas.
2. Haz clic en una actividad para abrir el formulario. Completa el responsable, ajusta el plazo y cambia el estado a En curso o Terminada. Haz clic en Guardar.
3. Para agregar otra, usa + Actividad. Elige la fase: las actividades del hypercare también van aquí, como “Actualizar el runbook con los incidentes del hypercare”.
4. Si algo impide avanzar, marca Bloqueada: el elemento pasa a “Requiere atención” en el Panel y entra en la agenda del seguimiento.
5. Con el checklist hecho, vuelve al Panel y haz clic en Avanzar a Hypercare →. Confirma. La fecha y la hora aparecen en la fila de fases.

Paso 5. Registra un incidente

1. Abre la pestaña Incidentes y haz clic en + Incidente.
2. Escribe un Título que cualquiera entienda (“El ERP rechaza pedidos con descuento progresivo”), la Severidad, el Componente, el Responsable y el Detectado el, que es cuando se notó el problema, no cuando lo estás escribiendo.
3. Marca Regresión causada por el despliegue si algo que funcionaba dejó de funcionar con la versión nueva.
4. Describe el problema y, si la hay, la Solución temporal. Haz clic en Guardar.

Paso 6. Atiende y resuelve el incidente

1. En la lista de incidentes, haz clic en la fila (o llega con Tab y pulsa Enter).
2. Cambia el estado a En análisis. Escribe en el campo Nueva actualización qué cambió y el próximo paso. Guarda. La nota va al Historial con fecha y hora.
3. Si encuentras una salida provisoria, usa Con solución temporal: el usuario puede trabajar, pero la causa aún no se corrigió.
4. Cuando lo corrijas, completa Causa raíz y Solución, cambia a Resuelto y guarda. Tras la confirmación del usuario, usa Cerrado.
5. Si el problema vuelve, regresa el estado a uno activo. El app borra la hora de resolución, marca el incidente como reabierto y cuenta la reapertura en el post-mortem.

Paso 7. Registra pendientes

1. Abre la pestaña Pendientes y haz clic en + Pendiente.
2. Elige el Tipo (corrección, mejora, configuración, datos, documentación, capacitación, decisión), la Prioridad y el Destino: Hypercare, si hay que resolverlo antes de cerrar, o Soporte, si puede quedar para el equipo que asume después.
3. En Incidente de origen, vincula el pendiente al incidente que lo creó, si lo hay. Así el post-mortem muestra de dónde vino cada pendiente.
4. Al pasar el elemento al equipo de soporte, usa el estado Traspasado a soporte: sale del conteo de abiertos y aparece en el post-mortem como traspasado.

Paso 8. Conduce la reunión de seguimiento

1. Abre la pestaña Seguimientos y haz clic en + Nueva. Ajusta el título, la fecha y los participantes.
2. Los indicadores de arriba se comparan con la reunión anterior: 3 +2 quiere decir 3 incidentes abiertos, 2 más que en el último seguimiento.
3. Sigue la Agenda sugerida: incidentes graves y con SLA incumplido, elementos bloqueados y atrasados, incidentes sin actualización, situación de los criterios de salida y acciones pendientes de reuniones anteriores.
4. En Actualización rápida, cambia el estado de cada elemento ahí mismo y escribe la nota en el campo de al lado. La nota se guarda al pulsar Enter y va al historial del elemento.
5. Escribe las Notas y las Decisiones (una por línea). En Acciones, usa + Acción para registrar qué se hará, quién y para cuándo.
6. Al final, haz clic en 📝 Generar acta para copiar o descargar el texto, en 📄 PDF de la reunión para guardar el PDF desde la ventana de impresión, o en ⬇ Informe HTML.

Paso 9. Decide si el hypercare puede terminar

1. En la pestaña Proyecto, marca los criterios de salida ya cumplidos. El app graba la fecha de cada uno.
2. En el Panel, lee el último punto de las Observaciones. Dice “Listo para cerrar el hypercare” o enumera lo que falta.
3. Con los criterios cumplidos y el acuerdo de quien responde por el sistema, haz clic en Avanzar a Post-mortem →.

Paso 10. Escribe el post-mortem

1. Abre la pestaña Post-mortem. Los indicadores de arriba ya están calculados: incidentes en el período, MTTR, SLA, regresiones, pendientes y criterios.
2. Completa Resumen, Impacto en el negocio y en los usuarios, Qué funcionó, Qué no funcionó, Causas raíz y Lecciones aprendidas. El texto se guarda al salir de cada campo.
3. Revisa la Línea de tiempo, armada sola con el despliegue, los cambios de fase, los incidentes y las resoluciones.
4. Registra las Acciones de mejora con responsable y plazo.
5. Elige la Decisión: cerrar el hypercare, extenderlo hasta una fecha o revertir el despliegue. Escribe la justificación y la aprobación.
6. Genera el 📄 PDF del post-mortem o el ⬇ Documento del post-mortem (HTML) y hazlo circular.

Paso 11. Cierra y guarda

1. En el Panel, haz clic en Avanzar a Cerrado →.
2. En ⬇ Exportar, descarga la 📘 Documentación completa (HTML) o la versión PDF, y el JSON (respaldo completo). Guarda ambos con la documentación del proyecto.

Las pestañas del app

Teclado: las flechas ← y → cambian de pestaña cuando el foco está en la barra de pestañas; Enter abre la fila de la lista con foco; Esc cierra el formulario.

Cómo leer el panel

La situación: estable, atención o crítica

La franja de color del Panel resume el momento con reglas fijas, que puedes comprobar:

¿Listo para cerrar?

En las fases Post-despliegue e Hypercare, la última observación dice si el hypercare puede terminar. El app solo dice “listo” cuando todo esto se cumple a la vez:

• ningún incidente S1 o S2 abierto;
• al menos un criterio de salida registrado, y todos cumplidos;
• ningún pendiente de prioridad alta abierto con destino Hypercare;
• los incidentes detectados en los últimos 3 días no superan a los de los 3 días anteriores.

Si falta algo, enumera los motivos. El app no cambia de fase solo: la decisión es de las personas.

Las observaciones

Las observaciones son frases armadas con los registros: días desde el despliegue y hasta el fin previsto, total y abiertos por severidad, tendencia de los últimos 3 días, MTTR, MTTA y SLA cumplido, incidentes con SLA incumplido, días sin S1 ni S2, componente que concentra incidentes, regresiones, reaperturas, incidentes sin actualización, pendientes, actividades, personas con cuatro o más elementos abiertos, criterios y acciones abiertas.

Cómo interpretar los números

• MTTR alto con pocos incidentes suele venir de un caso largo. Abre la lista y mira cuál sube el promedio.
• Un componente con la mitad de los incidentes pide una conversación con quien lo cuida, y quizás un pendiente de mejora.
• Muchas regresiones apuntan a las pruebas previas al despliegue. Es tema para el post-mortem.
• Muchos “sin actualización” indican incidentes detenidos o que nadie registra el avance. Ambos casos merecen atención.
• Incidentes en alza al final del plazo son la señal más fuerte para extender el hypercare.

El SLA cumplido se calcula solo sobre incidentes ya resueltos. Los abiertos con el plazo vencido aparecen aparte, en el indicador y en “Requiere atención”.

Buenas prácticas y errores comunes

Buenas prácticas

• Acuerda los criterios de salida antes del despliegue. Discutir criterios con el sistema ya en producción se convierte en una negociación de plazos. ^{[5] [6]}
• Registra la hora real de la detección. Cargar el incidente horas después, con la hora de la carga, hace que el SLA parezca mejor de lo que fue.
• Al menos una actualización por día en cada incidente abierto. La marca “sin actualización” ayuda a recordarlo.
• Seguimientos cortos y frecuentes. Diarios en la primera semana, después según la tendencia. Usa la agenda sugerida y cierra cada reunión con acciones que tengan responsable y plazo.
• Exporta el JSON al final de cada día. Los datos viven en el navegador; el JSON es tu copia.

Errores comunes

• “Registro todo como incidente.”

  Las mejoras y las dudas son pendientes. Demasiados incidentes distorsionan el MTTR y esconden los problemas reales.

• “Pongo todo en S1 para que me atiendan antes.”

  Cuando todo es crítico, nada lo es. El panel queda en rojo todo el tiempo y pierde su valor de alerta.

• “Se acabó el plazo, entonces se acabó el hypercare.”

  El fin previsto es una fecha; el cierre depende de los criterios. Si no se cumplieron, extiende y registra la decisión.

• “El post-mortem sirve para encontrar al responsable.”

  Un post-mortem que busca culpables hace que la gente oculte información, y las causas reales quedan sin tratar. ^[2]

• “Cierro el incidente y abro otro igual.”

  Si el problema volvió, reabre el mismo. Así la reapertura se cuenta y el historial queda completo.

Prompts para acelerar el trabajo

Los prompts de abajo usan lo que produce el app: el acta, el JSON y los textos de los incidentes. Reemplaza las partes entre corchetes. Para escribir mejores prompts, consulta el tutorial de prompts de este sitio. ^[7]

Antes de pegar: los incidentes y las actas suelen tener nombres de clientes, datos de usuarios y detalles de infraestructura. Reemplázalos por datos ficticios y sigue la política de tu organización sobre el uso de IA. El app no envía nada a la red, pero el servicio de IA recibe lo que pegues.

1. Criterios de salida para tu sistema

Voy a poner en producción [describe el sistema, los usuarios y las integraciones].
Propón de 5 a 8 criterios de salida del hypercare.
Cada criterio debe ser verificable, con un número y un período (p. ej.: "tasa de error por debajo del 0,5% durante 3 días seguidos").
Incluye criterios técnicos, de soporte y de negocio.
Para cada uno, di de dónde sale el dato y quién lo confirma.
No inventes valores de mi sistema: cuando no lo sepas, escribe [definir].

2. Escribir un incidente claro

Abajo está la descripción de un problema, tal como llegó del usuario.
Reescríbela para registrarla como incidente, con:
- un título de hasta 80 caracteres que diga qué falla y dónde;
- una descripción de hasta 5 líneas: qué pasa, desde cuándo, a quién afecta, cómo reproducirlo;
- la severidad sugerida (S1 a S4) y el motivo, usando esta escala: [pega la escala de tu equipo];
- las preguntas que faltan responder.
No inventes hechos que no estén en el texto.

Texto: [pega aquí]

3. Resumen ejecutivo a partir del acta

Abajo está el acta generada por el app Hypercare (datos anonimizados).
Escribe un resumen para [dirección / área de negocio], en hasta 150 palabras:
situación general, qué mejoró, qué preocupa, decisiones y qué necesitamos de ellos.
Usa solo los números del acta. No redondees ni estimes números que no estén ahí.

Acta: [pega aquí]

4. Borrador del post-mortem

Abajo está el JSON exportado del app Hypercare (datos anonimizados).
Ayúdame a preparar el post-mortem sin culpables:
1. Agrupa los incidentes por causa probable y di qué datos sostienen cada grupo.
2. Propón textos cortos para "Qué funcionó" y "Qué no funcionó".
3. Sugiere hasta 5 acciones de mejora, cada una ligada a un grupo de incidentes.
Describe procesos y sistemas, nunca personas.
Marca como [hipótesis] todo lo que no esté en los datos.

JSON: [pega aquí]

Revisa siempre lo que devuelva la IA. Los números del app vienen de los registros; los de la IA pueden ser inventados.

Datos, exportación y documentos

Los PDF usan la ventana de impresión del navegador: elige Guardar como PDF como destino. Los documentos HTML abren en cualquier navegador y no dependen del app.

Importar

⬆ Importar JSON reemplaza los datos actuales por los del archivo. Exporta antes si quieres conservar lo que está en pantalla. Los archivos que no son el JSON del app se rechazan con un aviso.

Limitaciones y solución de problemas

• Un proyecto por navegador. Para seguir dos despliegues, usa navegadores o perfiles distintos, o alterna mediante el JSON.
• No es multiusuario. Dos personas no editan el mismo proyecto a la vez. Acuerden quién registra y hagan circular el JSON o los documentos.
• No se integra con herramientas de tickets ni de monitoreo. Los incidentes se escriben en el app.
• Borrar los datos del navegador borra el proyecto. La ventana privada tampoco guarda nada al cerrarse. Exporta el JSON.
• Horarios en la zona horaria del equipo. Los cálculos usan el reloj y la zona de la máquina. Equipos en zonas distintas deben acordar la referencia.

Glosario

Repaso rápido

Referencias

1. Giovani Perotto Mesquita, “Hypercare”, app de este sitio, giovanipm.github.io/hypercare.html.
2. John Lunney y Sue Lueder, “Postmortem Culture: Learning from Failure”, cap. 15 de Site Reliability Engineering, O’Reilly/Google, 2016, consultado el 12/11/2026, sre.google/sre-book/postmortem-culture.
3. Atlassian, “Common incident management metrics”, consultado el 12/11/2026, atlassian.com/incident-management/kpis/common-metrics.
4. ERP Research, “What is Hypercare?”, glosario de ERP, consultado el 12/11/2026, erpresearch.com/glossary/hypercare.
5. Panorama Consulting Group, “ERP Hypercare Checklist to Help You Stabilize Fast”, consultado el 12/11/2026, panorama-consulting.com.
6. Eric Klimuk, “What Is Hypercare? Definition, Timeline & Exit Criteria for B2B Support Teams”, Supportbench, 2026, consultado el 12/11/2026, supportbench.com. Las referencias 4 a 6 provienen de proveedores y consultoras, no de una norma. Coinciden en que el hypercare tiene plazo y termina por criterios acordados, pero difieren en la duración típica: de 2 a 8 semanas para ERP Research, de 2 a 6 semanas para Supportbench y “varias semanas”, según la complejidad, para Panorama.
7. Giovani Perotto Mesquita, tutorial de prompts de este sitio, giovanipm.github.io/PromptTutorial.html.