Configure dozens of predefined tests (touch, Face ID, battery, cameras, speakers, Wi-Fi, motherboard and more) and custom tests: they appear as a checklist with an OK/KO outcome both at intake and before delivery.
From Company > Device tests you can enable or disable a wide catalog of predefined tests and create custom tests tailored to your lab. These tests automatically appear as a checklist on the device testing card, both when the repair is accepted and before it is returned to the customer, with an OK or KO outcome marked for each item: the foundation of standardized, traceable testing for every smartphone and PC repair shop.
Why it matters for a repair shop
One of the most frequent problems in a repair lab is a post-delivery dispute: the customer comes back claiming a fault (a camera that won't focus, a volume button that doesn't respond) was caused by the repair technician's work, when it may already have been present before. A structured testing checklist, run both at intake and before delivery, lets you objectively document the device's functional state before and after the smartphone repair or PC repair, protecting both the customer and the repair shop from misunderstandings. It is also an internal quality control tool: a good pre-delivery test drastically reduces returns for undetected malfunctions.
In practice
The Device tests section, under Company, lists a wide catalog of predefined tests designed specifically for smartphones and electronic devices: touch screen, Face ID, battery, charging dock, back cover, frame, front glass, liquid damage detector, housing, LCD display, power button, proximity sensor, microphones, ambient microphone, excessive wear, call speaker, volume/mute buttons, camera glass, rear camera, front camera, home button, ringer, Touch ID, speaker, Wi-Fi, cellular network, call function, motherboard and no-power condition. Every test can be enabled or disabled with a simple switch, based on what is actually relevant to check for your type of devices (a company that only repairs PCs, for example, would disable the smartphone-specific tests). Besides predefined tests you can create custom tests with a name of your choice, to cover specific checks not present in the standard list.
The testing card, visible on each individual repair in the Lab, is organized into two separate tabs: "in" tests (run at intake, to capture the starting condition) and "out" tests (run before returning the device, to certify everything works). For every active test, the technician can mark an OK or KO outcome with a simple tap; if the device won't turn on at all and tests cannot be run, a dedicated "device off" option skips the entire checklist for that phase, avoiding the need to manually check off dozens of unverifiable items. Every completed checklist stays saved and viewable in the repair's history, with results kept separate for intake and delivery.
Quick guide
- Go to Company > Device tests.
- Enable or disable predefined tests based on your needs (touch screen, cameras, battery, Wi-Fi, motherboard, etc.).
- If needed, create a new custom test with a descriptive name.
- When accepting a repair, open the device test card in the Lab section and select the "in" tab.
- Mark OK or KO for every active test, or enable "device off" if the checks cannot be run.
- Before returning the device to the customer, go back to the same test card and fill in the "out" tab with updated outcomes after the repair.
- Save the results: they stay visible in the repair's history for any future comparisons.
Real use cases
A customer brings in a smartphone with a cracked screen: at intake, the technician runs the "in" testing and marks KO on the front glass test (already damaged) but OK on camera, Wi-Fi and speaker, giving an accurate snapshot of the starting condition before working on the screen alone.
After replacing the screen, the technician fills in the "out" checklist: all tests come back OK, including the front glass test which is now replaced, and the customer receives the device with documented certainty that every function was checked before it was returned.
A laptop arrives completely dead and no functional test can be run at intake: the technician enables the "device off" option on the "in" tab, avoiding having to manually handle dozens of unverifiable items, and moves straight into diagnosing the power-on fault.
Tips and best practices
Always run the intake testing before starting any intervention, even when the reported fault seems to involve only one component: discovering an unreported pre-existing problem after you have already worked on the device exposes the shop to disputes. Disable tests that are not relevant to your line of business to keep the checklist lean and quick to fill in. Always use the "out" checklist as a final quality check before every delivery, not just for the more complex repairs.
Common mistakes to avoid
Do not skip the intake testing to save time: it is precisely the absence of this check that generates the hardest disputes to handle. Do not leave too many predefined tests enabled if they are not relevant to your business: an overly long checklist discourages staff from filling it in carefully. Remember to use the "device off" option when nothing can genuinely be tested, instead of leaving tests simply unfilled, which makes the repair history ambiguous.
Frequently asked questions
Can I disable a predefined test without deleting it? Yes, every predefined test can be enabled or disabled at any time without losing its configuration: just turn it back on when you need it again.
What is the difference between intake and delivery testing? Intake testing captures the device's condition when accepted, before any intervention; delivery testing certifies its functioning before being returned to the customer, so the two moments can be compared.
What happens if the device won't turn on at intake? You can enable the "device off" option on the "in" tab, which skips the entire checklist for that phase without having to fill it in item by item.
Are custom tests valid across all company shops? Yes, tests configured under Company > Device tests are part of the company-wide configuration and are used in the testing checklist for repairs managed by the company, regardless of the shop.
Who actually performs the tests during a repair? The technician working on the repair, from the device test card in the Lab section, marking OK or KO for each item while verifying the device's functionality.
Do test results remain viewable after delivery? Yes, the completed checklist with intake and delivery outcomes stays saved in the repair's history, viewable for future checks or disputes.
