Building a customer portal for a testing or contract laboratory
How to plan a laboratory customer portal: online sample submission, tracking, results and CoAs, LIMS integration, multi-tenant security and a phased rollout.
For a testing or contract laboratory, a large share of customer communication is administrative. A client emails a spreadsheet of samples, someone at the lab retypes it into the LIMS, the client calls to ask whether the samples arrived, then asks again about turnaround, then asks for a CoA that was already sent to someone who left the company. None of this is difficult, but it adds up, and every retyped line is a chance for a mismatched sample ID.
A laboratory customer portal moves that work into a structured, self-service channel. Done well, it reduces email and phone traffic, improves the quality of incoming sample information and gives clients a clearer view of their work. Done poorly, it becomes another place where data has to be reconciled. This guide covers what to build, how it should relate to the LIMS and how to roll it out without disrupting the lab.
What customers actually want
Lab clients are usually busy people with a narrow set of tasks. The portal should make those tasks fast, not show off everything the LIMS knows.
- Submit requests without email back-and-forth. A guided form for sample submission, with the right fields for the type of testing: sample descriptions, matrices, collection dates and times, sampler names, requested tests, due dates and any hazards. For environmental and food labs, an electronic chain of custody form that the client can print and include with the samples is often the most valued feature.
- Track samples and status. Clear statuses such as submitted, received, in testing, in review and reported, with expected dates where the lab is comfortable sharing them.
- Get results and CoAs. Approved results in a readable table, downloadable certificates of analysis, and the ability to find older reports by project, site, PO number or date range without contacting the lab.
- Reorder easily. Many clients submit the same set of samples and tests every week or month. Copying a previous request or saving a template removes most of the effort.
- Message the lab in context. A question attached to a specific request or sample is far more useful than a general email to a shared inbox.
Notice what is missing: clients rarely want to see raw instrument data, internal worksheets or the lab's workflow details. Keep the customer view simple and focused on their outcomes.
What lab staff need
A portal that serves only clients will create work for the lab. Staff-side features are what make the incoming data usable.
Request review before work starts
Submitted requests should land in a review queue, not go straight into the LIMS as active samples. Sample receiving or customer service staff check that the tests requested make sense for the matrix, that holding times can be met, that the client has an account in good standing and that the information is complete. Only then are samples created and labels printed. The portal should let staff accept, edit with a note, or return a request to the client with questions.
Mapping customer-facing tests to LIMS analyses
Clients think in terms of test names, packages and methods they recognize from regulations or contracts. The LIMS thinks in terms of analyses, analyte lists, methods and specifications. The portal needs a test catalog with customer-friendly names that map to LIMS master data, including packages that expand into several analyses. That mapping should be maintained by the lab and kept in step with LIMS changes, or new methods will appear in the LIMS but not in the portal.
Pricing and quote awareness
Many contract labs work from quotes or customer-specific price lists. The portal does not have to be a billing system, but staff should be able to see whether a request matches an existing quote, and clients may need to reference a quote or PO number. Showing prices to clients is a business decision; some labs prefer to show them, others only reference the quote.
Control over what gets released
Staff need to decide exactly what appears in the portal and when. That includes final results, reports and CoAs, and any preliminary data the lab chooses to share. The release step should be deliberate and recorded.
The integration question
The biggest architectural decision is how the portal relates to the LIMS. There are two broad patterns.
Portal as a front end to the LIMS
The LIMS remains the system of record for samples, tests and results. The portal holds requests until they are accepted, then creates samples in the LIMS, and later reads back status and released results. This is the most common and usually the most sensible pattern for labs that already have a LIMS, since it avoids duplicating sample management. It is also a natural example of extending a LIMS rather than replacing it.
Portal with its own data
The portal stores requests, statuses and published reports in its own database, synchronized with the LIMS on a schedule or by events. This can make sense when the LIMS has limited integration options, when several LIMS instances or sites feed one portal, or when the portal must stay available while the LIMS is down for maintenance. The trade-off is more synchronization logic and a clearer need to define which system owns what.
What to sync and when
Whichever pattern you choose, write down each data flow explicitly:
- Customer organizations, contacts and sites, usually owned by the LIMS or CRM.
- Test catalog and packages, owned by the lab's master data.
- Requests, owned by the portal until accepted, then converted to LIMS samples with a link back to the request.
- Sample status updates, flowing from the LIMS to the portal, either in near real time or at a predictable interval.
- Released results and reports, flowing from the LIMS to the portal only after approval.
Only release approved results
This deserves its own rule. The portal should never be able to display a result that has not passed the lab's review and approval process. If a result is corrected after release, the portal should show the revised version, mark it as revised and keep a record of what was previously published. Treat the CoA as a controlled document: generated from approved data, versioned, and not editable after release.
Security and multi-tenancy
A customer portal is multi-tenant by nature: many client organizations share one system, and each must see only its own data. This is the area where shortcuts cause real harm.
Tenant isolation
Every request, sample, result, document and message should be tied to a customer organization, and every data query should be filtered by the logged-in user's organization on the server. Hiding links in the user interface is not access control. Test isolation explicitly, including direct URLs to documents and API calls with another tenant's IDs.
Roles within a customer organization
Client organizations have their own structure. A typical set of roles includes an administrator who manages users for that organization, submitters who create requests, and viewers who can only see results. Larger clients may need access split by site or project, so a plant manager sees only their plant's samples.
Sign-in and SSO
Strong passwords, multi-factor authentication and sensible session timeouts are a baseline. Larger clients may ask to sign in with their own identity provider through SAML or OpenID Connect, which improves security for them and removes the lab's burden of managing their users. Plan for it even if it is not in the first release.
Audit trail
Record who submitted, changed, accepted or returned each request, who released each result, and who viewed or downloaded reports. If the lab works under ISO/IEC 17025, GLP or GMP expectations, the portal becomes part of how results are communicated, so it should fit the lab's procedures for report issue and amendment. Software supports those requirements, but compliance depends on the lab's quality system, procedures and validation where it applies.
White-labeling and the client experience
The portal represents the lab to its customers, so it should look like the lab: its logo, colors, domain and email sender address. For lab networks or labs that run testing on behalf of partners, white-labeling may need to go further, with different branding per brand or per site from the same system.
Beyond branding, small details shape the experience: confirmation emails that include the request number, notifications when results are released, clear error messages on the submission form, and a layout that works on a phone for clients who check status from the field.
Off-the-shelf, LIMS module or custom
There are three realistic routes, and each fits different situations.
| Option | Best fit | Strengths | Limitations |
|---|---|---|---|
| Off-the-shelf portal product | Labs with standard workflows and a supported LIMS | Faster to start; vendor maintains it | Limited control over forms, workflow and branding; integration may be generic |
| LIMS vendor portal module | Labs already invested in that LIMS and satisfied with its approach | Native access to LIMS data; one vendor relationship | Tied to the LIMS's release cycle and licensing; customization can be constrained; may lag modern web expectations |
| Custom portal | Labs with specific submission forms, multiple LIMS or sites, strong branding needs, or unusual workflows | Fits the lab's process exactly; full control of experience and integration | Requires a capable development partner and ongoing ownership; scope must be managed |
A custom portal does not have to start from nothing. Starting from a working accelerator or a well-understood architecture reduces both cost and risk, and leaves budget for the parts that are actually specific to your lab.
A phased rollout plan
- Start with results and CoA access. Publishing approved reports to clients is the simplest flow (one direction, from approved data) and removes a large share of routine requests to resend documents.
- Add sample tracking. Expose status updates from the LIMS so clients stop calling to ask where their samples are.
- Introduce online sample submission. Build the request form and the staff review queue, starting with one or two cooperative clients and a limited test catalog.
- Expand the catalog and templates. Add packages, reorder templates and electronic chain of custody forms, and refine the mapping to LIMS analyses based on what staff had to correct.
- Add messaging and notifications. Contextual messages on requests and samples, plus email notifications for receipt and release.
- Bring in SSO and advanced roles. Offer identity provider sign-in and site-level access for larger clients once the core is stable.
Each phase should be useful on its own. Run each one with a small group of clients first, collect feedback from both clients and lab staff, and fix the friction before inviting everyone.
Where SpectraLIMS fits
SpectraLIMS builds laboratory customer portals that work alongside an existing LIMS. Our Laboratory Customer Portal accelerator is a working, white-label starting point with testing requests, a test catalog, sample tracking, results, CoA downloads, messaging and a LIMS integration demo. It is not a finished, validated product, but it lets you see and adjust a real portal early instead of designing one from a blank page. If incoming sample information or results distribution is taking more of your staff's time than it should, talk to us about what a first phase could look like.
Frequently asked questions
What is a LIMS client portal?
It is a secure website where a laboratory's customers submit testing requests, track their samples, and view or download approved results and certificates of analysis. The portal is usually connected to the lab's LIMS, so requests become samples and released results flow back without staff re-entering data or sending emails.
Can a customer portal work with our existing LIMS?
Usually, yes. Most portals are built as a front end to the LIMS, exchanging requests, sample status and released results through an API, database views or scheduled file exchange. The main design work is deciding what data is synchronized, how often, and which system owns each record.
How do you make sure customers only see their own results?
Every record in the portal is tied to a customer organization, and every query is filtered by the logged-in user's organization on the server side, not just hidden in the user interface. Roles within each customer organization then control who can submit requests, view results or manage users, and access is recorded in an audit trail.
Should results appear in the portal as soon as they are entered?
No. Results should be published only after they have passed the lab's review and approval process, and preliminary results, if shown at all, should be clearly labeled and controlled by a deliberate release step. If an approved result is later corrected, the portal should show the revised version and keep a record of what was previously released.