uSMS, the universal Service Management System, runs your services and the people around them: who uses a service, who delivers it and who owns it. When something fails, you see more than a ticket. You see what is at stake and who can act.
Most tools organise work by tickets and queues. uSMS organises it by relationships. Every service has three of them.
The organisation that holds the agreement, and the people in it who use the service every day. uSMS keeps the two apart, because they have different rights.
The desk that responds, and the technical owners who deliver into the service, layer by layer.
The person who stands for the service, its quality and its commitments. Named in the catalogue before anything happens.
Five real screens from uSMS. No sign-up, about two minutes.
Screens show the German interface; the English interface ships with release 1.5.
All screens show the state of development as of 22 September 2026. We do not commit that the functions shown will be part of a future release in this form.
We only list what you can see in a demo today.
Report, assign, coordinate, resolve. Always against a service, with the known-error check at intake and a major-incident path with coordinator and fixed update cadence.
Every service has a named service owner and, layer by layer, the technical owners who deliver into it. Staffed in one place, visible where the role acts.
Request a service or an access from the catalogue you are entitled to. Entitlement is checked before fulfilment, not after.
Recurring incidents become candidates; a problem ends as a known error or as a change. Standard, normal and emergency each have their own path to approval.
Commitments, offerings and request types live in the catalogue. The incident inherits them. That is why uSMS can say what is at stake without anyone typing it into the ticket.
The service-level report is generated from commitments and events, delivered to the customer and acknowledged by them. The acknowledgement is an audit event.
Event log, timers and jobs, outbox, load per area, licences. What enterprise buyers ask about in the second conversation.
The model knows the consumers of a service. Seeing that list from the incident, in one view, is what comes next.
Ask questions about your own services in plain language and get a recommended next step. With a deliberate limit: an assistant creates nothing and changes no status. It answers and suggests.
The processes you saw in the tour do not stand alone. They are part of a system in which every service has an owner, every case has a path and every change has its origin in the catalogue. The map shows that context in full. It is our map, not an advertisement.
The map shows the organising model, not the scope of a specific release. What of it is built in uSMS today is listed above under "What uSMS does".
We name uCRM and uRMS, we do not offer them yet. They are the proof that the architecture is universal, shown as they are, with their state of construction. How Cognie connects them is on the HRX page →
You do not have to move your whole landscape to find out whether this holds. Take one service area and run it completely in uSMS: your catalogue, your owners, your commitments, your customers. That is where the difference becomes demonstrable, and the decision stays reversible.
Ask us where your data is hosted, how access is controlled and where we stand on certifications. You get the current status in writing, including what is still open.
In half an hour we map one of your services, with the people who use it, those who deliver it and the person who owns it, and walk through an incident on it.