Service catalogNEW
Whoever needs something internal today opens a blank case and writes down whatever they remember. Nobody knows what can be asked for, the case arrives missing the obvious detail, the agent asks, the person answers the next day, and the SLA deadline is gone in that back and forth. The catalog replaces the blank case with a storefront: every service, from a new laptop to a system login, is an item carrying its own form, its own queue and its own priority. The person picks the service, answers the questions that service asks, and the system opens a real case, already filled in and in the right place. There is no parallel request: it is the same case the console opens, the SLA times, automations move and the API sees. And, for the first time, you can answer how many times each service was requested this month.
- A storefront with search by name, description or code, and categories in a tree, so an item can live under IT and, inside it, under Access.
- A form per service: up to 40 questions in nine types (text, long text, select, email, phone, number, date, date and time, yes or no), each required or not, with its own help text.
- Conditional questions: a field only shows up when another field holds a given value, and whatever stays hidden is neither required nor stored.
- Default queue, priority and category per item: the case is born where it belongs, with no manual triage.
- A composed subject: you mark which answers go into the subject, so a hundred requests for the same service do not arrive with a hundred identical subjects.
- Approval per item, in the same approval engine the company already uses, with no second engine.
- The request freezes a snapshot of the form: changing the questions today does not make yesterday’s request lie.
- Submitting the same form again returns the request that already exists, instead of opening a second case and buying two laptops.
- A report of how many times each service was requested, counted from the link to the item, never from a counter kept by hand.
Free in Sellio, you only pay for the machine
A service catalog with its own forms, queues and approvals is usually a separate ITSM module. In Sellio it comes with the help desk: you only pay for the machine.
The request arrives complete
The service asks its questions at request time, so the agent does not lose a day asking the obvious and the deadline does not disappear in the back and forth.
Nobody has to guess what can be asked for
The storefront shows services by category, with search by name, description or code, and each one explains what it is before the person fills anything in.
The queue receives work already triaged
Queue, priority and category come from the item, and the subject already says what it is about, so nobody has to reclassify what just arrived.
What gets asked for becomes measurable
The report shows how many times each service was requested, which is the question that simply has no possible answer today.
The request becomes a real case, with a protocol number, queue, SLA, console, automations, API and history: everything the product already gives any case.
The answers go to two places with different purposes: as readable text inside the case, for the agent to read, and structured on the request, for the report to count.
Approval reuses the house engine, the same one behind every other approval, so policy, delegation and audit trail apply here with no new rule.
The catalog starts empty: until someone registers an item, opening a case works exactly as it did yesterday.
From the blank case to a storefront
The question the catalog answers is a simple one that has no answer today: what can I ask for? With no storefront, every person invents their own way of asking for the same thing. With no form per service, the request arrives without the detail the agent will have to ask back for, and that back and forth is what eats the deadline. With the catalog, whoever administers builds the list once, in Settings: categories, items, and the questions each item asks. Anyone in the company opens the same screen, picks and requests. A catalog only the administrator can see would have nobody to serve.
The form belongs to the service, not to the case
Each item carries the questions that service needs: up to 40 of them, in nine types, each required or not and with a help text underneath. A question can be conditional, showing up only when another answer holds a given value, and a field that stayed hidden is neither required nor stored, because demanding an answer to a question the person never saw is the fastest way to make a form impossible to submit. Reading is tolerant about format and strict about meaning: "3,300.00" and "35%" come in as numbers, dates accept the shapes people actually write, but February 30th is refused instead of quietly rolling into March 2nd. Two questions with the same key are refused at save time, otherwise the second would overwrite the first one’s answer with no error at all.
Where the case is born, and what it looks like
The item sets the destination queue, the priority and the case category, so the request lands with the right team at the right weight, with no manual triage. The subject is composed from the service name plus the answers you marked as part of the subject: without that, a hundred "System access" requests arrive with a hundred identical subjects and the queue becomes unreadable. The case description carries the answers as question and value pairs, in the same format the portal already uses, so the agent reads everything without opening another screen. And the case channel comes from your company’s channel map, not from a literal written into the code.
Approval per item, with no second engine
An item can require approval, and that requirement is data on the item, not a new engine: the decision is made by the same approval engine the company already uses elsewhere, with the same policies, the same delegation and the same audit trail. The case opens right away, and a pending approval blocks resolution through the path the console already has. Holding the case back until someone approves would leave the requester looking at nothing, with no protocol number, no queue and no SLA. The request has three states, awaiting approval, open and rejected, and the state is read from the approval on every query, never copied into a column: a copy would quietly drift the first time an approval was decided somewhere else. One honest note the screen itself says out loud: the engine answers "approved" when no policy matches, so ticking "requires approval" in a company with no policy registered blocks nothing. Set the policy first, the requirement after.
Deactivating is not cancelling, and deleting is not always possible
Deactivating an item means "stop asking for this", never "cancel what is in progress". Cases already opened for that service stay open, with the same queue and the same deadline, and past requests keep counting in the report. Cancelling somebody else’s work through a configuration click would be a consequence nobody asked for and the screen does not warn about. For the same reason, an item that has already been requested cannot be deleted, only deactivated: deleting it would take with it the meaning of every past request and the report would quietly start lying. And a category with items inside is not deleted either, because the items would be left with no taxonomy and the storefront with a ghost section. Moving the items, or deactivating the category, is the way.
The snapshot that keeps history honest
The item stays editable forever, and that is exactly what makes the freeze necessary. Every request keeps a snapshot of the questions as they were when the person answered, along with the form version number and the service code and name of that day. Renaming a question today, or renaming the service, does not rewrite what was asked for in March. The form version goes up when the form changes, and only then: renaming the item or changing its queue is not a form change, and inflating the number on every save would drain the meaning out of the number the request freezes. From the other side of that link comes the metric that justifies the catalog existing, how many times each service was requested, counted from the requests themselves and not from a counter incremented by hand.
- 1
In Settings, Service catalog, whoever administers creates the categories and the items.
- 2
Each item gets its questions, its destination queue, its priority and, where it applies, the approval requirement.
- 3
Anyone in the company opens the same screen, picks the service and fills in the form.
- 4
The case opens in the right queue with the answers inside, and the request is recorded for the report.
A new laptop for a new hire
The item asks for the model, the cost center and the start date, requires the manager’s approval and lands in the IT queue at high priority.
Access to a system
The "which system" question is a select, and the "which profile" field only shows up after the system is chosen, so nobody answers what does not apply.
A second copy of a document
The same person can ask twice on the same day, on purpose; what does not happen is a double click opening two cases for the same request.
The service is retired
You deactivate the item and it leaves the storefront right away, without touching the cases already in flight or erasing the history of who asked for it.
Is a request a case, or something separate?
It is a real case, with a protocol number, queue, SLA, console, automations, API and history. There is no parallel request with a life cycle of its own.
Who can build the catalog, and who can request?
Building it belongs to whoever administers, because an item sets queue, priority and approval, which is to say it sets work for other people. Requesting belongs to anyone in the company.
Does deactivating an item cancel the requests in progress?
No. Deactivating means "stop asking for this": cases already open stay open, with the same queue and the same deadline.
Can I delete an item that has already been requested?
No, only deactivate it. Deleting would take with it the meaning of every past request and the report would start lying. The same holds for a category with items inside.
If I change the questions, do old requests change too?
No. Every request keeps a snapshot of the questions as they were when the person answered, with the form version and the service name of that day.
Does ticking "requires approval" guarantee someone will approve it?
Only if an approval policy matches the case. The engine answers "approved" when no policy matches, and the screen says so right where you turn the requirement on.
Does a double click open two cases?
No. Submitting the same form again returns the request that already exists. Asking for the same service again, on purpose, still works: two second copies are two requests.
Do I have to set the catalog up for the help desk to keep working?
No. Until someone registers an item, opening a case works exactly as it did, so you can adopt this one service at a time.