After go-live: running the service
Service requests and the catalogue, incidents and what to do in a P1, the SLAs, support channels, releases, the governance cadence, monitoring, scaling, extensions, and the steady-state checklist.
Service requests
Request → execution → customer acceptance → catalogue maintenance. Only the customer raises and approves a request; TRANXACT receives, assesses, schedules and reports completion (SM_1.2.02). Production requests are handled 24×7, non-production on business days.
| Request | Identifier | Category | Lead time | Notes |
|---|---|---|---|---|
| Environment refresh (production → non-production) | TO_4.7.01 | Standard | 3 working days | Up to 12 per environment per year; optional data masking |
| Environment refresh beyond quota | TO_4.7.02 | Additional | 3 working days | Charged per refresh |
| On-demand backup before a major change | TO_4.9.04 | Standard | Hours | |
| Point-in-time restore | TO_4.9.05 | Standard | Hours (P1 immediately) | Within the retention window |
| Clean-room restore from the vault | TO_4.9.06 | Additional | Hours | Isolated environment, scan, reconcile, promote |
| Additional switchover drill | TO_4.10.04 | Additional | 2 weeks’ notice | Outside the quarterly Standard drill |
| Isolated (fenced) drill | TO_4.10.05 | Additional | 2 weeks’ notice | Outbound integrations disabled |
| Switch on a module | PLAT_5.1.01 | Standard | Per plan | Planned with a sizing review |
| Add a legal entity, currency or language | PLAT_5.1.03 | Standard | Per plan | Within contracted scope |
| Resize worker nodes | INFRA_2.4.05 | Optional — change request | Change window | Mirrored in the Live DR region |
| Resize database | DB_3.1.06 | Optional — change request | Change window | |
| Add an egress allow-list destination | INFRA_2.6.02 | Standard | 2 working days (proposed) | One entry per partner endpoint |
| Create an integration API client | PLAT_5.3.02 | Standard | 2 working days (proposed) | Scoped roles per client |
| Coordinate a customer penetration test | TO_4.5.08 | Additional | 2 weeks’ notice | NDA and agreed scope |
| Bulk data load | MIG_8.2.02 | Additional | Per plan | Beyond the agreed trial cycles |
| Temporary capacity increase for a peak | INFRA_2.4.06 | Additional | 5 working days (proposed) |
An environment refresh, phase by phase
- Request (customer) — in the service portal, with the target environment, the date and the masking choice.
- Quality check (TRANXACT) — scope, category, quota and approvals validated; schedule confirmed.
- Execution (TRANXACT) — snapshot, copy, mask, disable outbound integrations, re-point endpoints (TO_4.7.03, 4.7.04).
- Post-processing (TRANXACT) — health checks, access re-applied, a completion notice with evidence.
- Acceptance (customer) — validate and close or reject (TO_4.7.06); decide which integrations to re-enable (TO_4.7.07).
A refreshed copy must never send live payments or filings. Its integrations stay disabled until the customer enables them.
Incidents
The customer creates the incident with priority, business impact, error details and a 24×7 contact (TO_4.2.01). TRANXACT operations validates the priority and acknowledges, investigates with an ASK summary, and provides a solution or workaround; product defects go to engineering for a fix (TO_4.2.06). Only the customer confirms resolution and closes it (TO_4.2.05).
| Priority | Reaction time | Hours |
|---|---|---|
| P1 · Very high | 20 minutes | 24×7; workaround or action plan within 4 hours |
| P2 · High | 2 hours | 24×7 for production; business days for non-production |
| P3 · Medium | 4 hours | Business days |
| P4 · Low | 1 day | Business days |
Reaction time runs from ticket creation to first action by an engineer who knows the environment.
A P1, in four steps
- Raise a Very High incident in the service portal with a 24×7 contact name and phone, the business impact, and error messages or screenshots.
- Call the 24×7 service desk quoting the incident number; ask for status or a call-back; raise the priority if impact grows.
- The duty manager engages when business is down, go-live is endangered, or month-end, payroll or a filing is stopped — bringing in the Ledger Architect and engineering.
- An end-to-end action plan within 4 hours, a single point of contact, and a root-cause analysis for production. The incident stays the system of record.
A P1 without a reachable 24×7 contact loses its reaction-time guarantee. Name at least two on the onboarding form.
Support channels
| Channel | For |
|---|---|
| Service portal — the primary channel | Incidents and service requests, the request catalogue and status, availability and backup dashboards, release notes and the maintenance calendar. |
| 24×7 service desk | Very High incidents around the clock, status updates and call-backs. English; regional languages in business hours. |
| ASK in-product help | How-to answers in the user’s language; an incident draft with context attached. It never bypasses role permissions. |
| Customer success | The AI Adoption Navigator as named contact, the monthly business review, renewal and expansion. |
Releases
- Release notes and schedule published in advance (TO_4.8.01).
- Deployed to non-production first (TO_4.8.02).
- Customer regression tests of its own processes in non-production — the customer’s task, unless the T1 Regression Testing package is contracted (TO_4.8.03).
- A cooling period.
- A rolling production update across the three nodes.
- Month-end close, payroll runs and statutory filing dates are blocked out of the production release calendar by default (TO_4.8.04).
- Schema changes are backward-compatible and tested on a production-size copy (TO_4.8.05).
- The customer may request deferral of a production update within the allowed window (TO_4.8.06), and move the maintenance window away from month-end, payroll or filing dates (TO_4.4.03).
- TRANXACT does not delay platform updates for third-party extension compatibility (EXT_9.2.03).
Governance
| Forum | Cadence | Covers |
|---|---|---|
| Executive | On demand | Strategy, roadmap, expansion to further modules |
| Steering committee | Quarterly | SLA and KPI review, scaling, major changes (SM_1.1.06) |
| Business review | Monthly | Service quality, adoption, ASK usage and cost (SM_1.1.05) |
| Operations sync | Fortnightly | Incidents, requests, releases, escalations |
| Monitoring domain | Signals | Escalation chain |
|---|---|---|
| Application & ledger | API latency, error rates, posting queues, job runs | App L1/L2 → L3 |
| Runtime & database | Node, pod and DB health; Live DR lag; vault backup status | Platform L1/L2 → L3 |
| Network & security | Ingress / WAF, certificates, VPN, threat alerts | SecOps → L3 |
Synthetic checks run against the customer FQDN from outside the cloud (TO_4.3.03). Business-process monitoring — stuck approvals, unposted documents — is the customer’s unless the M1 Integration Monitoring package is contracted (TO_4.3.05).
Scaling
- Within the contracted tier, TRANXACT reschedules and scales workloads itself (INFRA_2.4.04, Standard).
- Beyond it, more or bigger worker nodes (INFRA_2.4.05), a bigger database (DB_3.1.06) or more storage (INFRA_2.5.03) are Optional, by change request — mirrored in the Live DR region.
- A temporary increase for a migration or a year-end peak is Additional (INFRA_2.4.06).
- Capacity is reviewed monthly and before each month-end, payroll or enrolment peak (SM_1.1.02, 1.1.03, TO_4.12.04).
Extensions and third-party software
A request is evaluated against the extension framework — configuration, then API, then in-cluster (EXT_9.1.01, Standard). In-cluster code or agents need a security and engineering review (EXT_9.1.02, Additional). If approved:
- The customer holds a valid licence and vendor support for the full term (EXT_9.1.03).
- TRANXACT deploys the approved image through its pipeline (EXT_9.2.01, Additional); the customer installs, configures, patches and escalates to the vendor (EXT_9.2.02).
- The customer validates compatibility before every release (EXT_9.2.03).
- TRANXACT may isolate or remove it after notice, or immediately in an emergency (EXT_9.2.04).
- Incidents caused by it are the customer’s and excluded from the availability SLA (EXT_9.2.05).
Record every approved extension in the landscape document and the non-standard log; it is re-reviewed at each major release and at renewal.
Checklist: steady state
| Governance | Change & release | Security | Resilience & scale |
|---|---|---|---|
| R&R workbook and RACI signed | Release calendar vs month-end | Access recertification | Quarterly switchover drill |
| Fortnightly and monthly reviews | Non-prod tests before prod | Logs flowing to the SIEM | Yearly clean-room restore |
| Escalation matrix aligned | Refresh plan and masking | Certificate and key rotation | Capacity review before peaks |
| ASK usage reviewed | Change window agreed | Patch notice period | Renewal sizing review |
Values marked proposed default are the deployment guide’s recommended starting points. Confirm each one per customer; the contract, order form, SLA and DPA prevail over this page.