Service requests
Nine productized request types: health check, backup, clone, patching, upgrade, DR drill, archive and purge, restart, and month-end close. Each carries live status you can watch.
- Home
- OTeam Platform
The platform
OTeam, the support platform your ERP runs on
Every Operatives support contract runs on OTeam: a client portal where you see everything, and an engineering workbench where every operation is runbook-driven, gated, and evidenced. Arabic and English, full right-to-left, built in rather than bolted on.
Your side of the platform
The client portal, where support stops being a black box
Published reports
Every completed run publishes a branded report to your portal: health scorecards, backup and restore evidence, upgrade outcomes, DR results with RTO timing, and close reconciliation summaries.
Incidents and RCAs
Open incidents carry deterministic severity, progress you can follow, and root-cause analyses you can read. Visibility into the work, not just the outcome.
Messages and confirmations
A direct conversation with your engineering team, including structured confirmation requests: the engineer proposes an action and a window, you confirm or decline, and the response is recorded with name and time.
Notifications, your way
Email notifications with per-kind preferences, an in-portal bell, and two-factor authentication on your account.
Arabic and English, full RTL
The portal and every communication in Arabic or English, with right-to-left treated as a first-class experience rather than an afterthought.
The confirmation loop
The engineer proposes. You sign.
A destructive step does not run because someone assumed it was fine. It runs because a named person approved it, in writing, at a recorded time, and the record survives the run.
Replay-proof, and readable a year later
Arabic first
Both languages, one product
Every screen, every notification and every published report exists in Arabic and in English. Right-to-left is not a stylesheet applied late; it is how the product was built.
Our side of the platform
The engineering workbench, capability you can verify
What your support team actually works in. This is why the portal has something real to show you.
Deterministic severity, never AI-decided
Incident severity is computed by code from the facts of the incident. The AI proposes diagnosis and drafts; it cannot set or change severity, scores, or go/no-go decisions.
Nine runbook-driven modules
Each with readiness gates scored from real command evidence, destructive-step confirmation, safe-state rules, and rehearsal then promotion: a proven run becomes the template for the next one.
Environment passports and credential vault
Client environments documented as structured passports. Credentials encrypted in a vault and referenced by label, never typed into chat and never echoed by anyone.
Redaction engine
Pasted logs and uploads are scrubbed of credentials before storage and before any AI processing. Secrets don’t reach models by architecture, not by policy.
Why it’s different
Five claims. Each one is architecture, not marketing.
- Zero-connectivity securitythe platform never connects to your systems, so we cannot be your attack surface Architecture
- Deterministic where it mattersseverity, readiness scores and go/no-go bands are computed by code from evidence Architecture
- Named-human confirmationdestructive steps are stamped with name and time, audited, replay-proof Architecture
- Evidence-first runsevery service publishes a report built from real command output Architecture
- Arabic-first bilingualportal, communications and reports, with RTL as a first-class experience Architecture
See it, don’t take our word
See OTeam run a real operation
Thirty minutes: the portal, a live runbook, and a published report, on the real platform rather than on slides.