Everything in context.

ITMDesk-Base is the Linux layer everything else stands on: the servers, their updates, their certificates, their databases and their logs, administered from one place instead of six terminal sessions and a spreadsheet of expiry dates.

It asks for as little as possible. Services share what they can rather than each carrying its own copy of everything, because the real cost of a platform is not the licence — it is the machine it demands, the memory it wastes, and the afternoon someone spends finding out which of its parts broke.

Sentinel watches it continuously, and what Sentinel sees does not stay inside Base: a service starting to fail becomes a ticket with its own history attached, and the fix becomes a procedure the next person can follow. That is the difference between monitoring something and knowing about it.

ITMDesk-FunLab is not software. It is the work of turning a process that currently lives in spreadsheets, e-mail threads and somebody's memory into an application running in production, in weeks.

Weeks instead of months, because it does not start from zero. Authentication, permissions, the record of who did what, storage, document handling and the infrastructure underneath already exist, already run, and are already the same ones the rest of the platform uses. What gets built is only the part that is genuinely specific to the problem.

ITMDesk-SM went from conversation to production in three weeks, development, infrastructure and deployment included. The number is only interesting because of what it says about the other ninety per cent: it was already there.

ITMDesk-Blue is where the machines are. Workstations and servers, Windows, macOS and Linux, with phones and tablets alongside them — inventory, telemetry, installed software, remote access, scheduled commands, and the record of who did what to which one.

The agents are the part that looks simple from outside. A macOS agent is not a Windows agent with a different icon: the permission model is different, the update mechanism is different, and what each operating system is willing to say about itself is different. Every one of them is its own problem, and every one of them still has to report into the same picture.

That picture is what makes the rest work. A ticket knows which machine it came from, who owns it, which contract covers it and whether its disk has been filling for a week. Nobody has to go and look.

ITMDesk-TicketDesk is the service desk: requests arrive, get routed, get answered and get closed, with the SLA tracked and the conversation kept.

What separates it from a service desk written over a weekend is what arrives attached to the request. The machine it came from, its owner, its history, and the last few times something similar was resolved and how. The suggestion drawn from those cases comes from the organization's own resolved tickets, not from the internet.

Every closed ticket makes the next one shorter. That is not a feature. It is what happens when the answers are kept in the same place the questions arrive.

ITMDesk-ProjectManager is where a demand becomes work with a shape and a date. Plans, tasks, owners and dependencies — enough structure to run a project, and not so much that running the tool becomes the project.

It is fed by what is already happening elsewhere. A ticket that keeps coming back is a sign that something underneath needs fixing. An ageing fleet is a project waiting to be named. The origin travels with the work, so six months later it is still possible to say why this was started.

AI helps set priorities and points at risk early. It proposes; whoever answers for the result still decides.

ITMDesk-LearningDesk holds what a team needs to know: onboarding, trainings, the content library, the documentation, the documents people have signed, and the shared passwords they are allowed to use.

It exists because knowledge kept in one person's head is an outage waiting for a holiday. A procedure written the night it was needed is worth more than a manual written in advance, and this is where it goes so that it outlives whoever wrote it.

The credentials sit here rather than in a spreadsheet for the same reason. Access has to be taken away the moment somebody changes role, and that only works when one place knows who holds what.