Skip to main content

Technical Checklist Before Customer Delivery

Purpose of this article​

This article gathers the technical checklist that the partner should follow before delivering devices to the customer, conducting training, or starting first use of the Dersalis/BioLink solution.

Use this guide to confirm that devices are prepared, the initial configuration has been applied, connectivity has been validated, and the customer has the minimum conditions to start the operation.

This article does not replace the specific preparation guides. For details, see:

When to use this checklist​

Use this checklist before:

  • delivering equipment to the customer;
  • releasing devices for training;
  • starting controlled first use;
  • considering technical preparation complete;
  • declaring that the implementation is ready to move forward.

The goal is to prevent the customer from receiving an incomplete solution, without testing, or with unresolved dependencies.

Main rule​

The customer should not receive devices or start operation without minimal functionality validation.

Technical delivery should only proceed once the partner can confirm that equipment, access, app, connectivity, initial configuration, and support are ready for first use.

1. Confirmed technical scope​

Before validating equipment, confirm that the project's technical scope is clear.

Check:

  • operation to be monitored;
  • unit, area, shift, or initial group;
  • initial number of operators;
  • chosen approved device;
  • defined usage model;
  • whether an Android phone is needed or not;
  • whether MDM is needed or not;
  • partner's responsible parties;
  • customer's focal points;
  • expected date for delivery, training, or first use.

If the scope is still undefined, do not proceed to delivery.

2. Approved device defined​

Confirm the project will use only currently Dersalis-approved devices.

Approved devices:

  • Polar 360;
  • Polar Verity Sense;
  • i.safe Mobile IS-SW smartwatch.

Requests for other sensors, smartwatches, or devices must be evaluated with Dersalis before any commitment to the customer.

3. Devices received and checked​

Before delivery, check the physical equipment.

Check:

  • quantity received;
  • correct model;
  • necessary accessories;
  • chargers;
  • straps, armbands, or usage items;
  • physical condition of devices;
  • signs of damage or wear;
  • serial number or identification, when applicable;
  • packaging and support items.

If there's a discrepancy, log the issue before delivering to the customer.

4. Devices identified​

Each device must be identified to facilitate usage, support, and traceability.

Confirm:

  • sensors identified;
  • smartwatches identified;
  • phones identified, when applicable;
  • device-to-customer relationship recorded;
  • delivery control defined;
  • return control defined;
  • a way to set aside problem devices defined.

Identification prevents incorrect swapping, wrong sensor selection, and support difficulties.

5. Battery and charging validated​

Before delivery, confirm all equipment is charged and there's a charging routine.

Check:

  • sensors charged;
  • phones charged, when applicable;
  • smartwatches charged;
  • chargers available;
  • charging location defined;
  • person responsible for charging defined;
  • end-of-shift charging routine defined;
  • guidance on what to do if a device is discharged.

An operation without a charging routine tends to fail within the first few days.

6. Android phone validated, when applicable​

This step applies to projects with Polar sensors.

Confirm which model will be used:

  • Android phone in kiosk mode;
  • customer's corporate Android phone.

If it's a kiosk phone​

Validate:

  • device charged;
  • Dersalis App available;
  • Hexnode applied, when planned;
  • kiosk mode working;
  • Bluetooth active;
  • permissions granted;
  • connection with sensor tested;
  • behavior after restart validated;
  • charging routine defined;
  • usage location defined.

For details, see How to Configure an Android Phone in Kiosk Mode with Hexnode.

If it's the customer's corporate phone​

Validate:

  • compatible Android version;
  • Dersalis App installed;
  • necessary permissions granted;
  • functional Bluetooth;
  • available connectivity;
  • absence of corporate blocks;
  • customer's MDM policy compatible with usage;
  • device support responsibility defined.

If the corporate phone doesn't meet the minimum requirements, it should not be used in the project.

7. Dersalis App validated​

When the Dersalis App is used, confirm:

  • app installed;
  • app opens correctly;
  • app is on the expected version;
  • permissions granted;
  • correct environment;
  • shift-start flow available;
  • ID or identifier accepted, when applicable;
  • sensor selection working;
  • pause and end working, when applicable;
  • app is not blocked by MDM, battery saver, or corporate policy.

Don't consider the app validated just because it opens. The operational flow needs to work.

8. Bluetooth validated, when applicable​

This step is essential in projects with Polar sensors.

Confirm:

  • Bluetooth enabled on the Android phone;
  • sensor turned on;
  • sensor close to the phone;
  • sensor appears in the Dersalis App;
  • sensor can be selected;
  • connection remains stable during the test;
  • Bluetooth permissions granted;
  • no MDM policy blocks the connection.

If there's a Bluetooth failure, resolve it before training operators or delivering devices.

9. Wi-Fi or mobile network validated​

Before delivery, validate that connectivity matches the project's model.

Confirm:

  • Wi-Fi available, when applicable;
  • mobile network available, when applicable;
  • data reaching the platform;
  • absence of network blocks;
  • functioning at the real location or under conditions close to the operation;
  • behavior in weak-signal areas, if that's part of the routine;
  • a support point defined in case connectivity fails.

If the customer depends on real-time monitoring, connectivity needs to be tested more rigorously.

10. GPS validated, when it's part of the use case​

Not every project requires GPS.

When location is part of the scope, confirm:

  • GPS is required for the use case;
  • the chosen device meets the requirement;
  • the signal works in the expected environment;
  • location appears as expected;
  • privacy restrictions or internal policies were considered;
  • the customer understands how location will be used.

If GPS is essential and there's technical doubt, involve Dersalis before delivery.

11. Initial configuration applied​

Before releasing first use, confirm that the recommended initial configuration was applied.

Check:

  • customer company created or validated;
  • initial operation configured;
  • default parameters applied;
  • mandatory configurations completed;
  • settings that should not be changed preserved;
  • exceptions documented;
  • customization questions forwarded to Dersalis, when necessary.

For details, see the articles in the Recommended Configuration section.

12. Users and profiles validated​

Confirm the users needed for first use are ready.

Check:

  • operators registered;
  • correct IDs or identifiers;
  • managers registered;
  • supervisors or focal points registered, when applicable;
  • appropriate access permissions;
  • duplicates removed;
  • initial list validated with the customer.

Incorrect registration can prevent shift start or generate data linked to the wrong person.

13. Test flow executed​

Before delivering to the customer, run an end-to-end test.

The test should confirm:

  • device turns on;
  • app or smartwatch works;
  • an operator or tester can start a shift;
  • sensor or device connects correctly;
  • data reaches the platform;
  • manager or focal point can view the data;
  • pause or end works, when applicable;
  • alerts or messages appear as expected, when applicable;
  • support knows what to do in case of failure.

This test is the main technical criterion for approving delivery.

14. Operational routine defined​

The solution needs a clear day-to-day routine to function.

Confirm with the customer:

  • where devices will be stored;
  • who delivers equipment to operators;
  • who collects it at the end of the shift;
  • who puts it on the charger;
  • who checks battery before use;
  • who sets aside problem devices;
  • who monitors the platform;
  • who responds to alerts;
  • who requests support;
  • how questions will be communicated.

Without an operational routine, even technically correct devices can fail in real use.

15. Focal point and support defined​

Before delivery, confirm the support channels.

Check:

  • customer's focal point defined;
  • partner's focal point defined;
  • communication channel defined;
  • service hours or critical window agreed;
  • first-level support responsible defined;
  • escalation criteria to Dersalis known;
  • mandatory information for tickets explained.

For details, see When to Escalate to Dersalis.

16. Initial orientation prepared​

Before delivering equipment, the partner should prepare basic guidance for the customer.

The customer should understand:

  • what they're receiving;
  • what each item is for;
  • how to store and charge the equipment;
  • who should use the devices;
  • what the first use will look like;
  • who will monitor the operation;
  • who to contact in case of a problem;
  • any remaining pending items, if applicable.

The customer should not receive equipment without minimal explanation of usage and responsibility.

17. Pending items recorded​

If there are any pending items, they should be recorded before delivery.

Record:

  • description of the issue;
  • responsible party;
  • impact;
  • resolution deadline;
  • whether or not it prevents first use;
  • whether it depends on the partner, customer, or Dersalis;
  • decision made.

Don't leave important pending items only in informal conversations.

Final checklist before delivery​

Before delivering to the customer or releasing first use, confirm:

  • technical scope defined;
  • approved device chosen;
  • equipment checked;
  • equipment identified;
  • battery validated;
  • charging routine defined;
  • Android phone validated, when applicable;
  • Dersalis App tested, when applicable;
  • Hexnode validated, when applicable;
  • Bluetooth tested, when applicable;
  • Wi-Fi or mobile network validated;
  • GPS validated, when applicable;
  • initial configuration applied;
  • users registered;
  • test flow executed;
  • data reaching the platform;
  • operational routine defined;
  • focal point defined;
  • first-level support prepared;
  • initial orientation prepared;
  • pending items recorded.

Technical approval criteria​

Technical delivery can be considered ready when:

  • devices work;
  • the operational flow has been tested;
  • data reaches the platform;
  • the customer knows how to use, store, and charge the equipment;
  • the partner knows how to provide initial support;
  • critical pending items have been resolved;
  • non-critical pending items have been logged with a responsible party and deadline.

If any of these points is not met, delivery should be postponed or done with a formally recorded pending item.

What to avoid​

Avoid:

  • delivering devices without charge;
  • delivering devices without identification;
  • starting training without a technical test;
  • releasing first use without data reaching the platform;
  • using a corporate phone without validating requirements;
  • delivering a kiosk phone without testing Hexnode;
  • leaving the customer without a charging routine;
  • leaving support undefined;
  • assuming connectivity will work without testing;
  • hiding pending items;
  • passing on to the customer problems that should have been solved before delivery.

When to involve Dersalis​

Involve Dersalis when:

  • there's doubt about initial configuration;
  • the device doesn't connect after basic checks;
  • data doesn't reach the platform;
  • the corporate phone doesn't meet the requirements;
  • Hexnode shows unexpected behavior;
  • there's a network, MDM, or permission block;
  • the device seems unsuitable for the operation;
  • the customer requests an exception or customization;
  • a pending item prevents first use;
  • the partner isn't confident enough to approve delivery.

When contacting Dersalis, send:

  • customer;
  • operation;
  • device used;
  • phone used, when applicable;
  • applied configuration;
  • description of the pending item;
  • tests performed;
  • available evidence;
  • impact on delivery;
  • deadline expected by the customer.

Expected outcome​

At the end of this checklist, the partner should know whether the solution is technically ready to be delivered to the customer, used in training, or released for controlled first use.

Delivery should only happen once devices, access, connectivity, configuration, routine, and support have been validated.

Next step​

After completing the technical checklist, proceed to the Recommended Configuration section or to the Step-by-Step Partner Implementation guide, depending on the project stage.

Summary​

The technical checklist before delivery ensures the solution isn't delivered to the customer incompletely.

The partner must validate devices, phone, Dersalis App, Hexnode when applicable, connectivity, initial configuration, users, data on the platform, operational routine, support, and pending items before releasing training or first use.