Shared calendars and spreadsheets work fine for small teams with a handful of instruments, but once you get any bigger than that things start to get difficult. Here's our guide to making the switch.
If you work in an R&D lab, chances are each instrument has its own shared Outlook calendar called something like "Lab2-HPLC3." To book an instrument, you need to know that a shared calendar exists, add it to your Outlook, then create an event. To check availability, you need to open that calendar and take a look, while also hoping that everyone else is doing the same. There are eleven other instrument calendars you should also have added. You have three of them.
Last Tuesday, two scientists booked the same HPLC for 2pm. One booked from their phone; the other from Outlook desktop. Neither saw the conflict until one of them walked up to the instrument and found it occupied. And we all know who won that argument (it was the person with greater seniority or political clout).
If you're reading this, chances are pretty good you already know these shared calendars are a problem. This article is not here to convince you of that but rather to help you figure out whether you have actually hit the point where switching is worth the disruption, and what the switch looks like in practice.
TL;DR:
Before talking about what breaks, it's worth saying what works:
The common setups are variations on a theme. Shared Outlook calendars, one per instrument, sometimes with a sticky note on the instrument itself: "Please subscribe to [email protected]."
For some labs, an improvised system like this works well enough. If there are plenty of instruments and only a handful of people using them, why bother with anything more?
There are others, like colour-coded Google Calendars, or a shared Google Sheet or Excel file with a tab per instrument. We've spoken to some teams where paper sign-up sheets taped onto instruments(!) are still very much a thing.
There's another one that shows up more often than anyone admits: a bespoke script or app built by a grad student, a postdoc, or someone in IT who had spare capacity three years ago. That last one is its own archetype. It works until the person who built it leaves.
But, if it's working, great. Chances are it won't for very long, though.
As we've just discussed, not every lab needs to move off shared calendars. A small team with abundant instruments and no external reporting requirements is probably fine, and we're not going to make the argument that you need to buy Calira. Our platform earns its keep once demand outstrips supply, multiple teams share the same kit, or someone above lab ops starts asking questions the calendar cannot answer.
(However: if you manage a small team with abundant equipment and no reporting requirements, you might have more equipment than you need and could probably improve your capital efficiency if you have a tool like Calira operating org-wide.)
Here are seven signals that you might have crossed that line.
Your lab has dozens of instruments across multiple groups, each one with its own shared calendar. New starters don't know which calendars to subscribe to, or that they exist at all: people miss out on using instruments because the calendar was never discoverable in the first place. The system only works for people who have been around long enough to know the informal setup.
Once a lab passes roughly thirty to forty people sharing instruments, the coordination cost of a manual system outstrips the effort of migrating to a dedicated one. With more teams, there are more moving parts and more booking collisions, with far more time spent resolving them.
Not the routine "oops, I'll move my slot" kind, but the kind where a sample is ruined, a deadline is missed, or two teams end up in a genuinely adversarial conflict over a critical instrument — the kind of booking conflicts that damage working relationships. This is where we see real damage done to research output, but it tends to be chalked up to this just being a way of life in R&D labs.
Could be any number of reasons: the PhD candidate burned out and went into industry, the IT contractor got fired, the lab manager who maintained the master calendar or spreadsheet moved to another company, or the vibe coder ran out of tokens and has no idea what the code actually means. On top of that, nobody else fully understands the system and nobody wants to be the one to rebuild it.
This really could be anything: utilisation rates per instrument, hard data to justify a new purchase, cost-recovery reports for shared equipment. The shared calendar captures booking slots but not actual usage, not maintenance windows, not training records, not which project codes are attached to which sessions. When the CFO asks "how much are we actually using that mass spec we bought last year?", the calendar has no answer. Times might be good in your company right now, but if the tide ever turns (which it often does)...
The moment equipment gets shared across locations, a set of shared calendars per lab does not scale. To be able to make sensible decisions about equipment allocation you need visibility across sites, and that requires a system, not a collection of calendars.
If you or a lab manager spends hours every week manually compiling usage data from multiple calendars and spreadsheets, that is a recurring cost the system is hiding from you (and time you're not spending doing something you'd probably prefer to be doing).
If three or more of these apply, you have outgrown the shared calendar. If none apply, keep what you have.
The operational failures (double-bookings, discovery problems, accidental overwrites) are obvious but the deeper problems are less visible.
An important note: a shared calendar captures intent. Somebody said they would use the confocal from 2pm to 4pm on Thursday. Did they? Did they show up at 2:15 and leave at 3:10? Did they show up at all? The calendar does not know, it just shows you a grid of claimed time, and you mistake it for a picture of actual usage.
This is the difference between a booking log and a booking system. A log records what people said they would do, whereas a system changes what people actually do; it changes their behaviour. It enforces training prerequisites, prevents unqualified users from booking instruments they are not certified on, creates buffer times between sessions, sends reminders, and captures adherence data alongside intent data.
The consequences compound at scale. Think of it in four levels: equipment, lab, site, organisation. The shared calendar operates at level one. It tells you what is happening with one instrument in one lab. The decisions that matter (should we buy another instrument? can we consolidate across sites? are we meeting utilisation targets?) happen at levels three and four. The shared calendar has nothing to contribute there.
When labs start looking for a replacement, they often conflate several categories of software that do different things. It helps to be specific.
These handle who can use what, when, with what rules and permissions; a coordination layer, if you like. This is where Calira sits.
LIMS (Laboratory Information Management Systems) handle sample tracking, experimental data, and regulatory compliance. ELNs (Electronic Lab Notebooks) handle experiment records and protocol documentation. Many LIMS and ELNs have some kind of built-in "booking" functionality, but because these are not the main focus of these tools they're often extremely basic, vestigial add-ons there to check a box in an RFP.
ALMs (Asset Lifecycle Management systems) and CMMS (Computerised Maintenance Management Systems) handle maintenance scheduling and asset lifecycles. Just like with LIMS and ELNs, booking tools that get built in here are basic at best. But unlike LIMS and ELNs, lab users don't use these tools all day anyway.
These are different software categories, not competing products. ELNs and LIMS rarely solve instrument scheduling or maintenance. Many biotechs run Benchling for their experimental data and still manage equipment booking on a shared calendar or spreadsheet, because Benchling is not trying to solve that problem.
The practical implication: you don't need to replace your LIMS or ELN to fix your booking problem. The booking layer sits alongside those systems, not instead of them.
Migration from a shared calendar to a dedicated booking platform is less dramatic than most people expect. But the parts that are hard are not the parts you would guess.
Instrument list, users, existing booking rules (even informal ones), any forms or reports you currently use. If you have booking data in a spreadsheet or calendar, export it. Most modern platforms accept CSV uploads for equipment records and user lists.
Ironically, this is the single most important integration. If your team lives in Outlook or Google Calendar, then notifications that pop up on their phones to remind them of their bookings are super important. The booking platform needs to sync with those calendars because, if it doesn't, adoption can struggle.
This could be any number of things:
These rules probably exist informally in your lab already; formalising them in the system is what turns a booking log into something that actually changes behaviour.
Don't roll something out across the entire organisation on day one. Instead, start with one site or building, learn what works, and adjust the rules before you expand.
A champion is usually someone in the lab who sees the value on the ground and will advocate to peers. They don't necessarily need to be a lab manager, but they do need to be someone the team trusts. A sponsor is someone with a greater level of seniority who is behind the project but isn't involved in the day to day, and they should have some ability to "mandate" usage.
Harder: change management. The technical setup is actually the easy part, whereas getting people to actually use the system can be harder. The person who built the old tool will defend it. The scientist who liked the flexibility of an unregulated shared calendar will resist rules. "Cultural issues took considerable time and attention, because, if not managed well, would impede adoption by users." That is from a peer-reviewed study on core facility change management, not a vendor blog.
Harder: billing edge cases. If your lab runs cost-recovery or recharge billing (i.e. in academia), the booking rules get more complex. Different rates for internal vs external users, per-group pricing tiers, grant and project code tracking. This is solvable, but it requires thought up front.
Easier: initial setup. Modern SaaS platforms are not the multi-month IT projects they used to be. Bulk CSV uploads for equipment, self-service configuration for booking rules, SSO integration via SAML. The "we need six months of IT support" fear is usually unfounded.
Easier: the death of the old system. Teams that have defended the shared calendar for years tend to abandon it quickly once a working alternative exists. The defence collapses faster than the build-up would suggest. Relief, not regret, is the common reaction.
The shared calendar is not the villain. It did its job when the lab was smaller, the team was smaller, and there just weren't as many instruments. The problem is structural: manual systems do not change how people share equipment, they just record intent and hope for the best.
The real shift happens when you move to a system that doesn't require someone to maintain it because it maintains itself and produces the data your lab needs to make better decisions about equipment, people, and capital.
If you want the full strategic case for why equipment booking matters at the organisational level, we have written about the scheduling blind spot most R&D teams miss. If you want to see what a dedicated equipment booking platform looks like in practice, that is where to start.
