“Where is this report?” The client calls for the third time. The sales rep who picks up opens the intake Excel file, then sends a LINE message to the lab supervisor. The supervisor says he needs to check the whiteboard. The whiteboard shows last week's progress. Twenty minutes later, the sales rep calls the client back: “It should be out tomorrow.” It isn't out the next day, because one of the tests has to be redone, and nobody told sales.
I'm Johnny Yang, founder of Brightstream Technology in Taiwan. I've led teams building systems for seven years, across more than 252 projects in over 32 industries. When owners of testing and laboratory companies come to me, they say almost the same thing: “Our testing quality is fine. The problem is that everything requires asking someone.”
The conclusion first: a LIMS (Laboratory Information Management System) does not manage instruments. It manages the complete record of a sample, from intake, assignment, testing, review, and report sign-off through to invoicing. Where testing companies actually leak money is usually not the testing itself but the handoffs: nobody can find out the status, nobody knows a test is being redone, nobody can find the previous version of a revised report, completed tests never get invoiced, and staff work overtime filling in records before an audit. Before implementation, the first thing to settle is not which system to buy. It is three things: how many states a sample has and who changes them at what point; whether there is only one master list of your tests and prices; and who can sign reports and how revisions are recorded. Get these three clear and either a packaged or a custom-built system will work. Leave them unclear and even the most expensive system just moves the whiteboard into a computer.
What is a LIMS? In terms an owner can use
LIMS stands for Laboratory Information Management System. The name sounds technical, but what it does is simple: it gives every sample in your company its own ledger.
That ledger records who sent it, when it arrived, which tests it needs, who it was assigned to, what step it's at, what the results are, who reviewed it, who signed it off, which version of the report went out, and whether it has been invoiced. Intake, the lab, QA, sales, and accounting all look at the same ledger.
It is not the same as instrument software. Instrument software manages how one machine measures and stores raw data. A LIMS manages whose hands a sample passes through inside your company. It is not ERP either. ERP centers on buying, selling, and inventory. A LIMS centers on samples, tests, and reports. Many testing companies need both, but the order and the boundary between them have to be clear.
If you run a QC lab in food, chemicals, or manufacturing, the concept is the same. The client is just your own production line. I wrote about tracing batch numbers back to raw materials in Food manufacturing traceability: how batch tracing works. That post focuses on production. This one focuses on how the lab itself runs.
Where do testing companies usually leak money?
Forget systems for a moment. Talk about money. The table below lists the most common leaks at testing and laboratory companies. Count how many apply to you.
| Leak | What it looks like on the floor | What it costs the owner | What a LIMS should handle |
|---|---|---|---|
| Nobody knows the status | Sales asks the supervisor, the supervisor checks the whiteboard, the whiteboard is out of date | Several calls a day, clients think you're unprofessional | Real-time sample status that sales and clients can check themselves |
| Nobody knows about retests | A test needs redoing and only the person running it knows | Missed deadlines, clients told at the last minute | Retests logged with a reason, relevant people notified automatically |
| Report revisions are a mess | Client wants a different letterhead, the fix is saved as “Report_rev2” | Wrong versions sent out, no clear answer during audits | Every version kept: who changed what, and why |
| Finished work never invoiced | Added tests only written in the notes on the work order | Work done for free, month-end reconciliation doesn't match | Completed tests go straight onto the invoicing list |
| Filling in records before audits | The whole company works overtime the week before an accreditation audit | Overtime pay, managers' time, risk | Records captured at the moment the work is done |
These five leaks have one thing in common: none of them is a technical problem. They are handoff problems. Between intake and the final report, a sample passes through at least four or five people. Every handoff is another chance for information to fall on the floor.
With a small team, the supervisor's memory and a whiteboard can hold it together. Once sample volume grows, clients multiply, and test combinations get complicated, memory stops being enough. Then the owner notices that the thing they say most every day is “go ask.”
“Just buy an off-the-shelf LIMS” is half right
Many owners' first thought is: there are ready-made LIMS products on the market. Buy one and use it. Why go custom-built?
That instinct makes sense. A packaged LIMS is built from the workflows of many labs, and the main line of intake, assignment, result entry, review, and sign-off is roughly the same everywhere. If your lab's workflow is standard, your client types are simple, and your report formats are fixed, a packaged system really is the fastest option.
But the real problem I see on site is usually not whether the system has enough features. It's that the company hasn't defined its own things yet. The three most common situations:
- There are several master lists of tests. Sales quotes from one Excel file, the lab assigns from another, and accounting invoices from a third. The same test has different names and different prices in all three. Whichever LIMS you buy, step one will get stuck right here.
- There's no agreement on sample states. Does “intake complete” mean the sample arrived, or that the data has been entered? Does “done” mean the data is out, or that it has been reviewed? Everyone has a different definition in their head, so the states in the system mean nothing.
- The quotation logic lives in the sales rep's head. Bundle prices, rush surcharges, discounts for long-time clients, discounts when certain tests are run together. If these rules aren't written down, the system can't calculate them either.
So the real dividing line isn't packaged versus custom-built. It's whether you can state your own rules clearly. If you can, go see which system can hold them. If you can't, whatever you buy will get stuck. It's the same point I made in The cost of messy part numbers: how to clean up product master data. In manufacturing the master data is part numbers. In a testing company it's the test list.
Five things to settle before implementing a LIMS
I recommend settling these five things in internal meetings before you contact any vendor. None of them requires technical knowledge. They require the owner and managers to make the call together.
1. How many states a sample goes through, and who changes them
Write the life of a sample, from arrival to closure, as five to eight states. For example: awaiting intake, received, assigned, in testing, awaiting review, awaiting sign-off, report issued, invoiced. Next to each state, write who moves it to the next step.
This table looks simple, but it is the skeleton of the whole system. Define the states too broadly and the owner can't see where things are stuck. Define them too finely and the floor staff feel they have to click in the system for every little thing, so eventually they stop clicking.
2. Tests and prices exist in one place only
Organize every test into one master list: test name, method, expected turnaround in days, standard price, and which other tests it can be combined with. Sales quotations, lab assignments, and accounting invoices all pull from this one list.
This takes the most time, and it's the most worth it. In my experience, on the day the master list is finished, a lot of internal arguments disappear on their own, because everyone is finally talking about the same thing.
3. Who signs reports, and how revisions are recorded
Who has authority to review, who has authority to sign off, and who their deputies are. When a client asks for a report change: what changed, who approved it, how the old version is kept. If you hold accreditation, define this against the standards and audit requirements that apply to you, not from memory.
4. Whether instrument data should flow into the system automatically
This is the part vendors make sound the best, and the part where you should be most careful. Automatic data transfer from instruments sounds like it saves effort, but every instrument has a different format. Each one you connect is a development cost and an ongoing maintenance responsibility.
My advice is not to connect everything up front. Pick one or two instruments with the highest data volume, where manual transcription is most error-prone. Use file import or manual entry for the rest. Once the system is stable, decide whether the next instrument is worth connecting.
5. Whether clients can check status and download reports themselves
If your clients call every day asking about status, letting them check it themselves is the fastest win. In Taiwan, the interface clients are most used to is LINE: enter the order number and see the current status, then get a notification and a download link once the report is signed off. Sales gets fewer calls, and clients actually feel better about you.
Packaged LIMS, custom-built LIMS, or ERP plus a module: how do you choose?
Only after those five things are settled is it time to pick a system. There are generally three paths, each suited to a different kind of company.
A packaged LIMS suits labs with standard workflows and simple client types. The upside is fast launch and complete features. Watch out for three areas: quotation rules, report formats, and client channels. These often need extra custom work or simply can't be done. Before signing, give the vendor your quotation rules and two or three of your most complicated report samples, and ask them to demonstrate on the spot how they'd handle them.
A custom-built LIMS suits companies whose workflows have their own particulars, or that need sales, invoicing, and client inquiries connected into one line. The upside is a close fit to how the floor actually works. The catch is that the spec must be written as a list on paper first, or the scope will keep growing. For how to write the spec, see How to write an ERP requirements spec. The same method applies.
ERP plus a testing module suits companies where testing is just one department and the main business is manufacturing or trading. The upside is one system for everything. The catch is that ERP is designed around documents and inventory, and its handling of sample states and report versions is usually not detailed enough.
Which path you take comes back to the old question: build or buy? I wrote out the full decision framework in Build or buy? A decision framework for small and mid-sized businesses. I'll add just one thing here: if the custom items you're negotiating with a packaged vendor have grown to the point where they need their own spec document, that usually means custom-built is the more honest choice.
Whichever path you choose, when a vendor comes to demo, bring three things to test them with: your most complicated order (many tests, a rush item, a combination discount), a report that has been revised, and a scenario where a test has to be redone halfway through. Ask them to run it in the system from intake all the way to invoicing. Watch only three things: whether the quotation comes out right, whether sales gets notified about the retest, and whether you can find the previous version after a revision. If it passes these three, the other features can be added over time. If it doesn't, a polished slide deck won't help.
How do you estimate budget, timeline, and post-launch costs?
What owners most want to know is how much this will cost and what they'll still be paying afterward. I'll explain using how Brightstream works, to give you a baseline for comparison.
Brightstream's system implementation starts at NT$300,000, quoted by spec. We first write the scope as a written feature list, then quote a fixed price. No signing first and adding charges later. Payment is collected in stages. After launch, maintenance starts at NT$20,000 per month, quoted by system size. During the maintenance period, adjustments to screens, fields, and report layouts within the written feature list are not charged extra, and critical issues are fixed within 24 hours of being reported.
The key to the timeline is usually not the coding. It's how fast those five things get settled. The cleaner your test master list, the faster everything after it goes. How much old data needs to move also affects the timeline. Historical reports usually don't all need to be converted into the new system; keeping them as searchable files is enough. For details, see Can your old system's data be migrated?.
As for whether it's worth it, there's a simple way to calculate. Say you get 20 client calls a day asking about status, and each one, including the internal asking around, takes 10 minutes. That's over three hours a day. Over twenty-some working days a month, that's more than 70 hours of staff time, mostly from sales reps and lab supervisors. Add the invoices for added tests you might miss each month and the cost of handling wrong report versions, and you can estimate what your leaks are worth in a year. Then compare that against the total cost of the system.
Frequently asked questions
What's the difference between a LIMS and an ERP?
ERP centers on buying, selling, inventory, and accounting. A LIMS centers on samples, tests, and reports. A testing company's main operating unit is the sample, not a product, so it usually needs a LIMS. If the company also manufactures or trades, draw a clear boundary between the two, then decide which one is the main system.
Does a small lab need a LIMS?
It's not about size. It's about the number of handoffs and the volume of inquiries. If sample volume is low and only one or two people touch a sample between intake and report, Excel plus clear forms may be enough. When you start getting asked about status every day, when retests happen without anyone knowing, or when report versions get mixed up, that's when to evaluate seriously.
How long does a LIMS implementation take?
The timeline depends mostly on how fast the test master list and sample states get defined, not on the system itself. Companies with clean master data and agreed workflows move much faster than companies still arguing about the process. Launch the main line from intake to report first. Do instrument integration and advanced reporting in later phases.
Does instrument data have to be imported into the LIMS automatically?
No. Every instrument you connect is a development cost plus ongoing maintenance. Start with the one or two that have the highest data volume and the most error-prone manual transcription. Use file import or manual entry for the rest, and once the system is stable, evaluate each remaining instrument on whether it's worth connecting.
What a LIMS buys you is “a ledger for every sample”
In the end, a LIMS is not software that makes your lab look more advanced. It's what lets the owner stop saying “go ask” every day. Settle sample states, the test master list, and sign-off and revisions first. Then the system works for you, instead of becoming one more place to fill in.
If you're evaluating whether to implement one, or you've already bought one that nobody uses, start with How ERP implementation works to see how we go step by step from mapping your workflow to launch.
