Severity and escalation

Prioritize support requests by impact and coordinate production incidents.

Choose priority based on the current effect on your business. Include the affected product, environment, number of workflows affected, and any workaround in your support request.

Priority	AMLOK example	Initial response target
P1 - Critical	Production API is unavailable, or a critical underwriting or monitoring workflow is blocked across your workspace without a workaround.	1 hour, 24/7
P2 - High	A key production integration or report is failing, but a workaround allows operations to continue.	4 business hours
P3 - Normal	An isolated data-mapping issue, non-critical display defect, or development integration question.	1 business day
P4 - Low	How-to guidance, a documentation correction, or a feature request.	2 business days

Business-hour definitions and coverage are in the SLA. A suspected security incident follows the security incident process, including any separate notification requirements.

Incident updates

During an active P1 incident, AMLOK targets hourly progress updates until service is restored or the incident is downgraded. For P2, updates are provided at least once each business day while active investigation continues. P3 and P4 updates accompany material progress, a request for information, or an agreed follow-up.

Updates distinguish confirmed impact, the current action, any workaround, and the next update. A first response is not a promise of a fixed resolution time. If investigation depends on your environment or evidence, provide an available contact and the requested redacted details.

Escalate an existing request

Reply to the existing thread with Escalation requested, the support reference, changed impact, and an available contact. Copy your account manager if known. Use [e-mail] if you cannot reach the assigned contact.

Escalate if a response target has passed, the impact materially increases, a workaround fails, or an incident needs account-level coordination. AMLOK reviews severity and assigns the appropriate technical or account-management owner. Keep related evidence in one thread so ownership and history remain clear.

Recovery and follow-up

After recovery, verify the affected workflow and reconcile unfinished jobs, webhook deliveries, and reports. Retry authorized processing or report requests using the original idempotency key where applicable. Ask support or your enterprise account manager to investigate credit discrepancies. Payment methods and top-ups are managed in the portal; the public reporting API does not initiate payments.

For a material incident, request an incident summary through the same thread. The summary covers confirmed impact, recovery actions, and follow-up measures when the investigation is complete. Customer-specific or security-sensitive details are shared through the appropriate authorized channel.