Service catalog spreadsheet for teams before portal tools

Why teams lose track of service details

Teams rarely lose service details all at once. The mess builds slowly. Then one day nobody knows who owns a service, where it runs, or which chat to use when it breaks.

A lot of it starts with naming. People call the same system three different things. The repo says "billing-api," the team calls it "payments," and older staff still call it "the Stripe thing." After a few months, those nicknames take over. Search stops working because nobody uses the same name twice.

Ownership drifts just as fast. A developer leaves, a manager changes teams, or a contractor hands work back to the company. The service still runs, but the notes stay frozen. When something goes wrong, people tag the person who used to own it. That person often says, "I haven't touched that in a year."

Support questions make it worse. In many teams, there is no clear support contacts list, so every issue lands in the loudest group chat. Finance asks product. Product asks engineering. Engineering asks around for context. A five-minute answer turns into an hour because the question started in the wrong place.

New hires feel this first. They join, open the codebase, and see ten services with unclear names and no plain-language notes. Instead of doing useful work, they spend days asking who owns what, where the docs live, and which service matters for a customer request. That lost time adds up fast.

Growing companies often assume people will "just know" the basics. That works when five people sit in one room. It breaks when the team doubles, adds contractors, or supports more than one product. Memory does not scale.

That is why a service catalog spreadsheet works so well as a first step. It is simple, but it gives the team one place for service names, owners, links, and support contacts. Even a plain internal service inventory cuts repeated questions and stops important details from living only in one person's head.

If your team already argues about what a service is called, the first problem is not documentation. It is shared memory.

What the first sheet needs

Start small. A service catalog spreadsheet works best when each row points to one live service that people actually use, support, or depend on. Skip old experiments, abandoned repos, and half-built ideas. If a service is in production or affects customers or staff, give it a row.

Names matter more than teams expect. Write the service name people would understand on a stressful day, not the clever internal nickname from an old sprint. "Billing API" is clear. "Falcon" usually is not unless everyone knows what Falcon does without asking.

Each row should answer three questions fast: what is this, who owns it, and where do I go when it breaks? If the sheet cannot answer that in 20 seconds, it will decay.

A good starting set is short:

• Service name
• One-line description
• Primary owner
• Backup contact
• References for docs, dashboards, and support chat

That one-line description does a lot of work. Keep it plain and specific, like "Sends password reset emails" or "Stores customer invoices and payment history." People should not need a technical background to understand it.

Ownership needs one real person, not only a team name. "Platform team" sounds tidy, but it does not help when someone needs an answer now. Put one owner who makes decisions, plus one backup who can step in during leave, travel, or simple bad timing.

You also need a trail around the service. Most teams need at least a pointer to docs, a dashboard or alert view, and the support channel where people ask for help. That can be one column each or one grouped notes field. The layout matters less than having those paths written down.

A simple example shows why this works. Say a growing company has a checkout service, an admin panel, and a reporting job. The checkout service belongs to Maya, with Ben as backup. Its row says it "creates orders and takes card payments," with references to the runbook, the monitoring view, and the support channel. When payments fail on a Friday night, nobody wastes 30 minutes asking who owns checkout.

Keep the sheet boring. Boring works. If people can scan it, trust it, and update it in under a minute, they will keep using it.

How to set up the columns

A good sheet falls apart when each row turns into a mini essay. Keep the first view short enough that someone can scan a few dozen services quickly and still spot who owns what.

Start with the columns people check most often. In a service catalog spreadsheet, that usually means service name, a short purpose, the main link, team, owner, and support contact.

Do not pack those into one cell. "Billing API - Platform - Mia - billing-help" looks neat for a few days, but nobody can sort it cleanly or filter it when something fails.

Owner, team, and support contact should stay separate because they answer different questions. The owner approves changes. The team handles the day-to-day work. The support contact tells people where to go when production is down or access stops working.

A practical starting order looks like this:

• Service name
• Short purpose
• Main link
• Team
• Owner

After that, add support contact, status, environment, and last review date. Those columns help during real work, not just during documentation.

Status can stay simple: active, planned, retired, or migrating. Environment can be production, staging, development, or internal only. Last review date is the field that keeps the sheet honest, because stale rows often look correct right up until someone needs them.

Use drop-downs anywhere people repeat the same values. Team names, status, environment, and service type are the usual ones. This avoids small spelling mistakes that split your filters into junk values like "Platform," "platform," and "Platfrom."

Keep free-text columns short. If a service needs a long note about contracts, backups, or special access rules, put that in a separate notes tab or source document and keep only the reference in the main sheet. The first tab should answer basic questions in seconds.

For example, one row might show "Auth service" as the name, "handles sign-in" as the purpose, an admin URL in the link column, "Core product" as the team, one person as the owner, and a shared chat or mailbox as the support contact. Add "active," "production," and the latest review date, and the row becomes useful without becoming bloated.

Freeze the header row on day one. Then sort by owner or team, depending on how people usually search. Most teams look for "who owns this?" before anything else, so that sort order often saves a few minutes every week.

How to build it in one week

A first service catalog spreadsheet does not need a project plan, a budget, or a tool review. One shared sheet and five focused workdays are enough for most teams. The goal is simple: create one usable internal service inventory that names each service, who owns it, and who people contact when something breaks.

Start with the services you already know. Pull names from team docs, old onboarding notes, cloud accounts, monitoring dashboards, ticket categories, and the apps people mention in chat. Do not wait for a perfect list. If a service is real and someone depends on it, add a row.

A simple week can look like this:

• Day 1: Create the sheet and add every known service, even if half the columns are blank.
• Day 2: Send it to each team lead and ask them to fill in missing rows, owners, and support contacts.
• Day 3: Clean up duplicates and pick one clear name for each service.
• Day 4: Confirm every owner and one backup contact.
• Day 5: Assign one maintainer and set one rule: new services are not "done" until the row exists.

The duplicate step matters more than most teams expect. One group calls it "billing api," another says "payments service," and support writes "checkout backend." That turns a useful sheet into a guessing game. Pick one name, keep old names in a notes column if needed, and move on.

Owner checks should be direct. Ask, "If this service fails at 2 p.m., who answers first? If that person is out, who is next?" You do not need a committee. You need one primary owner and one backup who both say yes.

A growing company with 25 to 40 services can usually finish this in a week if the request comes from one manager with enough authority to get replies. Without that push, the sheet tends to stall.

The last step is the one teams skip. Someone must maintain the sheet. Not "the team." Not "engineering." One person. That maintainer does not need to update every row alone, but they need to chase missing details, remove stale entries, and keep names consistent. That habit often makes the difference between a sheet people trust and one they ignore.

A simple example from a growing company

A 35-person software company can look organized from the outside and still ask the same questions every week: who owns this service, where are the docs, and which dashboard shows whether it is broken? A service catalog spreadsheet clears up more of that confusion than most teams expect.

Picture a sales rep on a Tuesday afternoon. A prospect tries to sign up, the confirmation email never arrives, and the deal stalls. Sales does not need a deep technical answer. They need the right person, fast.

Instead of asking in chat and waiting, the rep opens the sheet and searches for "signup service." One row gives them what they need: the owner is Maya, the support contact is Ben, the docs live in the product docs folder, and the service health dashboard sits in Grafana under the signup tab. In two minutes, sales has a real update for the prospect, and the engineer who owns the service already knows where to look.

That same row helps new people even more. A new engineer joins on Monday. By Wednesday, they get their first support task: check why signups dropped after a config change. Without a sheet, they would ask three people, search old messages, and still miss the right dashboard. With the internal service inventory in place, they open the row, check the docs, open the dashboard, and start with facts instead of guesses.

The backup contact matters more than teams think. In December, Maya goes on holiday. A billing partner reports that new users cannot finish setup after signup. The sheet shows Ben as the backup contact, so support does not wait for Maya to return. Ben knows the service, finds the runbook, and gets the issue to the right engineer before it turns into a larger outage.

A simple row can hold enough detail to keep work moving:

That is the real win. The sheet does not need to be perfect. It just needs to answer the first few questions people ask when something breaks, someone joins, or the usual owner is away.

Mistakes that ruin the sheet

A service catalog spreadsheet stops helping the moment people doubt it. Once that happens, they go back to asking in chat, guessing, or paging the wrong person during an incident.

The first problem is messy naming. If one team writes "billing-api," another writes "payments service," and a third writes "invoice backend," you do not have three clear entries. You have one service with three names, or three services that nobody can tell apart. Pick one naming rule early and keep it simple. A pattern like product plus service type is enough if everyone uses it.

Ownership gets muddy fast when teams pack several names into one cell. "Priya, Sam, backend team, support channel" looks helpful, but it does not answer the only question that matters during a problem: who acts first? Give each service one direct owner. Put backup owner, team name, and support contact in separate columns.

Old services cause a different kind of damage. Teams often leave retired tools in the sheet because deleting them feels risky. Then someone sees the old entry, assumes it still runs, and wastes an hour chasing logs or contacts that no longer matter. Keep the history, but mark dead services clearly. Add a status like "retired" or "sunset" and note when the team shut it down.

Review dates matter more than most teams expect. People change roles. Shared inboxes die. Repos move. A support contacts list can go stale in a month if the company is growing. Add a "last reviewed" date and make one person update it. Without that, the sheet turns into office archaeology.

Storage can ruin the whole thing even if the data is fine. If the sheet lives in a forgotten folder, a private drive, or an old export that only one manager opens, the team will stop using it. Put it where people already work. Mention it in onboarding. Use the same file during incidents and service handoffs so nobody wonders which copy is current.

The warning signs show up early. People ask who owns a service that is already in the sheet. Two rows point to the same repo. A service has no review date, no status, and no clear support contact. When that starts happening, fix the structure before adding more rows.

A plain internal service inventory can work well for a long time. It does not need fancy features. It needs clean names, one owner per field, current review dates, and a home that people actually check.

A quick monthly check

A monthly review keeps the sheet useful. Skip it for two or three months, and you get the usual mess: old owners, broken docs, and support contacts who left the team or changed shifts.

This check does not need a meeting. One person can do most of it in 20 to 30 minutes, then flag a few rows for follow-up. That is enough to keep an internal service inventory accurate without turning it into another admin task people ignore.

Pick one day each month and keep the routine the same. Teams are more likely to maintain a service catalog spreadsheet when the review feels small and predictable.

• Remove services nobody uses anymore, or mark them retired if you need the history.
• Replace owners who changed roles, moved teams, or left the company.
• Check support contacts after on-call rotations or team reshuffles.
• Open the main doc and dashboard for each service to confirm they still work.
• Mark any row that needs a fix, then assign a person and a date.

A few of these checks are faster than people think. If the owner field shows an engineer who now works on another product, change it at once. If the support contact points to an old shared inbox, replace it before the next incident. Bad contact data wastes the most time when something breaks.

Broken links are another quiet problem. A dashboard may have moved to a new folder. A runbook may now require different access. If the row says the service has docs, those docs should open without a hunt through chat history.

Use a simple status mark for rows that need work. "Review needed" is enough. You can add a short note like "owner unclear" or "dashboard moved" so the next person knows what is wrong. Do not leave half-correct rows looking complete.

One rule helps a lot: if nobody can name the current user, owner, or support path for a service, the row is not done. Mark it and come back. Guessing creates false confidence, and false confidence is worse than a blank cell.

This monthly pass also gives you a clean way to cut clutter. Old experiments, one-off scripts, and replaced tools tend to stay in the sheet long after the team stopped using them. Remove them or mark them clearly as retired. A shorter sheet is easier to trust.

If you want a lightweight owner for this process, give it to the person who already watches delivery or operations. They do not need to fix every row themselves. They just need to keep the list moving so the next incident does not start with, "Who owns this?"

What to do before you buy a portal

A portal can look neat in a demo, but demos hide a simple problem: many teams do not yet know what belongs in their catalog. That is how they end up paying for a system with dozens of fields nobody updates. A service catalog spreadsheet is the safer first step because it shows what people really maintain.

Start by counting the services you truly need to track. Do not count every repo, script, or one-off job. Count the services people ask about, depend on, or support after hours. For one team, that might be 14 rows. For another, it might be 80. The number matters because a portal makes more sense when the list changes often and many people need the same information.

Before you compare tools, write down a few facts from the sheet:

• how many active services you track
• which columns people update every month
• which columns stay blank or go stale
• which support contacts people actually use
• which manual steps waste time every week

This is more useful than most vendor checklists. If people always fill in owner, docs, repo, and support contacts, those fields matter. If nobody touches cost center, maturity score, or long service descriptions, do not let a portal force them back into your process.

Manual work is another good signal. Maybe your team still asks the same questions in chat: who owns this service, where is the runbook, which database does it use, who handles incidents on Friday night? If people spend 15 to 20 minutes chasing that information several times a week, write that down. A portal should remove those exact chores. If it does not, it is just a more expensive spreadsheet.

Keep the spreadsheet clean even if you decide to buy a tool later. It gives you a starting dataset and makes migration much easier. A messy sheet does not become clean because you imported it into a portal. It just becomes a messy portal.

A small team can stay with a service catalog spreadsheet longer than many people think. If you have a clear owner for each service, current links, and working support contacts, you may not need a portal yet.

If the choice still feels fuzzy, an experienced fractional CTO can help define the catalog, cut extra fields, and decide when the team has actually outgrown the sheet. Oleg Sotnikov at oleg.is does this kind of work with startups and smaller companies, especially when they need clearer technical ownership and cleaner operating processes before buying more tooling.