A complete reference for setting up, configuring, and operating ZantIQ as a customer administrator — covering both technical integration and business workflow setup.
Understanding how ZantIQ structures your organisation's data.
| Layer | Description | Key properties |
|---|---|---|
| Tenant | Your company's isolated ZantIQ workspace. All data is logically separated at tenant level. | Unique tenant_id, plan, billing, SSO config |
| Users | People with access to your tenant. Each user has one role. | Email, role (Admin / Manager / Viewer), SSO identity |
| Customers | Your end customers — the accounts you have contracts with. | customer_id, name, plan, CSM, Salesforce ID, health tier |
| Connectors | Integrations to external systems. Can be scoped to a specific customer or tenant-wide. | connector_id, system, status, is_source, field_map |
| Contracts | PDF/DOCX documents uploaded and parsed by ZantIQ's extraction engine. | Type, status, value, signed date, ingestion status, confidence score |
| Commitments | Individual obligations extracted from contracts (SLAs, seat counts, uptime, etc.). | Type, status (compliant / breach / missing / mismatch), customer link |
All tenant data is logically isolated. ZantIQ does not share data between tenants. Database rows are scoped by tenant_id at every layer and enforced via Row-Level Security (RLS) policies on the backend. If your organisation requires data residency in a specific geography (EU, APAC), contact your ZantIQ account team to discuss dedicated hosting.
Connect ZantIQ to your identity provider so users log in with their corporate credentials.
| Provider | Protocol | Notes |
|---|---|---|
| Okta | SAML 2.0 / OIDC | Use the ZantIQ app tile from the Okta Integration Network |
| Azure Active Directory | SAML 2.0 | Enterprise Application → custom app, then paste ZantIQ metadata URL |
| Google Workspace | SAML 2.0 | Custom SAML app in Admin Console → Apps → Web & Mobile Apps |
| OneLogin | SAML 2.0 | ZantIQ SAML application template available |
| Generic OIDC | OIDC | Any OIDC-compliant IdP; requires client_id, client_secret, discovery URL |
Only Admins can access SSO configuration. You will need your IdP's metadata URL or XML, and ZantIQ's SP metadata to paste into your IdP.
Copy the ACS URL and Entity ID from the SSO setup page. These are the values you paste into your identity provider to register ZantIQ as a service provider.
ZantIQ requires the following SAML attributes to be sent in the assertion:
| Attribute name | Value | Required? |
|---|---|---|
email | User's work email | Yes |
first_name | Given name | Yes |
last_name | Family name | Yes |
role | admin / manager / viewer | Optional (defaults to viewer) |
Paste your IdP's metadata URL or XML into the ZantIQ SSO form and click Test SSO. ZantIQ will perform a test login flow and confirm the attributes received. Once the test passes, click Enable SSO.
Toggle "Require SSO for all users" to block password-based login. Ensure at least one Admin account is confirmed working via SSO before enforcing.
Technical requirements for each supported integration, including required API scopes.
| System | Auth method | Required scopes / permissions |
|---|---|---|
| Salesforce | OAuth 2.0 Connected App | api, refresh_token, offline_access. Read access to Account, Contract, Opportunity objects. |
| Jira | API Token (Cloud) or OAuth 2.0 | Read: Projects, Issues, SLA Policies. Service Management: read:jira-work, read:jira-user. |
| Vitally | API Key | Full API key from Vitally Settings → Integrations → API. Read/write access to Accounts and Traits. |
| Zendesk | API Token + email | Admin role recommended. Required: Tickets (read), Organizations (read/write), SLA Policies (read). |
| HubSpot | Private App Token | CRM scopes: crm.objects.contacts.read, crm.objects.deals.read, crm.schemas.contacts.read. |
| Slack | OAuth Bot Token | channels:read, chat:write, users:read. Install the ZantIQ Slack App from the Slack App Directory. |
| Snowflake | Service Account + Key Pair | Dedicated service account with USAGE on relevant database/schema. ZantIQ uses read-only queries. |
| Stripe | Restricted API Key | Permissions: Customers (read), Subscriptions (read), Invoices (read). Never share your full Secret Key. |
| DocuSign | OAuth 2.0 (JWT Grant) | Integration Key + RSA private key from DocuSign Apps & Keys. Scopes: signature, impersonation. ZantIQ pulls completed envelopes and extracts obligations automatically. |
| Ironclad | API Key | Generated from Ironclad Settings → API & Webhooks. Provide your Ironclad subdomain (e.g., acme.ironcladapp.com). Read access to Workflows and Executed agreements. |
| Product Analytics | ||
| Amplitude | API Key + Secret Key (HTTP Basic) | Generated from Amplitude Settings → Projects → API Keys. Uses the Analytics API — read-only. Required scopes: view users/events for the project(s) you connect. |
| Heap | App ID + API Key | Bearer-token auth. From Heap Account → Manage → Projects, copy the App ID and mint an API key with account-details read. |
| Mixpanel | Service Account (username + secret) | Create a service account in Mixpanel Project Settings → Service Accounts. Provide the Project ID. Uses the Query API (read-only). |
| PostHog | Personal API Key | Bearer-token auth. From PostHog Settings → Personal API Keys. Provide the Project ID and host (default https://us.posthog.com). Read scopes: event:read, feature_flag:read, person:read. |
| Data Warehouse & Pipelines | ||
| BigQuery | OAuth 2.0 (Google) | Provide the GCP project ID. IAM: roles/bigquery.metadataViewer and, if using the optional usage query, roles/bigquery.jobUser plus data-viewer on any dataset the query reads. ZantIQ never runs mutations. |
| Snowflake | OAuth 2.0 or Key-Pair (JWT) | Provide account identifier (e.g. myorg-myacct) and warehouse. Recommended: a dedicated ZANTIQ_READER role with USAGE on warehouses and SELECT on any object your usage query reads. |
| dbt Cloud | Service Token | Generated from dbt Cloud Account Settings → Service Tokens. Permission set: "Read-only" — sufficient to read job run history and status. |
| Fivetran | API Key + Secret (HTTP Basic) | Generated from Fivetran Account → Settings → API Config. Reads groups and connector status only — no mutations. |
| Census | Workspace API Key | From Census Settings → API. Read-only sync + run history. |
| Hightouch | Personal Access Token | From Hightouch Settings → API & Webhooks. Read scope on syncs + runs. |
| Customer Data Platform | ||
| Segment | Public API Personal Access Token | Generated from Segment Workspace → Access Management → Personal Access Tokens. Read scope on sources, destinations, and tracking plans. |
| RudderStack | Workspace Access Token | Generated from RudderStack Cloud → Settings → API Access. Read sources, destinations, and connections. |
| Billing & Payments | ||
| Chargebee | API Key (HTTP Basic) | Provide the Chargebee site name (e.g., acme-test). Read scopes: Customers, Subscriptions, Invoices. Never share your full Master Key. |
| Braintree | Public Key + Private Key | Provide Merchant ID and choose sandbox or production. Uses the GraphQL API. Permissions: read Customers, Subscriptions, Transactions. |
| Zuora | OAuth 2.0 (Client Credentials) | Provide the API host (e.g., https://rest.zuora.com). Recommended role: "API Read-Only" plus read on Subscriptions and Accounts. |
| Business Intelligence | ||
| Looker | API 4.0 access token | Provide the Looker host URL. Generate a client_id + client_secret in Admin → Users → API Keys and exchange them for an access token. Optional: folder_id to scope reads to a customer folder. |
| Tableau | Personal Access Token | From Tableau Server / Cloud → Account Settings. Provide host, site_id, and (optionally) project_id. Read scope on Workbooks and Views. |
| Dev / PM / HR | ||
| GitHub | Fine-grained Personal Access Token | Provide owner and repo. Repository permissions: Contents: read, Deployments: read, Issues: read, Pull requests: read. |
| Asana | Personal Access Token | From Asana Developer Console → Personal Access Tokens. Provide workspace_gid. Scopes: default (read access to projects and tasks in that workspace). |
| BambooHR | API Key | Provide the company subdomain (e.g., acme for acme.bamboohr.com). Reads employee directory only. |
| Workday | OAuth 2.0 | Provide host and tenant. Uses Workday's REST v1 API. Recommended: an integration-system user (ISU) with read-only permissions on Workers and Organizations. |
| Status | Meaning | Action |
|---|---|---|
| Connected | Credentials valid, last sync successful. | None required. |
| Syncing | A sync is currently in progress. | Wait for completion (usually <60 sec). |
| Error | Last sync failed — credentials may have expired or scopes changed. | Re-enter credentials and click Sync. |
| Disconnected | Connector was manually disconnected. | Reconnect when ready. |
How ZantIQ maps contract term fields from the source of truth to downstream systems.
The system that holds the authoritative version of each contract field — typically your CRM (Salesforce or HubSpot). ZantIQ reads from this system and treats it as the "contract truth". Select the source using the Source of Truth dropdown on the Field Mapping page.
All other connected systems (Jira, Zendesk, Vitally, etc.) are potential targets. ZantIQ pushes — or validates — that the source field values match what is configured in each target.
Each rule maps one source field to one target field, with an optional Transform expression (JavaScript) that converts values between systems. Rules have a status of Active or Conflict — a conflict means the current target value does not match what the contract specifies.
Use the two dropdowns below the pipeline header. The canvas updates immediately to show the Source Fields (left panel) and Target Fields (right panel) for the selected pair.
The field row highlights in indigo and the canvas shows the instruction "Now click a target field to map". Click a field in the Target Fields panel to complete the mapping. A bezier line is drawn between the two fields.
The bottom-left panel lists all rules for the current source→target pair. Each row shows source field → target field → transform expression. Hover a row and click the trash icon to delete a rule.
The bottom-right panel shows the sync status and last-sync time for each target system, and flags how many rules have conflicts per system.
eval. Each rule is a JSON list of steps applied left-to-right. Only the operations below are permitted; anything else is rejected at request time.| Op | Args | Effect |
|---|---|---|
identity | — | Pass value through unchanged |
trim | — | Strip whitespace |
toLowerCase | — | Lowercase |
toUpperCase | — | Uppercase |
replace | from, to | Literal string replace |
substring | start, end | Slice by index |
concat | prefix, suffix | Prepend / append literal string |
parseInt / parseFloat | — | Coerce numeric |
Only admins see the Layer 3 Push Config panel at the top of Field Mapping. Toggle push_enabled, list the connectors that accept push in Allowed target connectors, and set a per-connector daily push cap. Layer 3 is off by default.
On a mismatched row, click Push. The 3-step wizard runs a live preview, surfaces server-side warnings (numeric-looking value being replaced, non-empty target about to be overwritten, day-cap approaching), and requires typing PUSH to confirm. Instead of pushing, choose I'll fix it manually + rescan to update the target directly in the vendor UI and then re-verify.
A different admin opens the Push Request Queue. The row is chip-flagged if it is the current user's own request; the API refuses self-approval regardless. On Approve, the server re-reads the live source value and refuses with status stale_source if it has drifted since the request was created.
The Push History timeline shows every push, rescan, and revert. Any successful push has a Request revert button — clicking it creates a new push request that writes the original target value back. A different admin still needs to approve it before the revert lands on the vendor.
sha256(connector|rule|transformed_value|target_value_now) · one-click revert.push_data(): Jira, Zendesk, Freshservice, HubSpot Service, Vitally, Gainsight, PagerDuty, Pylon, Linear, Notion, Slack. Notion writes typed page properties (rich_text / number / url / checkbox). Linear uses GraphQL issueUpdate and projectUpdate. Slack push covers channel.topic, channel.purpose, and message.post. Additional connectors are added on request.
Current triggers: breach.created, breach.status_changed, breach.resolved. commitment.mismatched and obligation.upcoming ship in v2. Every enabled rule for a matching trigger evaluates in parallel per event.
Nested AND / OR / NOT groups over leaf comparators (eq, gte, in, contains, is_null, and more). Fields are dot-paths on the resolved context — e.g. customer.plan, breach.type, customer.arr, commitment.contract_value. Missing fields resolve to None and never raise. Depth ≤ 8, ≤ 64 nodes.
Ordered list. Four action types ship in v1: slack.notify (post to a channel), email.send (transactional email), ticket.open (Jira / Linear / Zendesk / Freshservice), health.set (Vitally / Gainsight health score). Templates use {customer.name}-style interpolation from context; missing values render <unknown>.
POST /rules/{id}/test with a real resource_id returns the full condition trace + the interpolated action payloads without dispatching. Verify the tree evaluates the way you expect before flipping enabled=true.
Every fire — matched, throttled, no-match, or error — records a RuleExecution row with the trace and per-action outcome. GET /rules/{id}/executions returns the last 50 by default; the audit log also captures every rule create / update / disable.
/rules list/create · /rules/schema (fields, comparators, action types — drives the builder UI) · /rules/{id} get/patch/delete · /rules/{id}/test dry-run · /rules/{id}/executions history. A no-code builder UI ships in an upcoming release; today rules are configured via the REST API. See the Rules Engine design doc for the full spec.
Author your own contract-clause extraction prompts alongside the 3 canned platform extractors.
Each extractor declares 1–20 output fields. Each field has a name (lowercase snake_case), a type (string / integer / number / boolean), a description, and a landing rule: Enforce as Commitment creates a Commitment row on every contract (runs through breach detection + rules engine + health score), Reference on Contract lands as passive metadata in Contract.extracted_fields. Mix both in a single extractor.
Free-form text; must contain the literal {text} placeholder — that's where the contract text is substituted at run time. The service wraps the tenant prompt with a system-authored preamble that forces the LLM to return JSON matching the declared schema. Extras the LLM produces are dropped; missing fields are logged as validation errors.
POST /extractors/{id}/test with a contract_id runs the extractor against that contract's stored text and returns the extracted fields plus a landing-rule preview. No Commitments are created and Contract.extracted_fields isn't written. Use this to iterate on the prompt before flipping status to active.
Draft extractors never run. Active extractors fan out during every customer contract ingest, vendor contract ingest, and background ingestion. To edit an active extractor, click Pause (moves to draft) first — this prevents in-flight ingestions from seeing a schema that no longer matches the prompt. After 5 consecutive failures, the extractor is auto-moved to draft with the last error visible on the row.
Commitments carry an extracted_by_extractor_slug column — system for platform prompts, the tenant's slug for custom extractors, NULL for manually-created rows. Exposed on the API today; UI chip on Commitment rows ships as a follow-up polish.
/extractors list/create · /extractors/platform (read-only descriptors of the 3 canned prompts) · /extractors/{id} patch · /extractors/{id}/activate · /extractors/{id}/archive · /extractors/{id}/draft · /extractors/{id}/test. Full guide: docs/custom-extractor-guide.md.
Track your vendors' response times by CC'ing a dedicated ZantIQ inbound address on every request you send them.
Every Business+ tenant gets a dedicated inbound address at
<slug>@vendor-comms.zantiq.app. When you email a vendor
and CC this address, ZantIQ:
domain field)./vendors/<vendor> and make sure the Domain field is populated (e.g. aws.amazon.com). Attribution won't work without it — the funnel matches inbound replies by domain.
When ZantIQ receives an inbound message on your alias (via the Postmark
inbound webhook), it runs a 5-step attribution funnel to figure out
which tenant / vendor / contract / commitment / thread the message
belongs to. Steps 1–2 gate the whole thing: if the tenant or vendor
can't be resolved, later steps are skipped and the message lands in
the Unmatched Queue. Code lives at
services/vendor_email/attribution.py.
| Step | What we match on | Data source | If no match |
|---|---|---|---|
| 1 — Tenant | Local part of the alias address (the <slug> before @vendor-comms.zantiq.app) in To: or Cc: |
vendor_email_aliases.slug |
Message discarded (nothing to attribute) |
| 2 — Vendor | From-header domain against the vendor's registered Party.domain |
parties WHERE party_type='vendor' AND status='active' AND domain=?, tenant-scoped |
Tagged unknown_sender, lands in Unmatched Queue |
| 3 — Contract | Contract label appearing in the subject line (≥8 chars, case-insensitive substring) | contracts.label for the resolved vendor |
Contract left NULL — vendor attribution still stands |
| 4 — Commitment | Commitment name / contract value keyword in subject or body | commitments for the resolved contract |
Commitment left NULL — contract + vendor still stand |
| 5 — Thread stitching | RFC 5322 In-Reply-To / References headers, then subject + vendor fallback |
vendor_email_threads.message_id_header |
New thread created |
Step 2 is where "which vendor" gets answered. Every inbound message goes through this lookup:
csm@aws.amazon.com yields aws.amazon.com.parties where tenant_id = you, party_type = 'vendor', status = 'active', and domain = 'aws.amazon.com'.attribution_status = 'attributed'.attribution_status = 'unknown_sender' and shows up in the Unmatched Queue for manual triage.
The disambiguation you asked about — "how do you know which vendor if
there's more than one" — comes from the fact that each vendor's
Party.domain is unique per tenant (in practice; the DB
doesn't enforce it, see edge case #5 below). A message from
@datadoghq.com maps to your Datadog party; a message from
@twilio.com maps to your Twilio party. Never ambiguous
as long as each vendor has its own corporate domain registered.
Each stored VendorEmailMessage row carries an attribution_status that reflects how the funnel handled it:
| Status | Meaning | Where it renders |
|---|---|---|
attributed |
Step 2 matched a vendor. Steps 3–5 may or may not have added contract / commitment / thread linkage. | Vendor detail page → Email Threads tab |
needs_attribution |
Message received but the funnel hasn't run yet (transient) or vendor lookup deferred (rare). | Should auto-clear within seconds; if it sticks, check Postmark webhook health |
unknown_sender |
Step 2 couldn't match the From-domain to any active vendor party. Message is preserved, just unlinked. | Unmatched Queue admin page |
manually_attributed |
An admin clicked "Attribute to this vendor" in the Unmatched Queue. | Vendor detail page → Email Threads tab (same as attributed) |
csm@yourco.com), not the vendor. Step 2 doesn't match
on that outbound copy. It stays as needs_attribution
until the vendor replies — the reply attributes the thread, and
step 5's In-Reply-To header stitches the outbound
message onto the same thread. Response-time metrics start ticking
from the outbound send time once the thread is bound.
acme.com but the reply arrives from
support.acme.com. Exact-match fails, message lands in
the Unmatched Queue. Fix: either update the vendor's
Party.domain to the subdomain that actually sends, or
use the Unmatched Queue's manual-attribute action to bind the
message; it flags as manually_attributed. A follow-up
feature (party_aliases table) would let one vendor own multiple
domains — flag if you hit this often.
Party.domain. Every rando from Gmail would match the
first vendor that owned the domain. Contractors on personal email
are a manual-attribute case every time — inconvenient but safer
than the misattribution alternative.
.limit(1)s the result, so the alphabetically-first
vendor wins. Not currently handled well. If you hit this, ping
engineering to consider a per-contact "primary email" tiebreaker
or the party_aliases feature.
Party.domain set.
Every message from that vendor lands in the Unmatched Queue
forever. Fix at setup time — audit
/parties?party_type=vendor&domain=null as part of
Vendor Email Requests onboarding.
Anything with attribution_status other than
attributed or manually_attributed surfaces
in the Unmatched Queue admin page (linked from the sidebar under
Vendor Email Requests). Each row shows subject + From + first line
of the body. Two actions: Attribute to vendor
(pick a vendor from the dropdown; flags as
manually_attributed and moves the thread to the
vendor's Email Threads tab) or Discard (spam or
unrelated). You never lose a message — the funnel prefers "unmatched
+ preserved" over "attributed to the wrong vendor + hidden."
Rules of thumb:
To:. The alias goes in CC. Never make the alias the primary recipient — vendors need to see who they're replying to.Every vendor detail page (/vendors/<vendor>) has an Email Threads section. Each thread row shows subject, message count, first-response time, and links out to the full conversation view. Threads that couldn't be attributed automatically appear in the Unmatched Queue for manual review.
Vendor Email Requests is a fully managed feature — the price is included in Business ($2,499/mo) and Enterprise. You never touch DNS or a mail server. On our side we run:
vendor-comms.zantiq.app apex + MX recordsdocs/vendor-email-alias-runbook.md. Ops engineers on-call should keep it open during any deliverability incident.
Understanding when ZantIQ syncs data and how to monitor integration health.
| Sync type | Frequency | Trigger |
|---|---|---|
| Scheduled background sync | Every 15 minutes | Automatic |
| Manual sync | On demand | Click "Sync" on Connectors page |
| Webhook-triggered sync | Real-time (<5 sec) | Incoming webhook event from the source system |
| Post-ingestion sync | Immediately after contract ingestion | Automatic after extraction completes |
Navigate to Sync Log in the left sidebar to view a full audit trail of every sync operation. Each entry shows:
Integrate ZantIQ into your internal tooling via REST API and outbound webhooks.
| Event | Trigger |
|---|---|
commitment.breach | A commitment status changes to breach |
commitment.resolved | A breach is cleared and status returns to compliant |
connector.error | A connector sync fails |
contract.ingested | A contract finishes extraction |
field_map.conflict | A mapping rule detects a conflict between source and target |
Configure webhook endpoints in Settings → Webhooks. Each webhook delivery includes an X-ZantIQ-Signature header (HMAC-SHA256) for request verification.
How ZantIQ handles data security, encryption, and retention policies.
| Control | Details |
|---|---|
| Encryption at rest | AES-256. All data including connector credentials, contracts, and field values. |
| Encryption in transit | TLS 1.3 minimum for all API and browser traffic. |
| Credential storage | API keys and OAuth tokens are stored encrypted and never exposed in UI, logs, or API responses. |
| Audit log | All admin actions (user changes, connector connects/disconnects, field map edits) are logged with timestamp, user, and IP address. |
| Data retention | Contract files: 7 years (configurable). Sync logs: 90 days. Audit logs: 2 years. |
| GDPR / data deletion | Customer data can be deleted on request via Settings → Data → Delete Customer. This removes all associated contracts, commitments, and sync history. |
| AI & data privacy | ZantIQ does not use customer contract data to train AI models. Vertex AI is used for inference only; no data is retained by the model provider. |
| SOC 2 (in progress) | ZantIQ is designed for SOC 2 Type II compliance. Security controls documentation available upon request at info@zantiq.ai. |
Controlling who can access ZantIQ and what they can do.
| Role | Typical user | Key permissions |
|---|---|---|
| Admin | VP of CS, Ops Lead, IT Admin | Everything — connectors, field mapping, Layer 3 push config, user management, billing, API keys, SSO, webhook configuration, data deletion. Layer 3 pushes require a different admin to approve than the one who requested — the system enforces maker/checker on the server side, so at least two admins are needed for any target write. |
| Manager | CS Manager, RevOps Manager | Full read/write on customers, contracts, commitments, compliance, SLA pages. Cannot manage connectors, field mapping, billing, or SSO. |
| Viewer | CSM, AE, Executive | Read-only access to dashboard, customers, contracts, compliance, and SLA reports. Cannot create, edit, or delete any records. |
The Team page shows all active users, pending invitations, and a list of recently deactivated accounts.
Enter the invitee's work email address. Select a role. Optionally set a CSM assignment so this user is pre-linked to specific customer accounts.
For onboarding a team, click "Import CSV". Format: email,first_name,last_name,role. Each person receives an individual invite email.
When a team member leaves, click the three-dot menu on their row → Deactivate. This immediately revokes their access. Their historical activity (audit logs, comments) is preserved.
How customers are created, organised, and viewed in ZantIQ.
The Customers page lists all accounts. Each row shows the customer name, plan tier, MRR, compliance score, health tier badge (Compliant / Review / At Risk), assigned CSM, and creation date.
Use the search bar to filter by customer name. Use the tier buttons — All, Compliant, Review, At Risk — to focus on customers that need attention.
Click any customer row to open their detail page. The detail view contains tabbed sections: Overview, Contracts, Compliance, and Connectors.
Compliant health score ≥ 90% · Review 70–89% · At Risk <70%. These tiers drive alert priority and QBR preparation workflows.
Customers are created automatically when a contract is ingested (ZantIQ extracts the customer name from the PDF) or via Salesforce sync (each Salesforce Account becomes a ZantIQ customer). You can also create customers manually from Customers → New Customer.
sf_account_id and used to match records across systems.How to upload, extract, and manage contracts in ZantIQ.
Click Ingest Contract on the Contracts page. Drag and drop or browse for a PDF or DOCX file. Maximum 50 MB.
ZantIQ's AI engine parses the document (15–60 seconds). It extracts: contract type, customer name, contract value, start and end dates, SLA tiers, response and resolution time commitments, seat counts, uptime guarantees, penalty caps, and escalation paths.
The Extraction Confidence column shows how confident ZantIQ is in its extraction (0–100%).
Navigate to Commitments to see every obligation extracted from the contract as a separate row — type, contract value, actual value (pulled from connected systems), and compliance status.
The Contracts page has filter tabs at the top: All, MSA, SOW, Active, Expired. Use these to quickly find contracts by type or lifecycle status. The Ingestion Status column shows whether extraction is pending, complete, or failed.
Monitoring whether your organisation is meeting its contractual obligations.
| Status | Meaning | Typical cause |
|---|---|---|
| Compliant | Contract term is being met in all connected systems. | — |
| Breach | Contracted term is actively being violated. | Jira SLA timer exceeded; uptime below contracted level. |
| Mismatch | What's in the system doesn't match what's in the contract. | Zendesk SLA policy set to 2h but contract says 1h. |
| Missing | No data found for this commitment in connected systems. | SLA policy not configured in the ticketing system. |
| Incomplete | Partial data found — some target systems have values, others don't. | Jira configured but Zendesk SLA missing. |
| Late | A time-bound commitment has passed its deadline. | Renewal date passed without action. |
| Unknown | Cannot determine status — connector data insufficient. | No connectors configured for this customer yet. |
Use the Customer dropdown in the top-right to focus on a single customer. Selecting "All Customers" shows aggregate compliance across your entire book of business.
Shows the percentage of commitments that are compliant for the selected customer. The centre number is the headline compliance rate.
Shows commitment count by status (Compliant, Breach, Mismatch, Missing, etc.) to identify which problem types are most prevalent.
A sortable table of every commitment that is not Compliant. Columns: commitment name, customer, type, contract value, actual value, status, and source system. Use this as your weekly action list.
Tracking response time and resolution SLA attainment across your customer base.
Select a specific customer or view all customers in aggregate. The stat cards, charts, and source breakdown table all update to reflect the selection.
A grouped bar chart showing Met % vs. Breached % for each priority tier (P1, P2, P3). P1 issues are your most urgent — a Breach here typically triggers financial penalties per contract terms.
A side-by-side bar chart comparing Actual response times versus the Contracted target for each priority tier. Bars above the target line indicate underperformance.
Four headline metrics at the top: Met, Breached, At Risk, and Mean Response Time. These update live as ticket data flows from Jira, Zendesk, or Pylon.
How ZantIQ surfaces breaches and how to route them to your team.
| Alert type | Trigger | Where it appears |
|---|---|---|
| SLA Breach | A commitment status changes to breach | Dashboard Active Alerts · Alerts page · Email · Slack (if configured) |
| Field Conflict | A field mapping detects a mismatch between source and target | Dashboard Enforcement Intelligence · Field Mapping conflicts counter |
| Connector Error | A connector sync fails | Connectors page status badge · Email to Admins |
| Renewal Due | A contract renewal date is within the configured notice period | Renewals page · Email digest |
Go to Connectors → click Connect on the Slack tile. Authorise the ZantIQ Slack App to access your workspace. ZantIQ will request channels:read and chat:write scopes.
Go to Settings → Notifications → Slack. Configure a default channel for breach alerts (e.g., #cs-alerts). Optionally, set per-customer channels so that TechCorp alerts go to #cs-techcorp.
Go to Settings → Notifications → Email. Add email addresses to receive daily digest reports and real-time breach alerts. The assigned CSM for a customer is automatically copied on breach alerts for their accounts.
Managing contract renewals and tracking customer health over time.
The Renewals page shows all contracts approaching their end date, sorted by renewal date ascending. Use this page for renewal pipeline management and at-risk identification.
Go to Settings → Renewals to set your default notice periods (e.g., 90 days, 60 days, 30 days). Contracts entering each threshold receive a notification.
Mark renewals as In Progress, Won, or Churned to maintain your renewal pipeline within ZantIQ alongside your CRM.
The Health Scores page provides a per-customer composite score (0–100%) calculated from:
Two additional analytics pages are available to business admins:
Tracks contracted seat counts against actual active users, contracted storage against usage, and other consumption-based commitments. Useful for identifying customers approaching or exceeding contracted limits.
Quantifies the financial exposure from active breaches — summing penalty caps, credit obligations, and at-risk renewal value. Feeds directly from breach data and contract penalty clauses extracted during ingestion.
How ZantIQ's on-demand AI agents work and what counts against your daily quota.
ZantIQ operates two distinct classes of AI workloads. Automated weekly scans — re-extraction of contract text, embeddings refresh, and anomaly detection — run in the background on a fixed schedule and do not consume any daily quota. On-demand agent runs are manually triggered by a user and each count as one run against the plan's daily limit:
| Plan | On-Demand Agent Runs / Day | Reset |
|---|---|---|
| Starter | 25 | Midnight UTC |
| Pro | 50 | |
| Business | 200 | |
| Enterprise (Scale / Global) | 500 | |
| Enterprise+ | Unlimited |
usage.agent_invocations_today and limits.agent_daily_limit from the GET /api/v1/billing/subscription endpoint. When the limit is reached, the API returns HTTP 429; the counter resets automatically at midnight UTC — no manual action required.A summary of every page in ZantIQ and what it is used for.
| Page | Purpose | Audience |
|---|---|---|
| Dashboard | Platform overview: stat cards, enforcement intelligence, active alerts, customer preview | All roles |
| Customers | Customer list with health score, compliance tier, CSM assignment; detail drilldown | All roles |
| Contracts | Contract list, type/status filters, ingestion trigger, confidence scores | Manager, Admin |
| Contracts → Ingest | Upload and extract a new contract PDF or DOCX | Manager, Admin |
| Commitments | All extracted obligations with compliance status, contract vs actual values | Manager, Admin |
| Compliance | Compliance score donut, status breakdown chart, non-compliant commitment table (per customer) | All roles |
| SLA Performance | SLA attainment and response time charts by priority tier, per customer filter | All roles |
| Connectors | Connect, sync, and manage external system integrations (72 systems across 14 categories) | Admin |
| Field Mapping | Visual canvas to map source fields to target system fields; manage mapping rules and conflicts | Admin |
| Alerts | All active breach and mismatch alerts with financial exposure | Manager, Admin |
| Amendments | Track contract amendments and mid-term changes to obligations | Manager, Admin |
| Health Scores | Composite health score per customer with trend history | All roles |
| Renewals | Upcoming renewal pipeline sorted by date, with status tracking | Manager, Admin |
| Trends | Historical compliance and SLA performance trend charts | All roles |
| Exposure | Financial exposure from active breaches and penalty clauses | Manager, Admin |
| Utilization | Seat count and consumption-based commitment tracking | Manager, Admin |
| Credits | Customer credit obligations from SLA breaches | Manager, Admin |
| Sync Log | Full audit trail of connector sync operations | Admin |
| Agents | AI agent configuration for automated monitoring and escalation; on-demand brief generation consumes the plan's daily run limit (Starter 25/day · Pro 50/day · Business 200/day · Enterprise 500/day · Enterprise+ unlimited — resets midnight UTC) | Admin |