When Your Lab Spreadsheet Starts Acting Like Custom Software

TLDR

• Sample accessioning is the process of receiving, labeling, logging, and tracking specimens with unique accession numbers.
• Effective accessioning improves sample traceability, reduces identification errors, and helps labs improve turnaround times (TAT).
• Automated accessioning systems support compliance, audit readiness, and more efficient laboratory workflows.
• Scispot streamlines sample accessioning with barcode tracking, real-time monitoring, system integrations, and automated audit trails.

Your lab probably has a spreadsheet that is doing far more than a spreadsheet should.

It may pull together files from outside partners. It may map sample IDs across systems, standardize units, flag unusual results, track reruns, and shape data into the format needed for a final report.

Someone on the team likely knows exactly how it works. They know which column to trust, which exception needs a closer look, and what must happen before the data can move downstream.

That spreadsheet may be indispensable. It may also be a sign that your lab has built custom software without meaning to.

Why spreadsheets become part of the lab stack

For decades, most lab software has been designed around workflows common enough to support many organizations.

That model makes sense. A product built for thousands of labs needs repeatable patterns, consistent data structures, and features that apply broadly. But lab work is rarely identical across organizations.

A team may work with several external research partners. Each may send data in a different format. One may provide Excel files. Another may send CSVs. Sample identifiers may not align. Units may differ. Some results may be reruns. Others may need review based on rules that only the internal team understands.

Those gaps do not stop the work. The lab creates a workaround.

Often, that workaround is a spreadsheet.

At first, it may be simple: a few lookup formulas, a set of tabs for each study, and manual checks before reporting. Over time, the spreadsheet picks up more responsibility. It gains new columns, validation rules, mapping tables, notes, and exceptions. It becomes the place where the real workflow lives.

The spreadsheet is no longer just a file. It has become an informal application.

What the “spreadsheet owner” actually manages

In many labs, one person becomes the expert on a critical spreadsheet-driven process. That person may be an operations lead, scientist, data analyst, project manager, or someone who learned the process because they were closest to the work.

Their spreadsheet may quietly manage tasks such as:

• Matching sample IDs across incoming files and internal records
• Normalizing units and result formats
• Separating valid results from data that needs review
• Tracking reruns and repeat analyses
• Applying study-specific business rules
• Maintaining internal notes on exceptions
• Preparing a final dataset or report for downstream use
• Updating the workflow when a new study, partner, or data format appears

The value is real. The risk is that the logic is often hard to see, hard to maintain, and difficult to transfer.

When the person who owns the spreadsheet is unavailable, other people may struggle to understand which steps are required and why. The lab may still have the data, but not a clear system of record for the decisions made around that data.

That is where a spreadsheet-based workflow can become fragile.

The problem is not that spreadsheets are bad

Spreadsheets are useful. They are flexible, familiar, and fast to set up.

They are often the right tool for early exploration, one-off analysis, simple tracking, and quick data review. The problem starts when a spreadsheet becomes responsible for a recurring operational workflow that affects sample lineage, reporting, handoffs, or decisions across teams.

A spreadsheet becomes harder to manage when it must account for:

• Multiple sources of incoming data
• Different naming conventions and file structures
• Rules that change by project or study
• Exceptions that require context
• Repeatable review and approval steps
• Access controls for different team members
• A history of what changed, when, and why
• Connections to other systems used by the lab

At that point, the work is no longer just data entry or analysis. It is software behavior.

The lab has a workflow with inputs, rules, permissions, state changes, exceptions, and outputs. The fact that it lives in a spreadsheet does not make it less important. It only makes the underlying logic less visible and harder to manage at scale.

Why generic software does not always fit

Labs often adapt to software because the software was not designed around their exact workflow.

A standard system may handle a broad process well but leave gaps around a specific study type, data handoff, partner format, review process, or reporting requirement. The team then adjusts its work to fit the system, or builds a separate process around it.

This is how disconnected operational layers appear.

A lab may use one system for records, another for files, another for project tracking, and spreadsheets to fill in what does not fit cleanly anywhere else. Each tool may have a clear purpose. The challenge is that the workflow spans all of them.

The result can be a process that depends on people remembering the connections:

• Which sample record maps to which external identifier
• Which file is the current version
• Which result is ready for use
• Which exception has been resolved
• Which team member needs to review the next step
• Which data should move into the final report

This does not mean the team is disorganized. In many cases, it means the team has developed a practical process to keep work moving despite the limits of its tools.

But workarounds have limits. Every new partner, assay, study, or reporting need can add more rules to the spreadsheet. The process becomes harder to change without creating new uncertainty.

AI can build software, but it needs lab context

AI has changed the conversation around custom software.

In the past, a workflow unique to one lab might not have been practical to turn into a dedicated product. The cost and effort of building, maintaining, and changing software could outweigh the value for a narrow use case.

AI can help reduce some of that effort. It can assist with writing code, creating interfaces, and translating workflow requirements into application logic.

But writing code is only one part of the problem.

AI does not automatically understand what a sample represents in your lab. It does not know how records connect across a workflow. It does not know who should be able to review, edit, approve, or release data. It does not know the history behind an exception, a rerun, or a decision unless that context exists in a structured and connected form.

For AI to support lab operations responsibly, it needs more than a prompt and a file upload. It needs context.

That context includes:

• The data the lab works with
• The relationships between samples, studies, results, and records
• The workflows that guide the work
• The rules and exceptions used by the team
• The permissions that determine who can do what
• The history of actions and decisions across the process

Without that foundation, AI can generate an application that looks useful but does not reflect how the lab actually operates.

The Digital Brain of the lab

Scispot has spent years building what it calls the Digital Brain of the lab.

The idea is straightforward: create a connected foundation that captures the operational context behind scientific work.

A lab’s data is not useful only because it exists. Its value also depends on the relationships around it. A sample has a history. A result may relate to a specific run, protocol, study, instrument, partner file, review step, or downstream analysis. A workflow may include rules that determine what happens next.

The Digital Brain is designed to bring that context together.

It connects the information that helps a lab understand its own operations:

• Data and records
• Workflows and process steps
• Rules and exceptions
• User roles and permissions
• The history behind the work

This kind of connected operating layer gives teams a clearer view of how work moves through the lab. It can also create the context needed to build more useful software around real workflows, rather than forcing the lab to reshape its process around a generic product.

Introducing Scispot Jazz

Scispot Jazz builds on that connected foundation.

Jazz is intended to help Scispot work with labs to turn specific operational workflows into purpose-built applications. The goal is not to replace every tool a lab uses or to treat every workflow as identical. The goal is to support the workflows that have become too important, too complex, or too dependent on spreadsheets to manage informally.

Consider the common example of incoming data from several outside research partners.

A purpose-built workflow application could be designed around the steps the lab already follows:

• Receive files in different formats
• Match incoming sample IDs to internal records
• Apply the lab’s data mapping rules
• Identify reruns or records that need review
• Route exceptions to the right person
• Preserve the history of decisions
• Prepare validated data for reporting or downstream work

The exact workflow will differ by lab. That is the point.

A lab should not have to choose between a rigid, one-size-fits-all process and an increasingly complicated spreadsheet. With the right data foundation, software can be shaped around the work itself.

And when that workflow changes, the application can change with it.

Software should follow the work

For a long time, labs have adapted to the limits of the systems available to them.

That adaptation often looks like new spreadsheet tabs, manual checks, separate trackers, and knowledge held by a small number of people. These workarounds can keep a lab moving. They can also make it harder to see the full process, maintain consistency, and change the workflow as the organization grows.

The shift is toward software that can adapt to the company.

That requires more than a configurable interface. It requires a connected understanding of the lab’s data, workflows, rules, and history. It also requires a way to translate that understanding into applications that support the team’s actual work.

That is the idea behind Scispot Jazz: one Digital Brain, with purpose-built applications for the way your lab operates.

If your most important spreadsheet feels less like a spreadsheet and more like the system holding a key workflow together, it may be time to treat that workflow as the software it has already become.