Why the Environment Booking Spreadsheet Fails (and What to Use Instead)

Somewhere in your company there's a spreadsheet called something like "Env bookings" or "Who has staging". It has columns for environment, name, from, to, and notes. The top rows are tidy. The bottom rows are a mix of "Sam – until done", strikethroughs, and a cell that just says "ASK FIRST".

It wasn't a bad idea. A spreadsheet is free, everyone can open it, and it took five minutes to set up. The problem is that it's a record of what people said they would do, and it has no way to stay in sync with what they're actually doing. This post goes through why it fails, what a replacement has to do, and how to move off it.

Why the spreadsheet fails

It has no expiry

A row saying "Alex, staging, until Thursday" is still there on Friday, and the following Friday. Nothing clears it. After a few weeks, people learn the sheet is full of stale rows, so they stop trusting any row. Once that happens, every booking turns into a message: "is this still yours?"

Nobody is told anything

When Alex finishes early, nothing tells the person who wanted staging next. When someone books over an existing row, nothing tells the person whose row it was. The sheet only gets read when someone thinks to open it.

It's not where the work happens

Engineers decide to use staging while they're in a terminal or a chat thread. Opening a browser tab, finding the sheet, finding the right row and typing in it is enough friction that people skip it "just this once". Then the sheet is wrong.

Conflicts are resolved by whoever edits last

Two people can type into the same row at the same time. There's no concept of "this is held; ask the holder". There's just the cell's current value.

Automation can't use it

Your CI pipeline can't sensibly check a spreadsheet before deploying. In principle it could call a spreadsheet API and parse free-text dates. In practice nobody does, so CI ignores the bookings entirely, and the sheet only governs the people who remember it.

It becomes a second job for someone

Usually one person, often a QA lead or engineering manager, ends up policing the sheet: chasing stale rows, settling disputes, reminding people. That's a real cost even if nobody writes it down.

What a replacement needs

Turn each failure around and you have the requirements:

Spreadsheet failure	Replacement needs
No expiry	Every hold has an end time and clears itself
Nobody is told	Waiting people are notified on release; holders are asked before takeover
Not where work happens	Taking and releasing is one action in the tool people already have open
Last edit wins	A held resource can't be taken without the holder's agreement
CI can't use it	An API that pipelines can call
Needs a policeman	Defaults, expiry and notifications do the policing

The options

There are four realistic replacements, and they suit different situations.

A shared calendar. Good when bookings are planned days ahead, such as hardware lab slots or meeting rooms. Poor for "I need staging for the next hour", because creating an event is slower than the task. No API-friendly way for CI to respect it.

Slack Workflow Builder. You can build a form that posts a booking message and writes a row somewhere. Slack's help centre (2026) says Workflow Builder is available on paid subscriptions. It removes some friction, but the underlying record is still a list without expiry or handoffs, unless you build those yourself. We look at how far you can take it in Slack Workflow Builder for resource booking.

CI-native locks. GitHub Actions concurrency groups, GitLab resource_group, Jenkins Lockable Resources. Excellent for stopping overlapping pipeline runs, but they don't know people exist. They replace the sheet only if people never touch the environment directly.

A chat-based reservation bot. Lock and release from chat, holds expire, waiting people are notified, and there's an API for CI. This is the closest match to the requirements table, and it's what we built Lockit to be.

If you also need long-range planning, approvals and release calendars, that's a different category: environment management platforms. We compare all of these in best tools to reserve shared environments and resources in 2026.

Replacing the sheet with Lockit

Lockit runs in Slack, Discord and Microsoft Teams. Here is how each requirement maps to it.

• Expiry. Every lock has a duration: the one you pick, or the resource's default, or the workspace default (48 hours if nothing is set). Set per-resource defaults that match real use.
• Notifications. If a resource is locked, "Alert when released" pings you when it's free. "Ask for takeover" sends the holder Approve / Reject Request buttons.
• Where work happens. @Lockit lock staging and @Lockit release staging in Slack. /lockit lock resource:staging duration:2 hours on Discord. @Lockit lock staging 2 hours on Teams.
• One view. @Lockit list shows every resource and who holds it. The App Home tab shows your own locks.
• CI. On paid plans, the REST API lets pipelines lock and release the same resources.

Migrating off the spreadsheet

The migration is small, but do it in a day, not gradually. Two systems running in parallel is worse than either.

1. Clean the resource list

Go through the sheet and list the distinct things being booked. You'll usually find duplicates ("staging", "Staging env", "stg") and things nobody has booked in months. Agree on one name per resource. Short, lowercase and hyphenated is easiest to type: staging, staging-db, uat, perf-env.

2. Decide default durations

For each resource, pick a default that matches typical use. Look at the sheet: if most staging bookings were "afternoon", 4 hours is about right.

3. Create the resources

For a handful, @Lockit new in chat is quickest; it asks for a name, a description and an optional channel for updates. For more, the API is faster. Put the cleaned list in a CSV:

name,description,default_hours
staging,Main staging cluster (eu-west-1),2
staging-db,Staging Postgres. Lock before migrations or resets,1
uat,Customer UAT environment. Coordinate with CS,24
perf-env,Load testing environment,4

Then create each resource and set its default duration:

#!/usr/bin/env bash
set -euo pipefail
API=https://api.lockitbot.com/api/locky
ME=you@yourcompany.com   # must be a member of your Slack workspace

tail -n +2 resources.csv | while IFS=, read -r name desc hours; do
  curl -sS -X POST -H "X-API-KEY: $LOCKIT_API_KEY" \
    -H "Content-Type: application/json" \
    -d "$(jq -n --arg n "$name" --arg d "$desc" --arg u "$ME" \
          '{name:$n, description:$d, userEmail:$u}')" \
    "$API/resources"
  echo
  curl -sS -X POST -H "X-API-KEY: $LOCKIT_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"defaultLockHours\": $hours}" \
    "$API/resources/$name/default-duration"
  echo
done

Then set the workspace fallback, so anything without its own default doesn't sit at 48 hours:

curl -sS -X POST -H "X-API-KEY: $LOCKIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"defaultLockHours": 4}' \
  "$API/config/default-duration"

The API needs a paid plan and a key from the App Home tab. The free plan's 2 resources can be created from chat.

4. Carry over current holds

For anyone who genuinely has an environment right now, lock it for them, or ask them to run @Lockit lock <name> themselves. Don't carry over future bookings; tell people to lock when they start.

5. Retire the sheet visibly

Rename it "ARCHIVED – use @Lockit", make it read-only, and post a short message in the team channel with the three commands people need: list, lock, release. Pin it.

6. Point CI at it

If pipelines deploy to any of these resources, add a lock step before the deploy and a release step that always runs. How to lock a staging environment from your CI/CD pipeline has working examples.

FAQ

Is a spreadsheet ever good enough?

For a very small team with one resource and little contention, yes. It starts failing when holds outlive their rows, when people stop checking it, or when CI needs to respect it.

What about future bookings, like "staging next Tuesday"?

Lockit locks start when you take them; it isn't a calendar. If you genuinely plan environment use days ahead, a shared calendar or an environment management tool fits better. Most teams find that very few bookings actually need to be in advance once holds are short and handoffs are easy.

How do we get people to actually use the new tool?

Make it the only option. Archive the sheet on the same day, pin the three commands, and have CI respect the locks. When the pipeline waits for a lock, people quickly learn to take one.

Can we keep the spreadsheet for inventory?

Yes. A spreadsheet is fine for things that rarely change, like a list of environments with owners and URLs. It's bad at tracking who is using something right now, which changes many times a day.