Getting Started with DeskDirector
DeskDirector Portals
Browser Support
What is the DeskDirector Admin Portal?
What is the DeskDirector Tech Portal
What is the DeskDirector Client Portal?
Desktop Portal
Managing Your Account
Admin Essentials
DeskDirector Features Overview
Logging in to DeskDirector
User Profiles & Profile Pictures
Managing Tickets with DeskDirector
Office Hours
Getting Started with the Solution Library
How Searching Works
Embedding Help Page Media
Get started with the DeskDirector Power Automate Connector
Features
Portal Customization
Forms
Service Catalogue
Service Catalogue Strategy
Service Catalogue Setup: Choose Your Path
Why a Small Service Catalogue Works Better
Service Groups Explained: Controlling What Contacts See
Quick Setup: Service Groups for Teams With Limited Time
Advanced Catalogue Model: Proactive, Reactive and Automated
Build a Small, High-Value Service Catalogue
Capture Requests the Catalogue Misses With Inline Forms
Use AI Categorisation Instead of Setup-Only Service Types
Monthly Service Catalogue Review Checklist
Automate Service Group Creation for Each Contact or Account
Contact Groups: Shared Tickets for Teams
Communication
Email Connectors
Notifications
Email Notifications
Actionable Messages for Emails
Real-Time Chats
Email Template Engine
Surveys
Broadcasts
Generative AI
DeskDirector with Generative AI
Ticket Summary for TECH Portal
Setting up AI Service Providers
Microsoft Foundry for DeskDirector
Knowledge Bases for AI Assistants
Custom Tools for AI Assistants
AI Assistants in DeskDirector
Advanced
Login & Authentication
Contact Groups
Custom Domains
File Storage
Dashboard
Accounts
Contacts
Approvals
Tags
Task Lists
The Learning Center
Portal Deep Linking
Auditing & Analytics
Microsoft Power Automate
Actions
Solutions
Featured Solution: Teams Ticket Discussion
Power Automate Template Gallery
Featured Solution: Ticket Briefing
Power Automate Administration
DeskDirector Power Platform Connector Reference
Power Automate Connector - Setting up your first flow
Microsoft Teams App
Introducing the DeskDirector for Microsoft Team App
Installing the Microsoft Teams App (Client Mode)
Installing the Microsoft Teams App (TECH Mode)
Setting up Tags for Teams Discussions (TECH Portal)
Branding the DeskDirector Teams App
DeskDirector Teams App Notifications
Contact Groups Integration with Microsoft Teams
Setting up Content Security Policy (CSP)
Advanced topic: Setting up Tech & Client Mode in the same tenancy
Integrating Microsoft Teams with DeskDirector Tech Portal
Smart Alerts for TECH Users
Integrations
Developer Resources
Getting Started
What is the Toki Iti API
API Versions & Routes
Roles & Scopes
Authorization Options
Querying the API
How to Change an Entity Through the API
API Key Authorization
OAuth Fundamentals
Understanding OAuth for Tokity Integrations: Key Concepts
OAuth Authorization Code Flow: How an App Gets Access to Tokity
OAuth App Registration
How to Register an OAuth App to Integrate with Tokity
Choosing an OAuth App Type: Confidential vs. Public Apps and Client Secrets
OAuth Personal Secrets: What They Are and When to Use Them
OAuth Administration
Configuring OAuth Settings in Tokity
Managing OAuth Authorized Sessions and User Consent
Granting OAuth Admin Consent at the Root Level
API Response Control
Uploading Attachments (Ticket API)
The Prefer Header — Overview
Controlling Returned Data (Ticket API)
Controlling Returned Data (Form Result API)
Controlling Returned Data (Workspace API)
Workspace Ordering
How Workspace Ordering Works
Creating and Reordering Workspace Groups
Adding and Reordering Tickets in a Workspace Group
Data Sync & Notifications
Delta API: Tracking Changes Over Time
Webhooks vs. Events — Differences, When to Use Which
Verifying Webhook and Event Payloads (HMAC Signature)
Ticket Widgets
Ticket Widget: Overview
How the Widget Is Requested
Ticket Widget Anatomy and Styling
Ticket Widget Actions: Leading, Secondary and Primary
Ticket Widget: Progress Type
Ticket Widget: List Type
Ticket Widget: Description Type
Ticket Widget: Form Type
Ticket Widget: Control When a Widget Refreshes
Ticket Widget: Form Results and State Across Steps
Ticket Widget: Error Responses and Debugging
Ticket Widget: Building a Multi-Step Request
Glossary
Security
Troubleshooting
Troubleshooting via Web Developer Tools
Permissions & Access - Common Issues
Contact DeskDirector Support
Troubleshooting DeskDirector Connection Issues
Desktop Portal - Common Issues
Contact Impersonation
Approvals - Common Issues
Microsoft Teams App - Common Issues
Email & Email Delivery - Common Issues
Login & Authentication - Common Issues
DeskDirector Desktop App - Installation Issues
Table of Contents
- All Categories
- Features
- Service Catalogue Strategy
- Why a Small Service Catalogue Works Better
Why a Small Service Catalogue Works Better
Updated
by Helpdocs Admin
The service catalogue lets contacts choose the kind of request they want to make. A small, well-chosen catalogue is easier to use than a long one. This article explains why, and shows how real service providers set theirs up.
The short version
- People scan a list. They do not read it.
- Contacts are often in a hurry, or worried, when they ask for help.
- If a contact can't find what they want quickly, they may pick any option or send an email instead.
- The catalogue can't force anyone to use it, so it needs to be easy to use.
- The service providers with the most portal users keep their service groups small.
Think about the contact's moment
Most contacts don't open the portal for fun. Something has gone wrong, or they need something done soon. They may be stressed, and they may be in the middle of other work.
In this moment, a contact has very little patience. They want to know one thing: "Has my request been received?"
This should shape how you design your catalogue:
- Make the choice quick. A short list with clear names helps them decide in seconds.
- Keep forms short. A long form feels like a test. A person in a hurry will skip it, guess the answers, or leave.
- Collect only what you need to start. If you can collect information later, collect it later.
- Let them submit first. Once the ticket is created, the contact can relax. They know someone is working on it. You can then ask for more details through a comment, a follow-up question or an inline form.
The goal of the portal is to help the contact, not to collect as much data as possible. A contact who has submitted a ticket quickly is more likely to answer follow-up questions calmly. A contact who was forced through a long form first may be frustrated before you have started.
How people use a catalogue
A contact opens the portal with one goal: get help. They look at the list of service types and decide in a few seconds. If nothing looks right, they stop looking.
As a guideline, aim for 5 to 10 service types that fit on one screen without scrolling. This is a UX guideline, not a hard limit. The right number depends on your screen layout and your contacts. The principle is simple: the more choices you show, the harder it is to choose.
Contacts who can't find the right service type may choose a random one or send an email. The catalogue can't stop them. That is why it should be easy to scan.
What real service providers do
We checked the three service providers with the most contacts using the client portal. The figures below are monthly, from 1 September to 1 October 2026 (local time). Names are removed.
Provider A | Provider B | Provider C | |
Unique contacts using the portal | 2,115 to 2,243 | 4,034 to 4,051 | 3,644 to 3,670 |
Portal activities (browsing, creating tickets, comments) | 30k to 33k | 51k to 54k | 54k to 55k |
Form results submitted | 2.25k | 295 | 1.12k |
Unique forms used | 102 | 47 | 64 |
Service groups | 117 | 79 | 76 |
Service types per service group | 1 to 10 | Mostly 3 to 6, some 7 to 10 | 7 to 12 |
What stands out
1. Every service group is small. In all three, a service group holds about 1 to 12 service types. None of them show hundreds of choices to a contact. This fits the 5 to 10 guideline.
2. Many small groups, not one big one. These providers have 76 to 117 service groups each. Instead of one large catalogue, they have many small ones matched to an account or a need.
3. Most forms are account-specific. In Provider A, 95 to 99 percent of the forms used are account-specific. In Providers B and C, most forms are account-specific too. Each account often has its own version of a form, so the number of unique forms grows quickly.
4. A few forms do most of the work. In Provider B, 124 of 295 form results came from one form, "Support - Urgent Issue". Another 26 came from the default new user onboarding form. In Provider C, 110 came from the IT support form. The rest were spread across many account-specific forms.
5. Thousands of contacts, relatively few form submissions. Provider B had about 4,000 contacts using the portal in a month, but 295 form results. Many contacts browse or comment without submitting a form. Not every request needs one.
What this means for your setup
- Keep each service group small. The providers with the highest portal use do this.
- Keep forms short. Ask only what you need to start the work.
- Collect the rest later. Create the ticket first, then ask for more details.
- Add a form only when the answers change what you do next. Many requests work well without one.
- Watch for copied forms. If the same request exists once per account, check whether one shared form would do.
- Make the catalogue easy to scan. Clear names and a short list matter more than a long list.