Where handoffs between scientists and test engineers break
In most battery labs the requester (a scientist or project engineer) and the people running the cyclers work in different tools. The request arrives by email, the queue lives in a spreadsheet, the sample is dropped off at a bench and the result goes back in a chat thread. Each switch is a place where information gets lost.
- The test profile is described in free text, so the engineer has to ask follow-up questions before starting.
- Nobody knows the real priority, so the queue is ordered by whoever asked last.
- Samples arrive without an ID, with a different name than in the request, or not at all.
- The requester cannot see whether the test has started, is waiting for a channel or has finished.
- Results are sent informally, so it is unclear which version belongs to which sample and which test run.
The workflow in six stages
| Stage | What has to be true to move on |
|---|---|
| 1. Request | The record has requester, project, sample type and number, test profile, target dates and priority. Incomplete requests stay with the requester. |
| 2. Review | A test engineer confirms the profile is feasible (equipment, chamber, channel type) and estimates channel hours and duration. |
| 3. Queue and reservation | The request is placed in the queue by priority and bound to a concrete station and time window, so conflicts are visible before they happen. |
| 4. Sample registration | Each sample gets a unique ID and a label on arrival; receiver, storage location and condition are recorded. |
| 5. Test | The test runs on the reserved station; the sample, the test case and the station are linked, so measured values can be traced back. |
| 6. Result handoff | Results and the report are released to the requester with a status; the sample is returned, stored or disposed of — also recorded. |
The point is not bureaucracy. Each stage ends with a clear condition, so the next person never has to guess.
The minimum a test request needs
Long forms get ignored. Ask only for what the engineer needs to plan and run the test, and make the rest optional.
- Requester, project and cost centre or customer.
- Sample type, quantity and any special handling (state of charge, hazards, shipping).
- Test profile: standard or custom, with the parameters that matter (temperature, rate, cycles or duration).
- Target start and deadline, and a priority with a reason.
- What the requester needs back: raw data, a summary, a formal report.
- Contact for questions during the test.
Sample registration and handoffs
Samples are the weakest link in most workflows, because they are physical and move between people. Treat each transfer as an event, not a convention.
- Give every sample a unique ID that is printed on a label and also appears in the request and in the result.
- Record who received it, where it is stored and what condition it was in on arrival.
- Log every handover: who gave it to whom, where it went and why (to a chamber, to another lab, back to the requester).
- Close the chain explicitly with a return or disposal event, so a sample never just disappears.
- Keep the sample's history readable by the requester, so they do not need to ask.
For accredited labs this chain of custody is often a requirement; for everyone else it answers the daily question "where is sample X right now?"
Running the queue fairly
- 1
Define priority rules
Write down two or three classes (for example urgent, planned, background) and who may assign them. Without it every request is urgent.
- 2
Plan in channel hours
Estimate each request in channel hours, not just in weeks, so the queue reflects real capacity.
- 3
Reserve instead of waiting
Bind a request to a station and window as soon as it is reviewed. Conflicts show up in the calendar, not on the day.
- 4
Make the queue visible to requesters
A read-only view of status removes most status emails.
- 5
Review the queue weekly
Look at waiting time per stage. Long waits at review or at sample arrival are usually process problems, not capacity problems.
What to look for in software
- A project and test-sequence structure that matches how requests are actually organised, not a generic ticket list.
- Specimen (sample) records with unique IDs, a scannable code and a chain-of-custody log.
- Calendar and reservations on test stations, with conflict warnings.
- A status view for requesters and an optional read-only link for customers or partners.
- Test cases with results and approval status, so the handoff is a defined state and not an email.
- Role-based permissions and an audit log, so you can see who changed what and when.
Be sceptical of tools that only track requests as tickets: the queue, the physical sample and the test station then live in three different places again.