Support-OS

For businesses whose tickets are about things

Most helpdesks know who complained. Support-OS knows what broke.

Support-OS is a support platform that also models your customers' equipment — circuits, machines, vehicles, units, properties — and the relationships between them. So when a customer calls about “the line at the Croydon office,” your agent sees exactly which line, what it depends on, and who else is already affected.

14
industries, ready on day one
42
starter record types
973
tests, green on every push
1
login, however many workspaces
Ticket #4192 Open · 2h 14m left

Line down at the Croydon office

Northgate Legal · raised 09:14

Circuit

CLV09052026GGZK

Related records

  • Located at Croydon Exchange
  • Depends on SN-88421

Croydon Exchange is the location of 11 other circuits — 3 with open tickets this morning.

The Friday afternoon problem

Twelve tickets. One cause. Nobody noticed until Monday.

One ticket says “internet not working.” Another says “slow since this morning.” A third says “phones are dead.”

In most helpdesks these are three unrelated rows in a queue — because the helpdesk only knows the customer's name. It has no idea the three of them share an exchange.

The information was always there. Your helpdesk just couldn't hold it.

  • Agents ask “which one?”

    A hundred times a week, instead of answering the question.

  • The same fault, diagnosed three times

    By three different people who never knew about each other.

  • Nobody sees the pattern

    Until it arrives as a complaint, from the customer, on Monday.

  • Your equipment lives in a spreadsheet

    A different tab, a different owner, permanently out of date.

The difference

A ticket that points at a real thing — and things that point at each other.

Most helpdesks model two things: a ticket and a person. Support-OS models a third — the thing the ticket is about — and then lets those things be connected.

Records

The actual things you look after. A specific circuit. A specific MRI scanner. Flat 3B. Van 14. Each one has its own page: its fields, its full ticket history, who owns it, and what it's connected to.

Record types

You define the shape, not a developer. Fields, types, what's required, and who is allowed to see each field. Add a field this afternoon and it is live this afternoon — no release, no migration, no support request to us.

Relationships

Four ways to connect any two records, and every link reads correctly from both ends.

  • Contains / is part of
  • Located at / is the location of
  • Depends on / supports
  • Relates to (symmetric)

Four verbs, deliberately. A bigger vocabulary is easy to add later and impossible to take away — because every verb becomes rows in your database forever.

A worked example

A telecoms workspace, one Friday afternoon.

Nothing here is a special feature. It is what happens when the ticket, the equipment and the connections between equipment live in the same place.

Without the relationships, those twelve tickets look unrelated.

  1. 1

    A customer reports their line is down.

    A ticket is raised against circuit CLV09052026GGZK — the actual circuit, not a text box that says “broadband”.

  2. 2

    The agent opens the circuit.

    Under Related Records: Located at — Croydon Exchange. Depends on — CPE Device SN-88421.

  3. 3

    They open Croydon Exchange.

    Under Location of, it lists eleven other circuits — and three of those have open tickets from this morning.

  4. 4

    That is not one line fault.

    That is an exchange problem affecting twelve customers, found in two clicks instead of on Monday. The twelve tickets get linked and handled as one incident.

Thirty minutes to a working desk

You don't build a data model. You pick your industry.

  1. 1

    Sign up and choose your industry.

    Fourteen to choose from. This is not a label on your account — it decides what gets created next.

  2. 2

    Your data model is already there.

    Telecom gives you Circuit, Site and CPE Device, fields defined. Real Estate gives you Property, Unit and Lease. Nothing is locked.

  3. 3

    Point your tickets at real things.

    Every ticket can name the record it is about. Agents stop asking “which one?”.

  4. 4

    Connect the things.

    Link a unit to its property, a circuit to its exchange, a machine to its line. Now one record tells you everything downstream of it.

Today you draw those links by hand. The industry packs don't yet suggest them for you — that's the next thing being built, and it's listed openly below.

Fourteen industries. Forty-two starter record types.

It already speaks your trade.

Every industry below provisions a real data model at sign-up — not a different colour scheme, not a dropdown value. Turn on a second industry later and its record types are added alongside yours. Nothing is overwritten.

  • Telecom

    Circuit · Site · CPE Device

  • Healthcare

    Patient · Medical Device · Ward

  • Education

    Student · Device Loan · Classroom

  • IT

    Server · Workstation · Application

  • Legal

    Matter · Client · Filing Deadline

  • Logistics

    Shipment · Vehicle · Route

  • Retail

    Order · Product · Return / RMA

  • Hospitality

    Reservation · Room · Facility

  • Real Estate

    Property · Unit · Lease

  • Manufacturing

    Machine · Production Line · Spare Part

  • Finance

    Account · Transaction Dispute · Card

  • Consulting

    Engagement · Deliverable

  • Freelancer

    Project · Invoice

  • Non-profit

    Grant · Programme · Volunteer

Don't see yours? The record types are yours to define — the fourteen above are a head start, not a limit.

The fundamentals, done properly

The rest of the helpdesk is not an afterthought.

The records are the reason to switch. These are the reasons you can actually switch.

  • Tickets & the queue

    Saved views, bulk actions, tags, canned replies, assignment and escalation. Merge true duplicates; link separate tickets that share a cause.

  • Two agents, one ticket

    If somebody else already has this ticket open, you're told — before you send a second reply to the same customer.

  • Email in and out

    Connect your support mailbox and incoming mail becomes tickets. Replies find their way back to the right ticket. Auto-replies and bounces are filtered out instead of opening tickets nobody asked for.

  • Service levels

    Departments, service tiers with response targets in minutes, and categories that route tickets to the right team automatically.

  • Business hours, holidays, timezones

    A four-hour target set at 5pm on Friday doesn't quietly breach over the weekend. Off by default, so turning it on never silently moves an existing promise.

  • Automation

    Rules that watch for something, check conditions and take actions — including time-based rules that fire on a schedule, not just on a change.

  • Knowledge base & smart search

    Public help articles your customers can find themselves, so easy questions stop reaching your queue.

  • Customer portal

    Your customers raise tickets, follow progress, rate the outcome, browse help articles, see their own records and export their own data.

  • Reporting you can trust

    Response and resolution performance, CSAT ratings, a full audit log, and a system health page. Reported as medians, with the sample size next to the headline instead of buried under it.

  • Exports

    Any list your team can see, they can export to CSV. Customers can export their own data themselves.

  • Roles and permissions

    Four built-in roles, plus your own custom roles from a 29-permission catalogue. Nobody can grant themselves — or anyone else — a permission they don't already hold.

  • One login, several workspaces

    Work with three companies on the platform? One password, three workspaces, a switcher in the corner. Not three accounts.

Automation

Rules that can't be written wrong.

Automation is where support tools quietly do damage — a rule fires twice, or emails a customer at 3am, or does something the person who wrote it wasn't allowed to do. Support-OS is built so those specific things can't happen.

Test a rule against a real ticket before you trust it.

  • The builder only offers fields that exist.

    Triggers and conditions are read from your real data. You cannot build a rule against a field that isn't there, so you cannot build a rule that silently never matches.

  • Every rule runs as a person.

    A rule executes with the permissions of whoever it runs as. It can never do more than that person could do by hand — so automation can't become a back door into your permission model.

  • Scheduled rules act exactly once.

    Time-based rules sweep every fifteen minutes and claim their work before doing it. Two passes can't send the same reminder twice.

  • A broken rule says it's broken.

    If a rule is malformed it reports malformed. It never reports “didn't match”, which is how a dead rule survives for six months.

What your customers see

A portal you can hand over without a briefing.

Your customers sign in and see their tickets — and only theirs. They raise new ones, follow the conversation, rate the outcome when it's closed, search your help articles, look at their own records, turn on two-factor authentication, and download their own data.

For administrators: there's a page that shows you exactly what a customer can see, field by field, so you can check before you invite them — not after.

They can

  • Raise and follow tickets
  • Rate the outcome (CSAT)
  • Read your help articles
  • See their own records
  • Turn on two-factor
  • Export their own data

They cannot

  • Read your internal notes
  • See your other customers
  • See your team's structure
  • Reach another company's data
  • Walk ids to find what isn't theirs

API & integrations

Connect it to the rest of your stack.

REST API

/api/v1, token-authenticated, rate-limited per workspace. One response shape and stable error codes for everything — including the framework's own errors, so a client never has to parse two formats.

Docs generated from the code

The OpenAPI spec is generated from the router itself. It cannot drift from what the API actually does, because adding a route documents it.

Scopes are ceilings, never grants

A token's scopes can only narrow what its owner may do. A customer holding a token with every scope still can't touch someone else's ticket.

Idempotent writes

Send an Idempotency-Key and a retry returns the original response instead of creating a second ticket. Networks fail; duplicates shouldn't.

Webhooks both ways

Let another system raise tickets in yours, and tell other systems what happened in yours. Signed, retried with backoff, and replayable when the far end was down.

Pointed outward only

Outbound webhook targets are checked before they're called, so a URL can't be used to make your server fetch something on your internal network.

Built to be run in production

The unglamorous parts, done first.

Isolation is enforced at the database layer

Not by a developer remembering to add a filter. Ask for a record from another workspace and it does not exist for you.

Refusals don't leak information

“You're not allowed” and “that isn't yours” are answered differently on purpose, so nobody can map another company's data by watching the error codes.

Two-factor authentication

Time-based codes with recovery codes, for your team and for your customers.

A full audit log

Who changed what, and when — and it's the same record the automation engine reads, so the log and the behaviour can't disagree.

Backups that have actually been restored

Backed up daily. Once a week the backup is restored into a scratch database and compared against the original — because a backup nobody has restored is a hypothesis, not a backup.

973 tests, 3,390 assertions

Run on every change, against the same database engine production uses. Nothing is allowed to skip quietly: if a test can't run, the build fails instead of showing a green tick that means less than you think.

Before you ask

What Support-OS doesn't do yet.

Every other product page tells you what it does. Here's what we don't — in public, before you're in a sales call, so you never find out from your own customer.

  • No payment processor.

    Plans, seats, trials, limits and upgrades all work. The invoice itself is raised outside the product today. We'd rather say that than fake a charge screen.

  • No SSO, SAML or SCIM.

    A genuine blocker above roughly 200 seats. If that's you, we're not ready for you yet. (Two-factor authentication does exist.)

  • Custom domain and white-labelling: unavailable.

    Not “coming soon” on a price list — it is switched off so hard that nobody, including us, can turn it on for you.

  • Omnichannel messaging: preview.

    No live channel is connected yet. It is off the price list until one is.

  • No AI features. None.

    There is not a single AI call in this product. When there is, this page will say so before any other page does.

  • Packs don't suggest relationships yet.

    You can link any two records; the packs just don't yet know that a Unit usually belongs to a Property. That's the next thing being built.

If one of these matters to you, say so — it moves up the roadmap. Everything above is tracked in the open.

Pricing

One limit moves per tier, so the reason to upgrade is obvious.

Pricing is being finalised.

Get in touch and we'll talk through what your workspace needs.

Enterprise

Contractual SLAs with financial penalties attached.

Talk to us

  • No limits on agents, tickets or records
  • SLA Financials — breach credit memos
  • Everything in the tiers below it
Start the conversation

Two things are missing from every tier on purpose: Custom Domain and Omnichannel. Neither is finished, so neither is for sale — see above.

Billing today is invoiced directly — there's no card form yet, and we'd rather tell you that here than at checkout.

Questions

The things people ask first.

Is this just another helpdesk?

No. A helpdesk models a ticket and a person. Support-OS also models the thing the ticket is about, and the connections between those things. If your support is about equipment, property, vehicles or infrastructure, that difference is the whole product.

Do I need a developer to set up my data model?

No. Pick your industry at sign-up and a starter model is created for you. After that, adding a field or a whole new record type is a form, not a release.

What if my industry isn't in the list?

The fourteen are a head start, not a limit — define your own record types. Tell us what you do and it may become the fifteenth pack.

Can my customers see each other's data?

No. Isolation is enforced at the database layer, and a request for another workspace's data doesn't return “forbidden” — it returns “doesn't exist”.

Can I bring my email inbox?

Yes. Connect your support mailbox and incoming email becomes tickets; customers' replies attach to the right ticket automatically.

Does it have AI?

No, and it doesn't pretend to. There isn't one AI call in the product.

Can I get my data out?

Yes. Any list your staff can see, they can export as CSV — and your customers can export their own data themselves, without asking you.

Is it ready for a large enterprise?

Honestly, not above about 200 seats — there is no SSO, SAML or SCIM yet. Below that, it is ready.

Stop asking your customers “which one?”

Support-OS is opening to a small first group of teams. If your support work is about things — circuits, machines, vehicles, units, properties, devices — we'd like you in it.

No card required — there is no card form yet. You'll get a real reply from the person who built it.