REQVERA
The Honest No · Decision note 05

The RFP asks for 24/7 support. Your team works business hours.

Illustrative situation · Not a customer case
The buyer’s question

Confirm that you provide 24/7 support with a one-hour response for critical incidents.

Break the request into staffed coverage, incident eligibility and the response clock. If any required element is absent, the complete answer is not Yes. An always-open portal or an infrastructure provider's support plan does not create your own 24/7 customer service.

A response to adapt

We do not currently provide the requested 24/7 staffed support service for [proposed product and plan]. Our contracted coverage is [days, start/end time, named time zone and holiday treatment], through [supported channels]. For [defined critical-incident category], our approved commitment is [initial-response target and whether it uses elapsed or business time], measured from [valid notification event]. This is an initial-response commitment, not a guaranteed resolution time. Outside those coverage hours, [verified current behaviour; do not imply staffed response if tickets are only queued]. [Only if approved and operationally available: We can offer [precisely scoped out-of-hours option] for [eligible incidents], subject to [contract, activation lead time and commercial conditions].] If continuous staffed support with a one-hour elapsed-time response is mandatory, our current service does not meet that requirement. Please confirm through [authorised channel] whether [specified alternative coverage] may be considered. We will not represent it as compliant without the required buyer decision.

Replace every bracketed field with verified facts. Remove any optional sentence you cannot substantiate. Do not submit this wording unchanged.

What makes the wording defensible

Disclose the support coverage gap without confusing uptime, monitoring or an always-open ticket form with a staffed, contractual response service.

  • Separate four services that sound deceptively similar

    Service availability, automated monitoring, incident notification and human support are separate commitments. Your platform may run continuously while support is unstaffed overnight. An alert can be generated without anyone investigating it. A portal may accept cases all day while the response clock starts at the next opening. Name the actual service instead of allowing the phrase “24/7” to cover all four.

  • Make the clock testable

    Record the start event, elapsed or business hours, severity definition, channel and exceptions. Is one hour measured from an email, a telephone call or a valid ticket with diagnostic information? Who can declare a critical incident? A Friday evening example often exposes the difference immediately: write down when acknowledgement, qualified triage and the next update would actually occur under the proposed terms.

  • Do not inherit your supplier's promise

    AWS's own documentation distinguishes round-the-clock technical support, severity-specific first-response targets and the scope of a support plan. Those are AWS commitments to its eligible customer, not proof of your customer-facing coverage. Your service can still need application diagnosis, access approval and customer communication before or after supplier escalation. Show who owns that handoff rather than copying the upstream plan's headline.

Trace the incident, not the marketing promise

Walk one genuine critical-incident scenario through these boundaries. Any unowned interval is a gap to disclose or resolve before commitment.

Notification
Which channel is accepted, what information is required and what event starts the promised clock?
Qualified response
Who can assess the application's incident within the stated coverage hours, rather than merely acknowledge receipt?
Supplier escalation
Who can engage the dependency, under which contracted support plan, while keeping customer ownership with your team?
Recovery and updates
What is actually committed for restoration, resolution and communications? Do not imply these share the first-response deadline.

The evidence to obtain

  • The actual service schedule

    Obtain the support policy and contractual schedule for the precise plan being sold. Check days, holidays, time zone, seasonal clock changes, language and channels. Align the proposal's response target with the contract rather than a website headline. If the commercial proposal adds out-of-hours coverage, verify that it is priced, approved and available by the buyer's required start date.

  • A workable incident handoff

    The support lead should confirm who receives a qualifying incident, who has access to investigate, who can contact infrastructure providers and who updates the buyer. Test an out-of-hours notification against the real arrangement without sending a customer incident. An on-call rota alone is insufficient if the person cannot reach the relevant system or authorised decision maker.

  • The buyer's acceptable deviation

    Retain the exact clause and authorised clarification. If an alternative is permitted, document whether it changes coverage, severity, response measurement, price or mobilisation. Do not assume a discussion with the account sponsor changes mandatory tender conditions. The approval must be reflected in the permitted response and contractual documents, with the unresolved gap still visible until that occurs.

The decision to approve

Decision owners
The support or service-delivery lead owns operational feasibility. The commercial owner approves cost and mobilisation; the legal reviewer checks commitments; the Bid Manager manages the buyer's permitted exception route.
Proceed
Proceed with the precisely scoped support service only when it satisfies the request or the authorised buyer decision permits the disclosed alternative. Keep initial response, restoration and resolution commitments distinct.
Do not proceed
If mandatory continuous staffed coverage is unavailable, do not confirm 24/7 support on the strength of monitoring, queued tickets, an informal promise or an upstream provider's plan.
Escalate
Escalate if the proposed option requires new staffing, new supplier terms, exceptional access or a mobilisation date that is not approved. A future operating model is not today's capability.

Keep the decision in the final files

Compare the questionnaire, support matrix, price schedule, service-level attachment and any approved exception. They should agree on coverage, severity, timing and start date. This is where an approved narrow answer can be undermined by a broad promise elsewhere in the final files. REQVERA is positioned as a final control layer, not as a support service or a negotiator of exceptions.

See the authentic final-control workflow

Scope & primary references

Illustrative operational guidance, not a statement of REQVERA's support offering. The AWS example illustrates distinctions in a provider's published support terms; it does not supply terms for another vendor. Buyer procedure and enforceability require review of the actual documents. Replace all bracketed fields with approved, current facts.