Skip to content

Support tiers

Venturi support is tiered, least-privilege, and fully audited. Every published response and uptime commitment traces to an instrumented service-level objective, and Venturi support has no standing access to your tenant; any investigation runs under a time-boxed, customer-approved, fail-closed grant.

What governs your support experience

  • Your support tier sets the response targets and escalation path.
  • Every commitment is traceable to a measured SLO; Venturi never publishes a number it does not instrument.
  • Support access is break-glass only: customer-approved, time-boxed, MFA-gated, audited, and incapable of crossing your tenant boundary.

Tiers at a glance

Tier Sev-1 response Sev-2 / Sev-3 response Uptime commitment Escalation path
Standard Best-effort, business hours Next business day 99.9% serving plane; AI traffic never blocked (fail-open) CS → on-call (post-milestone)
Premium 15-min MTTA target (post on-call milestone) 4 business hours 99.9% serving plane; 99.95% step-up at milestone Named CS + escalation manager
Regulated 15-min MTTA target; residency-aware 4 business hours 99.9% serving plane + residency objectives Dedicated channel + break-glass governance

Which tier attaches to your contract is a commercial term, agreed during procurement.

The 15-minute Sev-1 target is milestone-scoped

The Sev-1 mean-time-to-acknowledge target of 15 minutes and the 99.95% availability step-up are scoped to Venturi’s first dedicated on-call coverage milestone, and are not advertised before it is in place. Venturi labels forward commitments as forward; it never implies a 24/7 SLA it cannot yet staff. See SLAs & SLOs.

Every commitment is traceable to an SLO

A support tier is not a list of aspirations. Each response-time and uptime commitment maps to a named indicator in Venturi’s SLO catalog, so you can always trace a contractual promise back to a signal you can observe. The uptime numbers above all derive from the serving-plane 99.9% availability objective; the recovery commitments derive from the RPO ≤ 15 min / RTO ≤ 1 h pair. None of these numbers implies that your AI traffic can be blocked: the 99.9% figure governs Venturi’s own serving surface, and fail-open means Venturi unavailability never blocks your traffic.

Severity and escalation

Venturi classifies issues by customer impact, and the severity sets both the acknowledgement target and the escalation path for your tier.

Severity Definition Acknowledgement target Escalation
Sev-1 Serving plane unavailable, or attribution materially wrong at scale 15-min MTTA (milestone-scoped) Immediate; named escalation manager on Premium/Regulated
Sev-2 Significant degradation: freshness lag, partial coverage loss, sustained heuristic fallback 4 business hours (Premium/Regulated) Owner → role queue → admin
Sev-3 Minor or cosmetic; no material impact on correctness Next business day Standard support queue

Time-bound escalation advances an unacknowledged critical issue through the configured tiers until it is acknowledged, recording the full path and respecting your business calendar. See Status & incidents for the incident lifecycle and degradation states.

Support paths

Path Use it for
Product support Setup, dashboards, exports, and interpretation questions
Technical support Connector failures, API behavior, webhook delivery, deployment issues
Security support Vulnerability disclosure, Trust Center questions, audit evidence
Incident escalation Availability, freshness, or data-quality incidents

How Venturi support access is governed

This is the part security teams care about most: Venturi support has no standing access to your tenant. When an investigation requires access to your environment, it runs under a break-glass grant with hard, fail-closed guardrails.

Target-state: break-glass enforcement

The no-standing-access posture and the guarantees below are the committed design. The enforced approval gate that makes every diagnostic session customer-approved, MFA-gated, and fail-closed in runtime is a Target-state control being wired against the canonical identity model, not yet general. The binding label and gate are in Docs authority & product state.

Support break-glass: the guarantees

  • Customer-approved. Access is requested for a specific tenant and reason, and granted only with a customer admin’s authorization.
  • Time-boxed. The grant carries an expiry and auto-revokes when the window closes.
  • MFA-gated and least-privilege. Scoped to the minimum needed for the case; read-only by default.
  • Fully audited. Every action is written to your immutable audit log, attributable to the support actor, and reviewed after use.
  • Tenant-bound and residency-correct. A break-glass grant can never reach across your tenant boundary or out of your residency region, and it fails closed on any of those checks.

Break-glass is one of the fail-closed surfaces (like authentication, authorization, tenant isolation, export, and billing). The decision-time interceptor’s fail-open allowance for your AI traffic never extends to a support-access decision. For the full step-by-step flow (request → Admin approval → scope/purpose/duration → step-up MFA → ticket-bound session → read-only default → immediate revoke → immutable audit → post-use review) and exactly what is and isn’t visible to Venturi staff before a grant exists, see Support-access architecture. See also Tenant isolation and Residency & subprocessors.

Evidence-linked support cases

A support case is evidence-linked from the moment it opens, so Venturi support can reason from your real state rather than from guesswork. When you open a case about a disputed attribution, the case surfaces, without requiring data access beyond the audited grant, the affected record’s:

  • Evidence basis: the signals that supported the attribution.
  • Output state and operational confidence (coper).
  • Degradation state: whether the result came from the trained model or a fallback.
  • Links to the relevant coverage report, export manifest, and audit entries.

The case also carries your tenant’s lifecycle stage and onboarding-completion status, so support has the context to resolve quickly. See Confidence & evidence for what each field means.

Before opening a ticket

Check Status & incidents, connector freshness in Observability & diagnostics, and the troubleshooting reference. Include request IDs, connector names, timestamps, and affected export or attribution IDs.

To report a security concern, follow the disclosure process in Venturi’s security policy rather than opening a public issue. See Security & compliance.