“Update the website” could mean correcting a sentence, adding an event, or reporting a broken page. Give each service its own request purpose, required inputs, expected output, and route. A requester should be able to choose a service before writing a long explanation to the wrong team.
Start with a small catalog of work the team actually offers. Three well-described services are more useful than a long menu whose names conceal different requirements. Keep the service owner and the date the description was checked beside each entry so someone can resolve an unclear boundary.
Open the complete example · Download the full HTML source
Describe the work with contrasting examples
Here is an original fictional catalog for a small community organization's web team. The services and document labels are demonstration content, not a live team's commitments.
S01 — Correct existing page wording. Use this when a published sentence needs correction. Supply the page address, exact current wording, proposed wording, and the factual source supporting the change. The expected output is a revised-text proposal for the named page. A new event page belongs under S02; a page that fails to load belongs under S03.
S02 — Prepare an event page. Supply the event title, intended audience, confirmed event details, source references, and the person maintaining those details. The expected output is an event-page draft. Missing dates or venues remain blank. This service does not promise registration handling or publication.
S03 — Investigate a page that fails to load. Supply the affected address, what happened, when it was observed, the browser/device if known, and permitted reproduction steps. The expected output is an investigation note describing what could be reproduced and what remains unknown. Do not send passwords or private account details.
Atlassian's service-catalog overview describes a requester-facing list of services, request options, and expectations. The three entries above apply that organizing idea to original example work. They do not reproduce a Jira setup or claim that a static HTML page creates requests.
Make the handoff route explicit
For a real catalog, name the maintained request destination for each service. It might be an existing request form or an agreed internal channel; use the destination your team actually maintains. Check that its title and required fields match the service description.
In this demonstration, the request destinations are not supplied. The example therefore shows “request route needed” as text. It has no pretend Submit button or invented mailbox. Browsing a service description creates no ticket and sends no notification.
Do not fill an unknown response time with a plausible number. If a team has a confirmed service commitment, include its source and specify what the clock measures. A first response, a draft delivery, and a published correction are different events. Keep any commitment that has not been agreed blank.
Test the boundaries with two requests
“The event date on our existing page is wrong” belongs with S01 when the task is to correct the supplied wording using confirmed information. “We need a page for a new event” belongs with S02 even if its title resembles last year's event. If the page cannot be opened, S03 needs the observed failure and reproduction context.
Read those cases with the people receiving requests. When two entries both appear to cover the same work, clarify their boundary or combine them before circulating the catalog. Keep an owner-confirmed route for requests that do not fit; do not invent another team's remit.
Copy the catalog brief
Create one complete HTML service catalog for the supplied audience.
Services actually offered and their owners: [PASTE]
For each: purpose, when to choose it, required inputs, output,
scope boundary, maintained request route and date checked: [PASTE]
Confirmed response/delivery commitments and sources, if any: [PASTE]
Agreed route for an unmatched request: [SUPPLY OR LEAVE BLANK]
Preserve the supplied service boundaries and distinguish draft,
investigation, response and completed delivery. Leave missing routes,
owners and time commitments blank with a specific next question.
Use labeled readable service sections and a reusable blank entry.
No invented services, service levels, mailboxes or live integrations.
Do not create a sending form or imply a request was submitted.
Return full self-contained HTML and the unresolved catalog fields.
Once the service is chosen, a service blueprint can trace the visible and backstage work needed to deliver it. Finish the catalog by confirming where each request goes, then keep that destination current when the team's offerings change.