opaige
back to overview
For enterprise·8 min read

Defining visa appointment SLAs for enterprise clients: what to promise and how to back it

Enterprise procurement teams ask for SLAs. 'We'll try our best' doesn't survive a legal review. What a defensible visa-appointment SLA looks like — slot detection time, confirmation rate, escalation thresholds — and how to structure the underlying operations to honour it.

The SLA question your procurement team will ask

< 1 sec
Slot detection latency
Pre-authenticated worker, adaptive cadence
30 sec
Operator escalation SLA
Human console alert on CREDENTIALS_REQUIRED
< 24 hrs
Portal-change recovery target
Absorbed by Opaige — zero action required from you
99.9%
Booking engine uptime target
Measured on the orchestrator, not portal availability

Enterprise procurement teams ask for SLAs as a matter of process. For most software categories, those SLAs are well-defined: uptime percentage, incident response time, support ticket SLA by priority tier. For visa appointment booking, the SLA conversation is harder because the thing you are trying to guarantee — a confirmed appointment — depends on a factor outside anyone's control: whether the portal has an available slot.

This creates a common trap. Vendors in the visa space make two kinds of mistakes: they either refuse to define any SLA ("it depends on the portal") or they over-promise guarantees they cannot back ("100% confirmed in 48 hours"). Both fail the procurement team. The first provides no contractual basis. The second creates liability the vendor cannot absorb when a corridor genuinely goes dark for six weeks.

A defensible visa-appointment SLA is structured around what is measurable and controllable: detection speed, booking execution speed, escalation response time, and system uptime — not the portal's own availability, which is explicitly carved out.

The four components of a credible visa SLA

1
Slot detection latency — the speed guarantee
When a slot opens, how quickly does the system detect it? Target: sub-second on the availability poll. This is the metric that separates monitoring infrastructure from the human-at-keyboard alternative. Define it as: 'when portal availability changes, detection occurs within one polling interval, not to exceed 120 seconds in normal cadence or 15 seconds in burst mode.'
2
Booking execution time — detection to confirmation
Once a slot is detected, how quickly does the booking complete (assuming no OTP delay)? Target: under 10 seconds for the automated booking sequence. OTP-dependent confirmation adds a human-latency component that should be specified separately — typically 'within the portal's hold window, not to exceed 8–10 minutes.'
3
Escalation SLA — human-in-the-loop response time
When the system cannot proceed autonomously — credential failure, unusual portal state, OTP not received — how quickly is a human operator notified and engaged? Target: 30 seconds to operator console alert; 4-minute operator response for active escalations during business hours.
4
System uptime — the orchestrator, not the portal
The booking engine, API, and operator console are what you control. Portal availability is explicitly excluded. Define uptime separately: 'the Opaige booking orchestrator will be available 99.9% of the time, measured monthly, excluding scheduled maintenance windows and third-party portal outages.'

What to carve out — and how to word it

The carve-out that protects both parties
'Slot availability is determined solely by the relevant embassy or visa centre. Opaige guarantees execution speed and system uptime; it does not guarantee slot availability. Where a corridor has no available slots within the customer's preferred window, the booking will remain in WATCHING status until availability returns, at no additional charge to the customer.'
What to promise (in-scope)
What to carve out (out-of-scope)
Slot detection
< 120s cadence, < 15s burst
Portal's decision to release slots
Booking execution
< 10s detection to submission
OTP delivery speed (applicant-dependent)
Escalation response
30s to alert, 4min to engage
Portal downtime / maintenance windows
System uptime
99.9% monthly, orchestrator only
Embassy or visa centre closures
Portal change recovery
< 24h target, absorbed by Opaige
Active booking count during outage window

The SLA conversation with your own enterprise customers

Once your platform embeds Opaige's API, you have a contractual basis for the SLA you present to your own enterprise customers. The structure maps cleanly:

  • You promise: when we submit a visa appointment request, our system will monitor continuously and execute the booking the moment a slot becomes available. You will receive a webhook within seconds of confirmation.
  • You carve out: slot availability is governed by the embassy or visa centre, not by your platform. Average wait times by corridor are published on your status page, updated weekly.
  • You back it with: Opaige's underlying SLAs on detection speed, execution time, and uptime — which you pass through contractually.

This is a more honest and more defensible structure than either "we guarantee it" or "it depends." Procurement teams can sign this. Legal teams can sign this. And it accurately represents what you're actually in control of.

Review the API and SLA docs How EOR platforms embed the API
Keep reading

Related guides

For enterprise
Zero-knowledge credential vaulting: how we protect applicant passports
The threat model for applicant data, per-user envelope encryption, audit logging, and how Opaige's identity vault maps to SOC 2, GDPR, and t…
Read guide
For enterprise
Building a global mobility vertical: why infrastructure beats internal scraping
Total cost of ownership for an in-house visa-booking bot vs licensing Opaige. Engineering headcount, maintenance cadence, legal exposure, an…
Read guide
For enterprise
Standardizing the human-in-the-loop: a protocol for real-time OTP routing
The messy reality of 2FA during automation, the protocol Opaige uses to route codes between portal, worker, and applicant in under 90 second…
Read guide
All guides