Relay

Relay is a help desk where every request that reaches a business lands in the same place. A customer fills in the form on your support page, emails an address directly, or an agent types up what they heard on the phone — all three turn into the same thing: a request with an owner, a priority, a clock and a history.

The product came out of the pile on our own desk. In a team running several products at once, support volume stops fitting into an inbox: who is looking at what, what was promised to which customer, and what has been waiting how long all disappear between email threads. Relay was written to bind those three questions to a durable record.

That is also where the first design decision came from: requests do not land in one pile, they land in projects. Every product, every team, every customer group gets its own project, its own queues and its own service promise. In a single installation, the software team's requests and the field team's requests never mix; each flows in its own lane.

• Project → queue → request: every team's work in its own lane
• The channel does not matter: portal, email and panel land in the same record
• Internal notes and customer-facing replies: same record, separate layers
• Two deployment models: cloud subscription or your own servers

In business support, the most tedious job is tying an incoming request to the right company. Showing the user a "pick your company" list is both tiresome and unreliable: it gets picked wrong, left empty, or changed on purpose. Relay solves this differently.

When a user already signed in to your own application clicks the support link, your application signs their identity and company with a project-specific secret and sends it along. Relay verifies the signature; if it is valid, the name, email and company come from the signature regardless of what the form says. The user cannot see or change them, and cannot open a request in someone else's name. An old signature is not accepted.

For a visitor using the link without a signature nothing changes — the anonymous form opens, the request still comes in, only the company stays empty and staff can attach it by hand later. So the same portal can be both your public support page and the support button inside your application.

• Company and user identity come from the signature, not the form
• Each project has its own secret; renewing it invalidates the old one
• Without a signature the anonymous flow works exactly as before
• Company records are global: the same customer is recognised across projects

You can use Relay in the cloud on a subscription: installation, backups, upgrades and monitoring stay with us, and you start working the day you sign up. As the team and the request volume grow, none of that becomes maintenance work on your side. And thanks to the module market only the part you use stays on — a module you switch off even disappears from the menu, so nobody has to learn a screen they never see.

The second model is the product installed on your own servers. Where customer correspondence must not leave the institution — public sector, defence, finance, healthcare and organisations running their own data centre — the same product lives inside your network, on your database. These are not two editions; it is the same core in a different place. There is no such thing as a cut-down version.

Authentication in both models goes through our central sign-on service: no password is stored in Relay, the session token lives server-side and can be revoked in one move. In an on-premises setup that service runs on your side too. The customer portal, on the other hand, asks for no identity at all; that door is deliberately open without an account.

• Cloud: subscription, zero maintenance
• On-premises: your servers, your database
• The same core — no feature gap
• Passwordless identity: central sign-on + revocable tokens