> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to build a service request catalog
- URL: https://blog.jestor.com/build-a-service-request-catalog/
- Published: 2026-09-16T18:53:15.000Z
- Updated: 2026-09-16T18:53:15.000Z
- Author: Bruno Bannach

A **service request catalog** replaces "send an email to support" with a list of request types, each carrying its own form, owner and deadline. In **Jestor**, each type is a form feeding the same process, so requests arrive complete and routed.

## Why open ended intake creates work

A free text request produces a conversation before it produces a resolution. The agent asks which system, which environment, which user, and each round trip adds hours.

Multiplied across a week, the clarification exchange often exceeds the resolution effort.

What a catalog fixes:

- Requests arriving without the information needed to act
- Back and forth before work can begin
- No consistent routing by request type
- Deadlines applied uniformly regardless of complexity
- No data about which request types dominate

## Designing the catalog

| Element         | What to define           | Example                     |
| --------------- | ------------------------ | --------------------------- |
| Request type    | A recognizable name      | New user access             |
| Required fields | What the agent needs     | System, role, start date    |
| Owner           | Who handles it           | The relevant team           |
| Deadline        | Expected resolution time | Varies by type              |
| Approval        | Whether one is required  | Manager approval for access |

## Step by step to build it

1. **Review three months of requests** and group them by what was actually being asked.
2. **Pick the ten most frequent**, which usually cover most of the volume.
3. **Create a form per type**, asking only what the agent genuinely needs.
4. **Use conditional fields**, so each requester sees only their relevant questions.
5. **Set routing and deadline per type**, since complexity differs.
6. **Add approval where required**, such as for access or spend.
7. **Keep one open category** for anything the catalog does not cover, and review it monthly.

## Why the open category is essential

A catalog without an escape route forces people to pick the closest wrong option, which corrupts the data and hides real needs. Keeping one open type, and reviewing what lands in it, is how the catalog grows to match reality.

## Why choose Jestor

In **Jestor**, forms support conditional fields, so one catalog can serve many request types without overwhelming anyone. Email and **WhatsApp** create records natively, **SLA** is tracked per stage, approval routing is built in, and an **AI** agent can classify anything arriving through the open category.

## Frequently Asked Questions

### How many request types should a catalog have?

Start with the ten most frequent, which usually cover most of the volume. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### Should I remove the free text option?

No. Keep one open type and review what lands in it to grow the catalog.

### Can different request types have different deadlines?

Yes. Routing and SLA are defined per type.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.