Connected product services should begin with a clearly defined after-sales decision. Before choosing dashboard widgets or creating alerts, identify what your service team needs to decide and which information would help.
A useful starting question is: “What evidence do we need before deciding whether a reported issue requires an on-site visit?”
This article proposes a practical approach to planning that first service. It does not describe a customer deployment or claim measured improvements. Instead, it explains how to define the workflow, assess the available data, and evaluate the results.
Define the after-sales decision first
Start with your service team’s existing process. Review how agents assess reported issues, what they ask customers, and when they escalate a case.
Next, choose one decision within that process. Keep it specific enough for the team to explain what information they need and what action follows.
For instance, you could assess whether available product information supports an approved remote troubleshooting step. Alternatively, your priority could be deciding when to arrange an inspection.
These are possible service objectives, not confirmed outcomes. Select the objective that matches your products, support procedures, and technical capabilities.
Before proceeding, document the decision, its owner, and the conditions that require escalation. Also specify what the team should do when the evidence remains inconclusive.
Check which product data is actually available
Once you define the decision, audit the information your product can provide.
Do not assume that connectivity gives you every measurement needed for diagnosis. Instead, confirm the available sensors, recorded events, communication methods, and access to historical readings.
For each proposed data field, ask:
- Does the product currently generate this information?
- Can the service team access it with the necessary authorization?
- Does its frequency match the decision being considered?
- Can the team verify its timestamp and reliability?
- Does it help answer a specific support question?
Then separate confirmed data availability from development requirements. If the workflow needs an additional sensor or firmware change, include that work in the project scope.
This step gives the team a concrete basis for deciding whether the proposed service is feasible.
Design connected product services around a clear workflow
Next, describe the steps from a customer’s support request to the final service decision.
Specify how the agent identifies the product, reviews the relevant information, and follows approved troubleshooting guidance. Then define how they record the action and its outcome.
Also agree on who maintains the guidance. Product, engineering, and service teams should validate their respective responsibilities before the pilot begins.
Where information is missing, the workflow needs an explicit fallback. For example, an agent may need to request further details or escalate the case.
Keep any proposed remote control capability separate from viewing product data. Changing equipment settings requires an additional assessment of permissions, operational requirements, and safeguards.
The initial service should remain within actions your team has validated and can deliver.
Build the dashboard around the decision
A service dashboard should help its intended user interpret the information relevant to the selected task.
Therefore, begin with the questions the agent needs to answer. Decide which readings, timestamps, and product details belong in the view.
Make unavailable or outdated information visible. In particular, a historical reading should carry enough context to avoid confusion with a current measurement.
The thethings.iO dashboards support device data visualization. The platform also provides alerts and Cloud Code for notifications and business logic.
These are confirmed platform capabilities. However, the configuration, data connections, and workflow required for your service still need project-specific validation.
Similarly, confirm any CRM or ticketing integration before including an automatic handoff in the service offer.
Define access and device lifecycle responsibilities
Before inviting users into the pilot, document who can access each product’s information and which actions they can perform.
Also establish what happens when a product changes owner, a service partner leaves, or a device reaches retirement.
For technical planning, the NIST IoT cybersecurity capabilities catalog provides a reference covering device identification, data protection, interface access, and software updates.
Use it to inform the requirements relevant to your deployment. It does not establish that a particular implementation meets those requirements.
Then assign responsibility for onboarding, credentials, access reviews, and updates. Include these tasks in the operating plan alongside customer support.
Evaluate the pilot without assuming the result
Before launch, document how the selected decision works today. Then choose measures that reflect the purpose of the service.
Depending on the objective, these could include time to a support decision, repeat contacts, or cases requiring further intervention.
Define each measure consistently. Also record cases where the proposed workflow does not help, including missing data and unsuccessful remote troubleshooting.
When comparing results, consider differences in issue complexity and product conditions. A simple comparison may otherwise give an incomplete picture.
Finally, include the costs of connectivity, implementation, platform use, and ongoing support. Assess the service using the evidence collected rather than an assumed efficiency gain.
Take one validated service forward
Connected product services need a defined purpose, usable information, and a team responsible for acting on it.
Start with one after-sales decision. Confirm the technical requirements, test the workflow, and review the evidence before expanding the offer.
Developing a connected product service? Contact thethings.iO to discuss your product, available data, and after-sales objectives.
