IT Service Catalog Template For Small IT Teams And MSPs

An IT service catalog is the list of services your IT team or MSP delivers, written for the people who request them. Each entry names the service, who can ask, how to ask, who owns it, how fast it happens, and what it costs.

The template below comes from the team behind SherpaDesk, a helpdesk and professional services automation (PSA) tool a small IT team can run alone. Copy it, fill in one entry per service, and publish it where your users already ask for help.

Key takeaways

• An IT service catalog is a document first. A shared page with one entry per service is enough for a team of three. What It Is
• Six fields do most of the work. Service, who can request, how to request, owner, target, and cost. Copy The Template
• Write down what isn't included. For an MSP, the "Not included" and "Cost" lines settle most scope arguments before they start. See The MSP Example
• Build it from your tickets. Last quarter's requests show what people actually ask for. How To Create One

What Is An IT Service Catalog?

TechTarget defines an IT service catalog as a list of IT resources and offerings available from an organization's IT provider. It "contains information about deliverables, prices, contact points and processes for requesting a service." Some catalogs also show the service category, the owner, the cost, and delivery timelines.

ITIL V3 made the use of a catalog a formal IT service management best practice, and ITIL defines it as a "database or structured document." You don't need the full ITIL service catalog process to get the benefit. The REMC Association of Michigan writes guidance for school technology staff. It notes that in smaller departments, the catalog "may just be a list of who is responsible for different technology resources and contact information."

Cornell's IT group keeps a service record for every service in its catalog. The record holds the description, audience, benefits, costs, aliases, and who the service is available to.

Service catalog vs service portfolio

The two lists overlap, but they answer different questions.

A small team can start without a separate portfolio and add one when it begins planning services ahead.

Service catalog vs self-service portal

The service catalog is the content. The portal is where people read it and place the request. TechTarget describes a customer-facing view, typically offered through a self-service portal, and a technical view for IT staff with what they need to deliver each service.

A portal with a weak service catalog behind it is a form nobody can use. A good catalog in a shared document still works on day one, before any portal exists.

Why A Small Team Needs One

Without an IT service catalog, the answer to "can IT do this?" lives in one technician's head. People find out what you do by asking, and every ask is a ticket.

One r/ITManagers poster described the problem. Their organization had long-tenured IT staff. The goal was "SOPs and a well-defined service catalog to ensure that the IT dept overall can continue if we lose any one of them." The same poster called converting repetitive tickets into defined, repeatable processes "time consuming but highly valuable."

REMC notes that understanding the service catalog lets staff know the best person or team to complete a request. Some catalogs list services the department does not provide, which saves a round of tickets.

For an MSP, the stakes are money. If the service catalog doesn't say what's included, the client assumes everything is. Then every new laptop, office move, or after-hours call turns into a conversation about the invoice.

The IT Service Catalog Template

Copy the block or download it. Fill in the header once, then copy the service entry once per service.

IT SERVICE CATALOG TEMPLATE
For a small IT team or MSP. Copy the service entry once per service.

CATALOG
Provider: [IT team or MSP name]
For: [company, client, school district, or site]
Catalog owner: [role that keeps this document current]
Version and date: [v1, date]
Next review: [date, at least once a quarter]
Support hours: [days, hours, time zone]
Anything not listed: [how to ask, e.g. a general request]

SERVICE ENTRY
1. Service name: [the words your users use, not tool names]
2. Category: [Accounts and access / Devices / Software /
   Email and files / Network / Security / Projects]
3. What you get: [one or two plain sentences]
4. Not included: [what people assume but don't get]
5. Who can request: [everyone / managers / named roles]
6. Approval: [none / manager / budget owner]
7. How to request: [form, portal link, email tag, phone]
8. Information needed: [link to the request form]
9. Owner: [role accountable for the service]
10. Done by: [team or person who does the work]
11. Target: [first response and done-within time,
    in business hours]
12. Cost: [included / billable at a rate / fixed fee /
    charged to a department]
13. Depends on: [other services, licenses, or vendors]
14. Status: [active / ending on date]
15. Last reviewed: [date and reviewer]

The header answers questions about the IT service catalog itself: whose it is, who keeps it current, and what to do when a service isn't listed.

How To Fill In Each Field

The table covers every line of an IT service catalog entry. The fields that cause the most rework get their own notes below it.

Who can request and approval

Write a role, not a person. Restrict purchases and access to data owners. Leave password resets open to everyone.

Springfield Public Schools does this in its service desk. Access to its "Purchase New Hardware" service is limited to principals, assistant principals, principal clerks, and technology coordinators. Everyone else is told to go through their school office for a quote. Its software purchase service adds a second gate: instructional software needs the Chief Instructional Officer's approval before IT review.

For an MSP, requesters are usually the client's named contacts; keep their names in the client record.

Target

Give two numbers: when the requester hears back and when the work is done. Count them in business hours and say which hours those are in the catalog header.

Keep the targets in the service catalog consistent with your service level agreement. The SLA sets the priorities, clock rules, and what happens on a miss. Our service level agreement template covers that side.

Information needed

Link to the request form instead of copying its questions into the service catalog. For the questions themselves, our IT ticket template has intake forms for access, devices, software, outages, and staff changes.

Cost: included or billable

Internal IT and schools often write "included" or name the budget a charge lands on. An MSP has to be exact here, because the service catalog line becomes an invoice line.

Filled-In Examples For An MSP And A School

Each example has an overview table and one complete entry. Targets use the header's support hours unless marked "any time".

A five-technician MSP

Example: say you run a five-technician MSP with 30 small-business clients on monthly per-user agreements. Your first IT service catalog might start with six services.

Here is new user setup in full, under the filled-in catalog header:

CATALOG
Provider: Example MSP
For: every client on a managed services agreement
Catalog owner: MSP owner
Version and date: v1, Nov 10, 2026
Next review: Feb 10, 2027
Support hours: Mon-Fri, 8 a.m.-6 p.m. Eastern;
  after-hours emergencies any time by phone
Anything not listed: email support with [Help]
  in the subject

SERVICE ENTRY
1. Service name: New user setup
2. Category: Accounts and access
3. What you get: Microsoft 365 account, mailbox, shared
   drive access, and MFA ready before day one.
4. Not included: buying the laptop (see Laptop
   replacement); training on line-of-business apps.
5. Who can request: the client's named contacts
6. Approval: a named contact's request is the approval
7. How to request: portal form "New user", or email
   with [New hire] in the subject
8. Information needed: the "New user" form,
   https://support.example.com/forms/new-user
9. Owner: service desk lead
10. Done by: any technician on the service desk
11. Target: first response within 4 business hours;
    done 1 business day before the start date when
    requested 3 business days ahead
12. Cost: included per user on the agreement
13. Depends on: a Microsoft 365 license, billed monthly
14. Status: active
15. Last reviewed: Nov 10, 2026, service desk lead

A small district technology team

A four-technician district team writes the same entries for staff and students. Costs land on budgets, not invoices.

The last row borrows Springfield's rule: only named school roles can request a hardware quote. The full entry for Chromebook repair:

CATALOG
Provider: District technology department
For: staff and students in all district schools
Catalog owner: director of technology
Version and date: v1, Nov 10, 2026
Next review: Feb 10, 2027
Support hours: school days, 7:30 a.m.-4 p.m. Central;
  a school day is a day on the district calendar
Anything not listed: helpdesk form "General request"

SERVICE ENTRY
1. Service name: Chromebook repair
2. Category: Devices
3. What you get: a working loaner, and the student's
   own device repaired or replaced.
4. Not included: chargers, cases, and devices the
   district did not issue
5. Who can request: teachers and library staff,
   for a student
6. Approval: none
7. How to request: helpdesk form "Chromebook repair",
   or bring the device to the school library
8. Information needed: the "Chromebook repair" form,
   https://help.example.org/forms/chromebook-repair
9. Owner: device lead
10. Done by: the building technician
11. Target: first response within 2 school hours;
    loaner the same school day (next school day if
    requested after 2 p.m.); repair done within
    5 school days
12. Cost: included; damage under the district device
    policy
13. Depends on: loaner stock at each school
14. Status: active
15. Last reviewed: Nov 10, 2026, device lead

Real IT Service Catalog Examples

Two public IT service catalogs, one district technology plan, and guidance for school technology staff show the same fields at a larger scale.

Cornell and Springfield show, per service, who it is for and how to ask; Palm Beach's plan requires both. Palm Beach's plan adds the service level agreement, and Cornell's pages add the cost. REMC sets the floor: a list of who is responsible, with contacts, already counts.

How To Create An IT Service Catalog

TechTarget's first step is the right one: take an inventory of every service you offer. A suggested order for a small team:

1. Pull last quarter's tickets

   Export them and sort by what was asked, not by what broke. Requests that repeat are your first services.

   Common mistake: starting from the tools you run instead of the requests you get.

2. Group them into 10 to 25 services

   Merge requests that follow the same steps. Put each service in one of five to eight categories users can guess.

3. Write each entry with the template

   Fill the six core lines of each service catalog entry first: name, who can request, how to request, owner, target, and cost. Add the rest in a second pass.

4. Check targets and costs against your agreements

   Every target should match your SLA, and every "included" should match the contract or budget.

   Common mistake: promising a target in the service catalog that the SLA doesn't support.

5. Test it on a few users

   Give three or four users a typical request each and ask them to find the service. Note the category they pick and whether they can tell who may ask, what it costs, and what happens next.

   Common mistake: testing with technicians, who already know where everything is.

6. Publish it where people ask

   Put it on the portal home page, link it in the support email signature, and send it to client contacts or staff once.

7. Review it every quarter

   Track three numbers: the share of requests that came in through a catalog form or the portal, the share left unclassified as "Other", and targets met per service. REMC suggests adding a service when enough repeated requests arrive outside the IT service catalog. For the target side, see SLA management.

Building an MSP service catalog

An MSP service catalog has a second reader: the person who signs the agreement. Write it so it can sit behind the agreement's services schedule. The schedule says which services the client gets. The service catalog says how each one works.

Start with the services in your standard agreement and mark each one "included". Then add the paid extras clients ask for most: hardware, projects, after-hours work, and on-site visits. Give each a cost line before the first request arrives.

If you're still writing the agreement, our managed services agreement guide covers the services and exclusions clauses. The service catalog can then point to the agreement, not repeat it. For setting the monthly number behind "included", see managed services pricing.

Best Practices And Common Mistakes

In an IT service catalog, categories fail first. One r/ITManagers commenter set the test: every request should narrow down to an obvious category "that an idiot in a hurry could categorise, consistently and repeatedly." "If everyone is just hitting other, other, other then it's failed."

The same commenter advised looking at it from the user's side. A user who wants an account on a product goes to accounts, then the product, then a new-account request. That path is your category, service name, and form.

Start your IT service catalog small and keep it current. Another commenter in the thread said of documentation: "Just start somewhere."

Do You Need Service Catalog Software?

Not to start. A shared document or one page on your portal holds an IT service catalog of 10 to 25 services. REMC notes that a service catalog can be a document or web page that students, staff, and others refer to.

Dedicated service catalog software earns its cost when requests need routing and approvals at volume. Look for these before you buy:

• Request types tied to forms. Picking a service should show only that service's questions.
• Routing by service. Each request should reach the owner in the entry.
• Targets on the request. The service catalog target should run as a clock on the ticket.
• Visibility by requester. Users see only the services they can request.
• Cost carried to billing. For an MSP, a billable service should arrive on the invoice with its rate.

Check which your current helpdesk already does.

Run Your Catalog In SherpaDesk

How this works in SherpaDesk

Each catalog service becomes a request type with its own form

You can set each service up as a class with a description, and link custom fields so users see only that service's questions. You can mark staff-only classes "For Technicians Only" to hide them from end users. Routing rules can send a class's tickets to a specific technician. SLA response and completion goals sit on priorities, so each service's target comes from its priority.

The cost line maps to billing. Each account can have its own rate plan; a contract can carry rate plans and prepaid hours. Flat + Hourly contracts bill included hours, then overage, plus extra billable services. You can run it for your own staff or for the clients you support.

A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin. Base Camp is $45 per agent per month ($40 billed annually), the first agent is free, forever, and the trial is 14 days free with no card.

See SherpaDesk Ticketing →

Frequently Asked Questions

What is an IT service catalog?

Can you provide an example of an IT service catalog?

What is included in a service catalog?

What are the 5 stages of ITSM?

Who should own the service catalog?

How often should you update a service catalog?