An incident affecting a website does not automatically affect every underlying token or provider record. Conversely, an apparently normal homepage does not prove that all service functions are operating correctly. ALFA's public communication should be able to describe a specific disruption without either exaggerating its scope or leaving customers to infer the practical consequences from scattered messages.
Name the affected function
A useful notice identifies the action that is unavailable or uncertain, such as viewing order history or submitting a new booking. It should avoid using a broad technical label as a substitute for customer meaning. The person reading needs to know whether they can safely continue, should wait or need to contact the provider about an existing commitment.
Distinguish established facts
The team should separate what it has confirmed from what it is still investigating. A confident claim that no customer was affected should follow evidence, not merely an absence of support messages. At the same time, speculative explanations can create unnecessary alarm. A concise statement of the known boundary gives users a practical basis for deciding their next action.
Preserve a dated history
Updates should show how the understanding changed over time. Replacing the original notice without a trace can make later review difficult, especially for customers whose actions occurred during the incident. A clear history helps support connect an affected order to the relevant period and explains why advice may have changed as the operational team obtained more reliable information.
Close with customer consequences
Restoring a system is only one part of resolution. The team should identify any orders, balances or communications requiring follow-up. For ALFA, an incident report is most useful when it explains that practical work and the current route for affected users. The result should support confidence through specific accountability rather than broad assurances about the ecosystem as a whole.
