Organizations & Contracts
Organizations model customer accounts. Contracts model service coverage and billing rules. Together they drive routing, approvals, portal visibility, SLA commitments, invoice generation, and account reporting.
Organizations
An organization stores the account profile, support tier, owner assignments, routing mode, account health, QBR ownership, portal members, escalation contact, governance controls, and notes. It can also store tenant and brand keys for white-label or multi-tenant deployments.
Routing Ownership
- Lead user is the primary accountable owner.
- Manager user is used for escalation.
- Backup lead covers lead absence.
- QBR owner handles account review ownership.
- Routing mode supports team-first, urgent-to-lead, and all-to-lead routing.
- Support tier supports standard, priority, enterprise, and strategic account behavior.
Governance Controls
Organizations can restrict public channels, require evidence tags, require closure QA items, require secure portal evidence, require export approval, apply VIP contract-only handling, store legal hold dates, and define pause rules.
Dedicated Support Team
Support team rows define agent, coverage role, capacity weight, queue cap, availability status, working days, shift windows, after-hours behavior, backup rotation order, backup-for user, leave dates, and active state. The form validates that support team, lead, manager, and backup lead users are active Admin or Agent users and are not duplicated in the same organization.
Support Contracts
A support contract is the service agreement for one organization. In plain language, it tells the app what the customer paid for, which ticket channels and priorities are covered, what response targets apply, and which work can later appear in reports or invoice drafts. This is support desk coverage documentation, not POS product or receipt documentation.
Create Support Contract Fields
| Field | Plain meaning | Example | What happens if you fill it |
|---|---|---|---|
| Organization | The customer account this contract belongs to. | Acme Labs | Required. Tickets for this organization can be checked against this contract. |
| Contract Name | The internal name for this agreement. | Acme Premium Support 2026 | Required. This is the name agents see on ticket coverage, reports, and billing screens. |
| Plan Name | A short plan or package label. | Enterprise Plus, Retainer, Managed SLA | Optional. Useful when several contracts use the same internal naming style but different plan tiers. |
| Status | Whether the contract should be used. | Active | Required. Active contracts can cover tickets. Inactive or expired contracts are kept for history but should not cover new work. |
| Starts At | The date and time coverage begins. | 2026-01-01 09:00 | Tickets before this date are treated as outside this contract. |
| Ends At | The date and time coverage ends. | 2026-12-31 18:00 | Must be on or after the start date. Tickets after this date are treated as outside the contract. |
| Renewal At | The date your team should review or renew the contract. | 2026-11-30 10:00 | Must be on or after the start date. Used for renewal follow-up and account lifecycle reporting. |
| Auto renew | Whether the agreement is expected to continue automatically. | Enabled for a monthly managed support retainer | Reports and renewal workflows can treat the contract as continuing unless someone changes it. |
| Covered only during configured business hours | Whether the contract only applies inside the organization's business-hour calendar. | Enabled for Monday to Friday, 9 AM to 5 PM support | Tickets outside business hours are still recorded, but coverage is flagged as a warning. |
| Ticket Credit Limit | The maximum number of tickets included in a monthly period. | 100 | When the monthly count reaches the limit, new matching tickets show a contract warning. |
| Monthly Hour Limit | The number of included support hours per month. | 40 | Used by usage burn-down, reporting, and invoice context. |
| Billable Hourly Rate | The normal hourly rate charged to the customer. | 150.00 | Used by finance reports and invoice draft calculations. |
| Internal Hourly Cost | Your internal cost estimate for one support hour. | 65.00 | Used to compare revenue and delivery cost in reporting. |
| Overage Hourly Rate | The rate charged after included hours or credits are used. | 200.00 | Used when billable work exceeds the included allowance. |
| Response Commitment | How fast the first response should happen, written in minutes. | 60 means 1 hour | Used as contract service context. The field accepts whole minutes. |
| Resolution Commitment | How fast the issue should be resolved, written in minutes. | 1440 means 1 day | Used as contract service context. The field accepts whole minutes. |
| SLA Override | A specific SLA policy that should apply for this contract instead of normal matching. | Enterprise 4 Hour SLA | Matching tickets can inherit this SLA policy from the contract. |
| Allowed Channels | Which ticket intake channels are covered by this contract. | Portal and Email | Leave blank to cover every channel. If only Portal and Email are selected, Internal tickets are outside this contract. |
| Allowed Priorities | Which ticket priorities are covered by this contract. | Medium, High, Urgent | Leave blank to cover every priority. If Low is not selected, Low priority tickets are outside this contract. |
| Named Contacts | Important customer contacts or inboxes for the agreement. | finance@acme.com, csm@acme.com | Enter comma-separated contacts. They are used by invoice exports, renewal follow-up, and account reports. |
| Notes | Internal free-text notes about the contract. | Customer requires monthly usage summary before invoice approval. | Use this for billing caveats, special commitments, renewal context, or handling notes. |
| Create Contract button | The save action for a new support contract. | Create Contract | The app validates required fields first. On success, it creates the contract and redirects to the Contracts index page. |
Contract Entitlements
Entitlements are optional rows that narrow what the contract covers. If the contract has no entitlement rows, the active contract can cover the whole organization, subject to channel, priority, date, and business-hour rules. If entitlement rows exist, a ticket must match one of those rows to be treated as covered.
| Entitlement field | Plain meaning | Example | How to use it |
|---|---|---|---|
| Context Type | The type of business record the contract covers. | Asset, Order, Project, Employee Group | Choose this when the contract only covers a certain kind of linked record. Leave blank for any context type. |
| Context ID | The exact record number inside that context type. | 245 | Use with Context Type when only one specific record is covered. For example, Asset ID 245. |
| Category | The ticket category that must match this entitlement. | Network Issue | Use when the contract covers only certain work types. Leave blank for any category. |
| Coverage Note | A short explanation shown as the coverage reason. | Covers router support for HQ office only. | Use this to tell agents exactly why the ticket is covered or what scope applies. |
Blank entitlement rows are ignored. For example, one row with Category set to Email Support and no Context Type means the contract covers that category for the organization. A row with Context Type Asset, Context ID 245, and Category Hardware means only hardware tickets linked to Asset 245 are covered.
Edit Contract Usage and Invoices
After a contract exists, the edit page can show a usage snapshot with used hours, hour limit, and remaining hours. Users with report permissions can also generate draft invoices for a selected billing period. The invoice area is not shown while creating a new contract because there is no saved contract yet.
Context Hub
/context-hub exposes linked business context records such as assets, orders, employees, and other configured providers. Tickets and contracts can point to these records so agents understand what product, asset, order, or business object the case relates to.