Service requests
Raised and approved by the customer in the service portal; received, assessed, scheduled and completed by TRANXACT. Production requests are handled around the clock, non-production on business days.
| Request | Category | Lead time |
|---|---|---|
| Environment refresh, production → non-production (TO_4.7.01) | Standard, up to 12 per environment per year | 3 working days |
| Refresh beyond the quota (TO_4.7.02) | Additional | 3 working days |
| Point-in-time restore (TO_4.9.05) | Standard | Hours; P1 immediately |
| Add an egress destination (INFRA_2.6.02) | Standard | 2 working days (proposed) |
| Create an integration API client (PLAT_5.3.02) | Standard | 2 working days (proposed) |
| Switch on a module (PLAT_5.1.01) | Standard, with a sizing review | Per plan |
| Resize nodes or database (INFRA_2.4.05, DB_3.1.06) | Optional, change request | Change window |
| Temporary capacity for a peak (INFRA_2.4.06) | Additional | 5 working days (proposed) |
A refreshed copy has its outbound integrations disabled and its endpoints re-pointed, so it can never send live payments or filings. They stay disabled until the customer re-enables them.
Incidents
| Priority | Reaction | Hours |
|---|---|---|
| P1 · Very high | 20 minutes | 24×7; action plan within 4 hours |
| P2 · High | 2 hours | 24×7 production; business days non-production |
| P3 · Medium | 4 hours | Business days |
| P4 · Low | 1 day | Business days |
In a P1: raise it in the portal with a 24×7 contact, call the service desk quoting the number, and the duty manager engages if business is down, go-live is at risk, or month-end, payroll or a filing is stopped. Expect an action plan within 4 hours, one point of contact, and a root-cause analysis for production.
A P1 without a reachable 24×7 contact loses its reaction-time guarantee. And only the customer confirms resolution and closes an incident.
Releases
Release notes in advance → non-production first → the customer’s regression tests (the customer’s, unless T1 is contracted) → a cooling period → a rolling production update. Month-end, payroll and statutory filing dates are blocked out of the production calendar by default, and the customer may request a deferral within the allowed window.
Governance
| Forum | Cadence | Covers |
|---|---|---|
| Executive | On demand | Strategy, roadmap, more modules |
| Steering committee | Quarterly | SLA and KPIs, scaling, major changes |
| Business review | Monthly | Service quality, adoption, ASK usage and cost |
| Operations sync | Fortnightly | Incidents, requests, releases, escalations |
Scaling and extensions
Inside the contracted tier TRANXACT scales on its own. Beyond it, bigger or more nodes, a bigger database or more storage are Optional by change request, mirrored in Live DR; a temporary peak increase is Additional. An approved in-cluster extension is the customer’s to install, patch and validate before every release; TRANXACT will not delay a platform update for it, may isolate it if it threatens the SLA, and its incidents are excluded from the availability SLA.
Three months after go-live, Calderwood refreshes QAS from production with masking for regression testing. Two days later a tester asks why no bank file arrived from QAS. Nothing is wrong: refreshed copies never send live payments, and QAS’s integrations stay disabled until Calderwood’s integration owner re-enables them against the bank’s test endpoint.
Try it Calderwood’s approved third-party tax engine, running in the cluster, stops the month-end close for three hours. Who handles it, and does it count against TRANXACT’s availability?
It is a customer incident: the customer installs, patches and escalates to the vendor (EXT_9.2.02), and incidents caused by third-party software are excluded from the availability SLA (EXT_9.2.05). TRANXACT may isolate or remove the extension if it threatens stability (EXT_9.2.04).