Subscribe to GEN
Login to GEN
GEN have been in enterprise IT since 1988. We have never run an advertising campaign and we have never bought a lead: clients arrive because somebody who already uses us said so. That is a slower way to build a business and a considerably harder one to fake.
We hold no software partner status, no reseller margin and no vendor incentive with anybody, so nothing we recommend earns us a commission. When we tell you a product is the wrong answer, there is no lost rebate behind the sentence.
This is how we work, and it applies to everything we support: Proxmox, Linux, Microsoft, Asterisk and FreePBX, Synology, HPE, DrayTek, Apple and the legacy systems other firms have stopped answering the phone about.
Most of what the market sells as support is a queue, a script and an escalation path that ends at a vendor. That works well enough for a laptop that will not print. It is the wrong instrument entirely for a production cluster, a soft-switch carrying live calls, or an array holding the only copy of something.
At this scale a wrong action costs far more than a slow one, and the damage is nearly always done in the first twenty minutes by somebody competent enough to be dangerous. Restarting the service that was about to flush its buffer. Failing over to the node with the stale copy. Rebuilding the array before anybody read which disk actually failed. So the job is mostly judgement: knowing which actions are reversible, working out what a change puts at risk before making it, and being willing to tell a customer losing money by the hour that the safe fix takes four hours and the unsafe one takes ten minutes.
Round the clock cover is where that ownership normally gets dropped, so we run five shifts a day rather than three, each overlapping the next by two hours. A handover is therefore a conversation between two engineers who are both awake and both looking at the same case, not a note left in a ticket. It costs us more engineers than the pattern the rest of the industry runs on, and it is why a fault opened at four in the afternoon is still understood at four in the morning.
Not every case deserves the same treatment, and pretending otherwise means giving mediocre service to everybody. Queued tickets are worked in rotation: a printer that will not print, a question about hosted email or telephony. Each reply returns the ticket to the queue, so successive responses may come from different specialists. On SLA4 at nine to five that is entirely appropriate, and you have not paid for it to be otherwise.
Pinned tickets never go back in the queue. If a system is down, if SLA8 or SLA9 applies at one hour and thirty minutes round the clock, or if one of the emergency teams in Infrastructure, Virtualisation or Cloud is involved, the ticket is pinned to a single specialist who stays with it until it is resolved, until you park it, or until the shift handover. Your replies are actioned immediately, with the specialist effectively sitting waiting on them.
Which is why we measure SLACK, the latency between responses, ours and yours alike. On a pinned ticket every minute of delay adds a minute to the time to fix, so it governs the case, and it is the one thing we will chase you about. Different parts of one estate can sit at different service levels, so production can be pinned while a development node is queued.
Every ticket is triaged the moment it arrives, linking your past cases, the relevant knowledge base articles, your site records and your system configurations, so the specialist opens a case that already holds the context.
Underneath your single thread, internal tickets and tasks bring several disciplines onto the same problem. A bounce-back with the headers attached goes to a messaging specialist; if the cause is DNS they reassign it, and if they merely suspect DNS they raise an internal question alongside your ticket so the DNS team can answer without the thread being lost. You are never asked to relay information between teams.
The whole process is written up in How and Why: The HelpDesk.
Every fault we take on runs through the same four steps, whatever the platform. The temptation under pressure is to start typing, and that is how a one hour outage becomes a three day one. It is also the difference between an engineer and somebody with root.
Before anything is touched we capture the state: logs, configuration, cluster and quorum status, storage health, guest detail and metrics. Our diagnostic scripts do it in a single command. A fault investigated after somebody has started changing things may never be explained at all.
We establish the actual cause, not the first plausible one. That means reading the evidence properly, following it into the source code where the logs stop short, and accounting for the edge cases that make a fault intermittent rather than constant.
The fix is decided before it is carried out, with its consequences worked through: what it touches, what it restarts, and what it puts at risk. Where data could be affected, taking a snapshot, clone or copy of whatever the fix might break is part of the plan, not an afterthought.
The plan is executed in an agreed window by an engineer who knows what every step is for, with the fallback already in place, and with you informed as it happens rather than after the event.
Then the PIR, our post incident report: what failed, what was found, what was done and what will stop it happening again. It is written by the specialist who managed the case, a copy comes to you, and on SLA8 and above a manager adds their own review. The findings feed back into our diagnostics, our monitoring and the knowledge base. It does not fit the acronym, and it is not optional.
We use AI heavily on the HelpDesk, and we are going to be precise about where, because the industry is currently using that word to mean something very different. Ours runs on our own hardware in our own UK data centres. The models are hosted locally, they are not a third party API, and nothing we process on your behalf is shared with anyone or used to train anybody's product. A diagnostic bundle carries your configuration, your addressing, your hostnames and occasionally your credentials: the moment that leaves the building it is somebody else's asset. Ours never leaves the building.
It reads, sorts and correlates. It triages the alert stream so a failed backup becomes a ticket without anybody watching every run, parses a diagnostic bundle so the specialist sees the relevant lines instead of the other four thousand, and finds the three prior cases out of thirty-seven years that look like this one. It does not decide the cause, choose the fix, or touch your systems. Those are judgement calls with consequences attached, and judgement is what you are paying an engineer for.
Your solicitor does not sell you five years of legal cover at a fixed monthly fee. You place a sum on account and draw against it, and so does your accountant, and very nearly every professional service anybody buys. Only IT support insisted otherwise, inherited more or less directly from the way IBM sold maintenance on machines that cost more than the building they stood in.
So there is no support contract, no minimum term and no notice period. Clients are onboarded properly, with terms agreed, an account opened and hours purchased, so nobody arrives unknown at three in the morning. What there is not is an agreement that ties you in: you buy hours at our published rates, you use them when you need them, and what you do not use carries over.
We sold the fixed price multi-year model ourselves for years, so we know precisely what it is: an estimate with a margin on it, and the profit living in the exclusions rather than the price. We stopped in 2010 and have not missed it. If you would rather go elsewhere, go, on any day you like, with no termination clause to negotiate your way out of. We can afford to offer that because clients do not leave, and a firm that needs five years of your signature to keep you is telling you something about its service, and about the invoices you have not seen yet.
Support delivered by specialists who assess risk before acting, take responsibility by name for what they do, and stay with a case until it is closed. GEN operate no outsourced first line, no script and no escalation path that ends at a vendor queue. Every fault runs through the SAPR method: snapshot the state, analyse the cause, plan the fix with its consequences considered, then remedy it.
No. There is no support contract, no minimum term and no notice period. Clients are onboarded with terms agreed and an account opened, then buy hours at published rates and use them as they are needed, with unused hours carried over. A fixed cost maintenance agreement is available for anyone who prefers a predictable annual figure, but it is optional.
Queued tickets are worked in rotation by first line, with each reply returning the ticket to the queue, which suits routine work on lower service levels such as SLA4. Pinned tickets are assigned to a single specialist who stays with the case until it is resolved, parked at the customer's request, or handed over at the end of a shift. Pinning applies where a system is down, where SLA8 or SLA9 cover applies, or where an emergency team is involved.
SLACK is the latency between responses on a ticket, measured dynamically by GEN for both the specialist and the customer. On a pinned ticket every minute of delay extends the time to fix by a minute, so SLACK is the governing metric on urgent work. It matters far less on queued tickets, where responses are handled in rotation.
No. No ticket response a customer receives from GEN is AI-generated, and at no point is a customer conversing with a machine. GEN use AI to triage alerts, parse diagnostic bundles, correlate monitoring data and search prior cases, and to assemble the closing technical and executive summaries from a post incident report a specialist has already written. It never determines a cause, chooses a fix, touches a customer system or writes a reply. Every model runs on GEN's own hardware in GEN's own UK data centres, with no third party API involved, so customer data is never shared or used to train an external product.
The 24 hour day is covered by five engineering shifts rather than the usual three, with each shift overlapping the next by two hours. Handovers are conducted live between two engineers who are both on duty and reviewing the same case together, rather than passed as written notes, so an ongoing fault keeps its context through the night.
No. GEN's engineers are in-house and UK based, and the specialist who takes a case is the specialist who works it. There is no first line queue filtering cases before a technical person sees them.
Proxmox VE and Proxmox Backup Server, VMware, Hyper-V, Linux in all its major distributions, Microsoft server and cloud platforms, Asterisk and FreePBX, Synology, HPE, DrayTek, Teltonika, Apple, and legacy systems including CentOS, Windows XP and Windows 7 that other providers have withdrawn support for.
A post incident report is produced covering what failed, what was found, what was done about it and what will prevent a recurrence. A copy is provided to the customer, and on SLA8 and above a manager reviews how the case was handled. The findings feed back into GEN's diagnostic tooling, monitoring thresholds and knowledge base.
GEN have one objective, and it is not to be the biggest or the cheapest. Everything above follows from it: thirty-seven years of enterprise experience, specialists who assess risk before they act, the SAPR method applied to every fault, technology used to sharpen our people rather than replace them, and no contract holding any of it together.
Whether you need a second pair of hands on an existing estate, cover for production infrastructure at any hour, or somebody to take on the systems your last provider gave up on, our team can scope it with you.