Table of Contents

Build a Small, High-Value Service Catalogue

Helpdocs Admin Updated by Helpdocs Admin

This is the proactive part of the advanced model. You choose a few service types that cover the most value, and you keep each one simple. For the reasoning behind a small catalogue, see Why a Small Service Catalogue Works Better.

The short version

  • Choose 5 to 10 service types that bring the most value.
  • Keep them at the root level.
  • Add a form only if the answers change what you do next.
  • Merge near-identical forms. Keep genuinely different ones.
  • Review every field: keep, move later, or remove.

Step 1: Choose your service types

Start from your history, not from your ideas. Use the Monthly Service Catalogue Review Checklist to see what people really submit.

A service type is worth keeping at the top if it meets one of these:

  • It is submitted often. It covers a large share of requests.
  • It makes a big difference when used. For example, an urgent issue form that gets the right people on a problem quickly.
  • It simplifies the work greatly. The information it collects saves several rounds of questions.

If a request is rare, don't give it a service type. Use an inline form instead. See Capture Requests the Catalogue Misses With Inline Forms.

The 5 to 10 figure is a UX guideline. It is about how many items a person can scan, and how many fit on one screen without scrolling. Adjust it to your portal layout.

Step 2: Keep them at the root level

Service types can be placed in categories, which adds a second step to browse. For a very small list, the extra step costs more than it saves. Put your top service types at the root level, so contacts see them straight away.

What your contact sees A short list on the first screen. One click to choose, no searching.

Step 3: Decide if each one needs a form

Ask one question: do the answers change what we do next?

Answer

Action

Yes. The answers decide who works on it, or how.

Add a form. Keep it short.

No. We only need a description of the problem.

No form. Subject and description is enough.

Maybe. It would be nice to know.

Collect it after the ticket is created.

Step 4: Merge or keep separate

When you review your forms, you will find two kinds:

Type

Example

Action

Near-identical

A software request with about three questions, copied for several accounts with small wording changes.

Merge into one shared form.

Genuinely different

A new user request that depends on the account's software, access and equipment.

Keep separate, or use one form with account-specific sections.

Don't treat every account-specific form as waste. Merge only when the purpose and questions are really the same.

Step 5: Review each field

For every question in a form, decide:

  1. Required. The ticket can't be handled without it. Keep.
  2. Useful but optional. Move it to the end, or collect it after the ticket is created.
  3. Not needed. Nobody uses the answer. Remove.

Each extra question is one more reason for a contact to give up.

Good setup work is often subtraction

Merging two forms, removing an unused field or retiring a service type nobody picks all make the portal easier to use. When you review, count what you removed as well as what you added.

How did we do?

Advanced Catalogue Model: Proactive, Reactive and Automated

Capture Requests the Catalogue Misses With Inline Forms

Contact