O RFP exige suporte 24/7. A sua equipa trabalha em horário de expediente.

As condições que sustentam a resposta

Declare a lacuna na cobertura do suporte sem confundir disponibilidade, monitorização ou um formulário sempre acessível com um serviço de resposta assegurado por pessoas e previsto no contrato.

• Separe quatro serviços que parecem semelhantes

  Disponibilidade do serviço, monitorização automática, notificação de incidentes e suporte humano são compromissos diferentes. A plataforma pode funcionar continuamente sem pessoal de suporte durante a noite. Pode ser gerado um alerta sem que alguém o investigue. Um portal pode aceitar pedidos a qualquer hora, mas o prazo de resposta só começar na abertura seguinte. Identifique o serviço efetivo, em vez de permitir que «24/7» descreva indistintamente os quatro.

• Torne a contagem do prazo verificável

  Registe o evento inicial, as horas corridas ou úteis, a definição de gravidade, o canal e as exceções. A hora conta a partir de um email, de uma chamada ou de um pedido válido com informação de diagnóstico? Quem pode declarar um incidente crítico? Um exemplo à sexta-feira à noite costuma revelar imediatamente a diferença: indique quando ocorreriam a confirmação de receção, a triagem qualificada e a atualização seguinte nas condições propostas.

• Não herde a promessa do seu fornecedor

  A documentação da AWS distingue suporte técnico permanente, objetivos de primeira resposta por gravidade e âmbito do plano de suporte. São compromissos da AWS perante o seu cliente elegível, não comprovativos da sua cobertura ao cliente final. O seu serviço pode ainda exigir diagnóstico da aplicação, autorização de acesso e comunicação com o cliente, antes ou depois de escalar o caso ao fornecedor. Mostre quem responde por essa passagem, em vez de copiar o título do plano de um fornecedor.

Os comprovativos a reunir

• O horário e as condições efetivos do serviço

  Obtenha a política de suporte e as condições contratuais do plano exato vendido. Verifique dias, feriados, fuso horário, mudanças sazonais da hora, língua e canais. Alinhe o objetivo de resposta da proposta com o contrato, não com um título do site. Se a proposta comercial acrescentar cobertura fora de horas, verifique se está orçamentada, aprovada e disponível na data de início exigida pelo comprador.

• Uma passagem de incidente operacionalmente viável

  O responsável de suporte deve confirmar quem recebe um incidente elegível, quem tem acesso para o investigar, quem pode contactar os fornecedores de infraestrutura e quem informa o comprador. Teste uma notificação fora de horas segundo o mecanismo real, sem criar um incidente de cliente. Uma escala de prevenção não basta se a pessoa não consegue aceder ao sistema relevante ou contactar quem tem autoridade de decisão.

• O desvio admissível para o comprador

  Conserve a cláusula exata e o esclarecimento autorizado. Se for permitida uma alternativa, documente se altera cobertura, gravidade, medição do prazo, preço ou mobilização. Não assuma que uma conversa com o patrocinador comercial da conta muda condições obrigatórias do concurso. A aprovação deve refletir-se na resposta permitida e nos documentos contratuais; a lacuna continua visível enquanto isso não acontecer.

A decisão a aprovar

Responsáveis pela aprovação

O responsável de suporte ou de prestação do serviço responde pela viabilidade operacional. O responsável comercial aprova custo e mobilização; o jurídico revê os compromissos; o responsável pela proposta gere o percurso de exceção permitido pelo comprador.

Prosseguir

Avance com o serviço de suporte precisamente delimitado apenas quando satisfaz o pedido ou a decisão autorizada do comprador permite a alternativa declarada. Mantenha distintos os compromissos de primeira resposta, restabelecimento e resolução.

Não prosseguir

Se a cobertura contínua obrigatória com pessoal disponível não existir, não confirme suporte 24/7 com base em monitorização, pedidos em fila, uma promessa informal ou o plano de um fornecedor de infraestrutura.

Solicitar uma decisão

Encaminhe para decisão uma opção que exija nova equipa, novas condições de fornecedores, acesso excecional ou uma data de mobilização não aprovada. Um modelo operacional futuro não é uma capacidade atual.

Preservar a decisão nos ficheiros a apresentar

Compare o questionário, a matriz de suporte, o mapa de preços, o anexo de níveis de serviço e as exceções aprovadas. Devem concordar em cobertura, gravidade, prazos e data de início. É aqui que uma resposta restrita aprovada pode ser contrariada por uma promessa ampla noutro ficheiro final. REQVERA posiciona-se como camada de controlo final, não como serviço de suporte nem como negociador de exceções.

Âmbito e fontes de referência

Orientação operacional ilustrativa, não uma declaração da oferta de suporte de REQVERA. O exemplo AWS ilustra distinções nas condições de suporte publicadas de um fornecedor; não estabelece condições para outro fornecedor. O procedimento do comprador e a força vinculativa dos compromissos exigem a análise dos documentos concretos. Substitua todos os campos entre parênteses retos por factos atuais e aprovados.

• AWS Support — Case management and first-response times

  Exemplo primário que distingue primeira resposta, gravidade, âmbito do plano e suporte técnico permanente. Nenhum objetivo AWS é transposto para este exemplo de resposta de fornecedor; revisto em 11 de outubro de 2026.

• AWS — Support plan comparison

  Demonstra por que a cobertura e os serviços de suporte devem ser verificados no plano aplicável, e não deduzidos da disponibilidade da infraestrutura.