Table of Contents

Service Groups Explained: Controlling What Contacts See

Helpdocs Admin Updated by Helpdocs Admin

A service group is a named list of service types. You assign it to decide which service types a contact sees in the portal. This article explains how it works and why we designed it this way.

The short version

  • A service group is a list of service types.
  • You assign it at the global, account or contact level.
  • A more specific level overrides the broader one.
  • Most teams only need the global level.
  • What you assign is what the contact sees. There are no surprises.

How it works

You create a service group, add service types to it, and assign it.

Level

Purpose

How often you need it

Global

The default for everyone

Almost always. Often this is all you need.

Account

An exception for one account

Occasionally

Contact

An exception for one person

Rarely. Worth it only for high-value contacts, such as a VIP.

The most specific assignment wins. An account-level group overrides the global group for that account. A contact-level group overrides both the global and the account group for that contact.

Why we designed it this way

Most teams only need one global group

In most cases, one global service group is enough. The account level is for exceptions. The contact level is rare.

You don't need to micromanage a dedicated list for every person. If some service types are only for managers, put them in the group under a category called "Manager only". Contacts who shouldn't use it will ignore it, and the account's managers will use it.

You might say a strict list prevents misuse. Consider what happens next. The manager goes on holiday and appoints someone else. Or a manager delegates one task to a person who is not a manager. Will you adjust the list each time? Every one of those changes is a running cost. A small, shared list with a clear category costs less to run than a precise list that is always out of date.

What you see is what you get

With a service group, you can look at the group assigned to a contact and know what they see. There is no hidden calculation. This is the main benefit: visibility.

Why override and not addition

We chose override over addition for two reasons.

  1. It controls the size of a group. If assignments were added together, a contact's list would grow with every level, and it would be hard to know how many service types they would see. A short list is better for contacts. See Why a Small Service Catalogue Works Better.
  2. Addition can't remove anything. Adding service types is the common case. But sometimes an account or a contact should not see certain service types. Addition cannot do that. Override covers both adding and removing, because the more specific group simply lists exactly what that account or contact should see.

A good design has to cover every case, including removal. Override does.

Practical advice

  1. Start with one global group. See Quick Setup.
  2. Add an account group only for a real exception.
  3. Use a contact group only for high-value contacts. Don't create one for each person.
  4. Use categories such as "Manager only" instead of separate lists.
  5. Keep each group short. See Build a Small, High-Value Service Catalogue.

Contact groups are different

Contact groups let a team share tickets. You can also assign a service group to a contact group, but this was added later and is not the purpose of contact groups. See Contact Groups: Shared Tickets for Teams.

How did we do?

Why a Small Service Catalogue Works Better

Quick Setup: Service Groups for Teams With Limited Time

Contact