Technology
›
Electronics & Hardware
›
Consumer Electronics
Wearables & Hearables
Complex technical sales and manufacturing engagements across the global electronics supply chain.
Example organizations in this space:
Apple
Fitbit
Garmin
Samsung
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify and diagnose before investing in a full evaluation cycle.
-
Fit & Channel Qualification
Confirm buyer profile (consumer vs enterprise), procurement constraints, data-privacy needs, and timeline before investing in full discovery.
Qualification Questions
Buyer profile and channel fit
- Which buyer profile best describes this opportunity?
- If enterprise, channel, or corporate buyer, who is the primary internal sponsor or buyer role? (title or department)
Procurement and contracting constraints
- Which procurement path will be used to purchase devices and subscriptions?
- What is the typical procurement lead time or decision window for deals like this?
Data privacy and compliance
- Will personal health information (PHI) or identifiable biometric data be processed, stored, or shared under the buyer's policies?
- Are there specific data residency, encryption, or vendor security assessments we should be aware of?
Budget, decision authority, and readiness
- Is an approximate budget allocated for this purchase (per unit or subscription), or is this exploratory?
- Who is the final decision maker or signatory for a purchase like this?
-
Customer Discovery
Map desired outcomes, clinical validation needs, stakeholders (HR, clinicians, IT), and success metrics relevant to device accuracy and integrations.
Discovery Questions
A quick picture of how you use wearables
- Tell me briefly why you are exploring wearable devices today
- In your organization or household, who will be the primary user or beneficiary of the devices
- Describe the top three outcomes you hope the device delivers for that user
- How often would that user interact with the device and companion app in a typical week
- Which of these features are essential versus nice to have for your use case
- Give an example of a recent device purchase or program adoption and what ultimately tipped the decision
Where the results actually matter
- If imperfect device accuracy or missed alerts cost you a clinical escalation, what would that cost your users or program in trust and outcomes
- Estimate how many false alerts or missed events per month you could tolerate before users or clinicians start to lose confidence
- Tell me about a previous time when a biometric signal was unreliable, what immediate actions did your team take
- Who on your team must be convinced that sensor accuracy is sufficient for clinical programs or benefits reporting
- How would a sustained 10 to 20 percent lift in daily active use change the financial case for your subscription or wellness program
- Which types of clinical validation would your reviewers want to see before approving a program
Where deployments tend to fail
- Who has owned previous device rollouts and what lessons from those projects still shape your expectations
- Describe the most common integration that has delayed a pilot in the past, for example authentication, data ingestion, or roster synchronization
- When carrier activation or mobile provisioning is involved, what lead times have you seen and which deadline is non negotiable
- Estimate how many people you can allocate to support an integration sprint, counting IT, security, and the wellness admin
- If a single gating issue would stop the project immediately, which one is it
The other paths you are weighing
- List the alternatives you are actively keeping on the table, including internal builds and incumbent devices
- Explain what would have to be true about your current approach for you to stay with it rather than switching
- Do any internal teams propose building the capability themselves instead of buying, and which teams are advocating for that
- Compare the incumbent option on these areas: support responsiveness, firmware updates cadence, and ability to export raw biometric data
- At what adoption or cost thresholds would you prefer the internal project over an outside partner
- Would you still consider switching if staying with the current vendor required no extra certification or privacy review
Rollout realities and gating criteria
- Name the exact systems a deployment must connect to, for example your SSO provider, HRIS, MDM, wellness platform, or EMR
- Identify who owns API keys, mobile device management, and data export agreements on your side
- Rate the readiness of your historic biometric and roster data for a 90 day pilot
- When legal or privacy reviews are required, how long do they typically take and which approvals are fatal to the timeline
- Provide the internal bandwidth you can commit to a pilot in hours per week from IT, clinician reviewers, and admin
- Are there carrier testing or retail certification windows already booked that cannot be moved
Metrics and money that move this decision
- Assume the pilot delivers a measurable reduction in clinical escalations or a lift in engagement, what remaining financial or regulatory barriers would still prevent approval
- Provide a budget range you expect for devices, provisioning, and an initial pilot including support hours
- Name the internal metrics procurement, legal, and clinical leadership will use to judge success
- Identify the stakeholders who must sign the purchase order, data processing agreement, and pilot acceptance
- What is your expected pilot duration from deployment to decision and which timeframe is your target
- Would you be prepared to commit to a scaled order within 60 days if the pilot proves the target metrics
A tight plan to test, learn, and decide
- Share who will run the pilot day to day and who the executive sponsor is that will sign off on outcomes
- Specify the minimum sample size and duration that would convince you the device accuracy and engagement signals are real
- Explain the escalation path when issues arise during a pilot and the timeline you expect for fixes
- Give the KPIs that would trigger a stop or restart of the pilot for example accuracy below your acceptable threshold, adoption under target, or a privacy incident
- Do you need a formal pilot acceptance document to release funds or would a joint signoff email suffice
- What are the next three actions you want us to take after this discovery to make progress
-
-
Solution Experience
Walk through how device hardware, companion apps, and subscription services deliver the buyer's outcomes and fit into clinical and benefits workflows.
Solution Experience
- Solution Experience - Device, App, and Subscription Walkthrough
- Confirm the current state and its cost
- You confirm the demonstrated device-to-clinical workflow removes the clinical evidence blocker you described.
- Deliver a concise clinical validation packet including study abstracts, sensor accuracy summary, and regulatory status within 5 business days.
- You confirm the privacy and data flow artifacts shown satisfy the requirements of benefits, legal, or privacy reviewers or list remaining gaps.
- Walk through the clinical workflow end-to-end
- Provide a clear privacy and data-processing diagram showing consent flows, data retention, and anonymization methods for review by legal/privacy.
- You agree on a pilot scope and timeline or identify the specific evidence still needed to approve the pilot.
- Prove the privacy and data flow controls
- Confirm pilot cohort owners, target cohort size, and target go-live window to enable a provisioning plan.
- Show the pilot provisioning and activation workflow
- Run a short provisioning trial on a small device batch and capture time-to-activation and any errors for the follow-up meeting.
- Validate the future state with the group
- Solution Experience - Device, App, and Subscription Walkthrough
- Solution Experience Deck
- Solution Brief - Device, App, and Services
- meeting
- slides
- document
-
Solution Scope
Define device SKUs, sensor suites, provisioning, enterprise dashboard features, privacy controls, and subscription modules to be included.
Scope Configuration
- Fulfill and Ship Hardware Orders
- Bulk Device Provisioning and Enrollment
- Activate Cellular Connectivity and Carrier Provisioning
- Enable Clinical Sensors and ECG Feature Activation
- Activate Irregular-Rhythm and Anomaly Alerts
- Provision Companion App Accounts and Access
- Grant Premium Subscription and Coaching Access
- Configure Corporate Wellness Dashboard and Roles
- Integrate with Corporate Wellness Platform (API)
- Set Up Aggregate Anonymized Reporting Exports
- Enable Secure Health Data Sharing for Clinicians
- Deploy OTA Firmware and Sensor Calibration Updates
- Activate HRV, Training Load, and Recovery Analytics
- Preload Guided Workouts and Mindfulness Content
Scope Questions
Fulfill and Ship Hardware Orders
- Provide the full list of SKUs and quantities to be fulfilled (include SKU, color/size, and quantity per SKU).
- List your receiving location details and preferred shipment windows (dock hours, time zone, and receiving SLA).
- Confirm whether serial numbers (S/N) or IMEIs must be pre-mapped to employee IDs in a provisioning CSV before shipment.
- Specify your customs, import, or carrier paperwork requirements for international shipments (e.g., commercial invoice, ECCN) and any special labeling needs.
- Indicate required acceptance criteria at your receiving dock (for example: sample power-on rate >= 98%, correct SKU match, sealed packaging intact).
- Estimate the percentage of units that must be held as pre-shipment QA samples for your audit and provide the target sample count.
Bulk Device Provisioning and Enrollment
- Provide the provisioning file format you will supply or accept (for example: CSV with columns: S/N, ICCID/IMSI, employee_id, email).
- Identify the MDM/EMM profile name or the provisioning profile fields required to enroll devices (MDM profile, Wi-Fi SSID, timezone, locale).
- Confirm whether devices should be bulk-provisioned to user accounts prior to shipping or enrolled post-delivery during the pilot window.
- Specify enrollment success criteria (for example: percentage of devices reporting first heartbeat within 24 hours and MDM check-in success rate).
- Describe the reconciliation process you require between ordered SKUs and provisioned serial numbers (for example: automated reconcile report in CSV daily).
- Estimate the total number of devices to provision in the pilot and at scale and the expected ramp cadence (numbers per week/month).
Activate Cellular Connectivity and Carrier Provisioning
- Specify whether devices will use eSIM profiles or physical SIMs and supply the provisioning method required by your carrier (SIM swap, carrier API, ICCID list).
- Identify required carrier test artifacts and acceptance checks (for example: carrier certification test plan ID, call/data test pass criteria, APN settings).
- Indicate the authentication method for carrier provisioning APIs (API key, OAuth2 client credentials, SFTP token) and whether we should coordinate a certificate exchange.
- Describe the expected activation milestone timeline (for example: carrier sandbox testing complete, pilot activations, full fleet activation dates).
- State any constraints the carrier imposes on order size or monthly minimums that will affect provisioning scheduling.
- Confirm the owner at your organization for carrier coordination (name, role, and expected availability window for carrier calls).
Enable Clinical Sensors and ECG Feature Activation
- Identify which device models (by SKU) require ECG activation and list the ECG firmware or algorithm version required for the deployment.
- Specify clinical validation thresholds you need for ECG and PPG sensor performance (for example: sensitivity >= X% for atrial fibrillation detection, false positive rate < Y%).
- Describe the regulatory or privacy constraints governing ECG data in your jurisdiction that affect activation (for example: HIPAA, GDPR, local biometric rules).
- Indicate whether ECG activation requires explicit end-user consent at first app launch and whether consent text must include specific clauses.
- State the telemetry/reporting fields you require from enabled sensors (for example: raw ECG sample rate, processed rhythm label, timestamp, device S/N).
- Provide the expected acceptance test for sensor activation (for example: set of 50 sample ECG traces with annotation agreement >= 95%).
Activate Irregular-Rhythm and Anomaly Alerts
- Identify which alert types you want enabled for the pilot (for example: irregular rhythm notification, high resting heart rate alert, desaturation alert).
- Specify alert thresholds and persistence rules (for example: HR > 120 bpm sustained for 5 minutes triggers alert).
- Describe the clinician or benefits escalation workflow for alerts (for example: user shares PDF report to PCP, or aggregated alerts to corporate nurse triage).
- Indicate acceptable false-positive tolerance for the pilot by alert type (for example: target positive predictive value for irregular rhythm >= 70%).
- Specify whether alerts should surface in the companion app, corporate dashboard, or be sent by secure email/SMS and include required delivery format (JSON webhook, PDF).
- Provide the alert review SLA you expect for triage teams (for example: initial review within 48 hours of alert generation).
Provision Companion App Accounts and Access
- Specify the account provisioning method you prefer for the companion app (for example: email invite with magic link, SSO via SAML/OAuth2, bulk-created accounts keyed to employee ID).
- Identify profile fields required on user accounts (for example: DOB, gender, employee ID, primary care clinician contact) and which are mandatory.
- Indicate whether you require Single Sign-On provisioning and specify the protocol and metadata endpoint to be used.
- Describe the account lifecycle rules (for example: deactivate after 30 days of inactivity, re-provisioning window, offboarding process).
- Provide the expected onboarding flow for users (for example: number of guided steps, required e-consents, initial sensor calibration).
- Specify whether you need role-based access within the app (for example: participant, manager, clinician) and list required role names.
Grant Premium Subscription and Coaching Access
- State the premium subscription SKU(s) to be granted and how entitlement mapping should occur (by serial number, email, or corporate code).
- Specify the coaching feature set to include in entitlements (for example: live coaching sessions, personalized plans, 1:1 messaging) and any usage caps.
- Indicate billing model expectations for subscriptions (for example: prepaid by company for 12 months, employee-paid, or mixed) and any minimum commitment period.
- Describe reporting requirements for subscription uptake and coaching engagement (for example: weekly CSV export with active users, session counts).
- Provide the entitlement activation timeline for pilot and full rollout (for example: activate entitlements within 48 hours of account provisioning).
- Specify the owner for subscription disputes and refunds and the expected SLA for resolution.
Configure Corporate Wellness Dashboard and Roles
- Identify the dashboard roles and permissions you require (for example: program admin, benefits manager, clinician reviewer) and the data each role may view.
- Provide the list of metrics and KPIs to display on the dashboard (for example: adoption rate, average daily wear time, percent with irregular rhythm notifications).
- Describe row-level or cohort filters you need (for example: filter by department, location, or pilot cohort tag) and required export formats.
- Confirm the acceptance criteria for dashboard delivery and integration (for example: mapped fields match API spec, test cohort data present, dashboard load time < 5s).
- Specify SSO or user provisioning integration for dashboard access (for example: SAML metadata URL, SCIM user provisioning support).
- Indicate whether the dashboard requires exportable anonymized datasets for insurance reporting and the required anonymization technique (for example: k-anonymity, hashing).
Integrate with Corporate Wellness Platform (API)
- List the API endpoints and payloads your wellness platform requires (for example: POST /participants, GET /aggregates) and the data schema version.
- Specify authentication and authorization method for the integration endpoint (for example: OAuth2 client credentials, mTLS, API key) and certificate exchange needs.
- Identify field-level data mapping requirements including PII fields and any fields that must be omitted or pseudonymized before transmission.
- Describe expected API performance and SLA requirements (for example: API call latency < 500ms, payload batch size limits).
- Provide a sample dev/test account or sandbox endpoint and confirm whether we can run test pushes against it.
- Specify retry/backoff and error-handling expectations for failed API calls (for example: retry 3 times with exponential backoff, dead-letter queue).
Set Up Aggregate Anonymized Reporting Exports
- Indicate the export cadence you require for aggregated reports (for example: daily CSV at 02:00 UTC, weekly summary).
- Specify the anonymized metrics and aggregation window (for example: daily average HR by cohort, 7-day rolling sleep efficiency) and minimum cohort size for release.
- State the anonymization threshold you require before exports can include subgroup data (for example: minimum 10 users per subgroup).
- Describe the export delivery method and format (for example: SFTP CSV, secure API push with JSON, or scheduled email to a secured mailbox).
- Identify retention and deletion policy for raw telemetry used to generate aggregates (for example: retain raw for 90 days, then delete).
- Provide an example anonymized export schema or confirm we should propose a schema based on required KPIs.
-
Mutual Commit
Finalize commercial terms, data processing and privacy agreements, carrier or retail requirements, and delivery milestones.
Agreement Modules
- Purchase Agreement
- Order Confirmation
- Subscription Agreement
- Data Processing Agreement (DPA)
- HIPAA Business Associate Addendum (BAA)
- Carrier & Retail Requirements Addendum
- Delivery & Milestones Schedule
- Bulk Provisioning and Activation Schedule
- Implementation Statement of Work (SOW)
- Hardware Warranty & Returns Policy
- Payment Schedule & Invoice Terms
-
Deployment
Lock readiness facts and configuration values before execution begins.
-
Pre-Deployment Readiness
Confirm concrete readiness facts — enrollment owners, pilot cohorts, privacy approvals, shipping windows, and integration points before rollout.
Pre-Deployment Questions
Environment and site access
- Is the buyer's production backend/API environment available for integration, or what target date will it be available? (so we can schedule integration and activation testing)
- If the production environment is not available now, what is the confirmed availability date? (enter a single date)
- Has the buyer granted test/provisioning access to the integration endpoints needed for provisioning and activation?
- If access is pending or not granted, provide the approver/contact name and role responsible for granting integration/test access (so we can request credentials through the right person).
Data and configuration
- Which system will be the source of truth for user enrollment and device assignment? (select the category we will integrate with)
- Is the field-mapping approach (user identifiers, device serial mapping, enrollment flags) finalized for the pilot?
- Name the owner (person and role) responsible for enrollment data and field mapping in the source-of-truth system.
People and ownership
- Who will own day-to-day enrollment operations for the pilot cohort?
- Provide the named enrollment owner(s) and primary contact details (name, role, email) who will run pilot enrollments.
Timing and constraints
- Are all required privacy and data processing approvals for the pilot (DPA, internal legal sign-off, IRB where applicable) completed?
- If approvals are pending or not started, who is responsible for securing them (name and role) and what is the target approval date?
- What is the confirmed shipping window for pilot device delivery (or target month if exact dates are pending)? (so we can align provisioning, carrier activation, and logistics)
-
Configuration Details
Capture exact configuration values the deployment team will use — provisioning credentials, API endpoints, MDM/portal settings, and carrier activation milestones.
Configuration Details
Environments & Endpoints
- Enter the Production API base URL the deployment will call (format: https://.../v1). Default: https://api.your-domain.com/v1 — enter the exact, production-facing URL.
- Select the primary cloud region to host the device cloud and backend services (Default: us-east-1).
- Enter the provisioning webhook callback endpoint the platform will call when a device is provisioned (format: https://... ). Enter the exact URL.
Authentication & Identity
- Identity provider (IdP) type for enterprise dashboard SSO — choose the protocol the buyer will use.
- Enter the SSO identifier to use (If SAML: Entity ID; If OIDC: Client ID). Enter the identifier string only — DO NOT paste secrets or client secrets.
Device Provisioning & Carrier
- Select the device provisioning method to configure (this drives enrollment flow and portal settings).
- Provide the exact topic or queue name the provisioning workflow will publish to (enter the topic/queue ID consumed by the deployment).
- Carrier activation milestone target in days from ship date — Default: 14 (enter numeric days).
Features, Modules & Limits
- Select which product modules should be enabled for this deployment (multi-select).
- Default device data retention period in days — Default: 365 (enter numeric days). This is the retention the deployment will enforce for device telemetry.
- Enter the user identifier attribute name in the buyer's source system that maps to the platform user_id (exact attribute name).
-
Deployment
Execute rollout with clear owners, pilot sequencing, carrier activations, bulk provisioning, and escalation paths.
-
-
Success
Review adoption, device accuracy and clinical alert outcomes, and maintain a shared channel for issues, enhancements, and customer feedback.
Success Reviews
- Go-live Health Check
- First Measurement Review (weeks 4-10)
- Acceptance Gate Review (around day 90)
- Quarterly Outcomes Review
Issues & Enhancements
- Maintain the shared issue channel with agreed SLAs for response and an escalation path for clinical-impacting alerts.
- Schedule targeted technical triage to reproduce device accuracy issues identified in the cohort.
- Restate acceptance criteria and numeric targets
- Record a documented acceptance decision against each numeric criterion from Customer Discovery.
- For any failed criteria, capture remediation tasks with specific completion dates and verification steps.
- Ensure the acceptance record and underlying data are published in the journey workspace.
- Publish the acceptance decision document with supporting data attachments and link it in the journey workspace.
- Create remediation tickets for each failed or conditional acceptance item with resolution timelines.
- Schedule the re-check meeting(s) for conditional acceptance items with a target date.
- Adoption and cohort trends
- Confirm adoption and alert performance are within acceptable ranges or document required operational adjustments.
- Ensure the top outstanding device accuracy and operational issues have remediation timelines and verification plans.
- Maintain a living issues and enhancement backlog with agreed priorities for the next quarter.
- Publish the quarterly outcomes summary that includes adoption, accuracy, and alert performance charts.
- Prioritize and create tickets for the top 5 operational defects or enhancements that affect adoption or alert accuracy.
- Re-confirm success criteria and ownership
- Confirm deployment components are live and that no critical activation failures remain.
- Identify the top 3 early blockers and document remediation actions with timelines.
- Ensure owners for immediate fixes are named in the journey workspace and next verification steps are scheduled.
- Publish the go-live verification log with pass/fail status for provisioning, dashboard access, and carrier activations.
- Create remediation tickets for each critical blocker with target verification dates.
- Update the deployment runbook with any bypasses or fixes applied during go-live.
- Present first measurement data
- Decide a prioritized remediation plan for any metric shortfalls and record target resolution dates.
- Confirm whether weekly active device rate and irregular rhythm alert PPV are tracking to Customer Discovery targets.
- Document the data sources and reports that will be used in the acceptance gate.
- Publish a one-page metric variance report showing current values, target values from Customer Discovery, and variance.
- Create remediation tasks for each root cause with due dates and verification steps.
- Present outcome data against each criterion
- Device accuracy and clinical alert outcomes
- Deployment and provisioning validation
- Diagnose root causes for gaps
- Document pass/fail per criterion and capture acceptance decision
- Early adoption signals and usage patterns
- Open issues, customer feedback, and incident burn-down
- Agree corrective actions and timelines
- Blockers and open issues
- Confirm timeline to acceptance gate
- Enhancements and maintenance priorities
- Agree remediation items and resolution timeline for any failed criteria
- Agree immediate remediation actions
- Close the loop and publish the acceptance record
- Confirm next quarter checkpoints