Go-to-Market Guide

You've built and certified your smart connected product, proven the technology works, and established a manufacturing workflow. Now comes the moment of truth: getting it into customers' hands and making sure they are successful! This transition from "product works" to "product sells and delights customers" requires as much planning as the technical development that preceded it.

This guide provides a high-level overview of the go-to-market and customer onboarding considerations for smart connected products using Blues Notecard. Starting with pricing strategy, through to sales enablement, and on to ongoing customer support.

note

Key Takeaways

• Anchor pricing in measurable value creation, not cost recovery.
• Align sales incentives and capabilities with your connected revenue model.
• Design onboarding to minimize friction and accelerate time to first value.
• Define support tiers, SLAs, and escalation paths before scaling deployment.
• Establish operational readiness before expanding customer volume.

In This Guide

This guide covers the core elements required to successfully bring a smart connected product to market:

• Pricing Strategy for Smart Connected Products: How to define a sustainable pricing model aligned to value creation, market positioning, and long-term growth.
• Sales Enablement: How to prepare your sales organization to confidently sell connected value, not just hardware.
• Customer Onboarding: How to design a frictionless activation experience that accelerates time to first value.
• Support Infrastructure: How to define issue ownership, escalation paths, and operational discipline before scaling deployment.
• Go-to-Market Checklist: A checklist covering pricing, sales, onboarding, support, RMAs, and compliance.

Pricing Strategy for Smart Connected Products

Smart connected products enable pricing models that traditional hardware doesn't. The ongoing connectivity and data services create opportunities for recurring revenue, while the cost structure requires careful modeling to ensure profitability.

Understanding Your Cost Structure

Before setting prices, understand what it actually costs to deliver your product and service.

Hardware costs include your BOM cost, manufacturing and assembly, packaging, and shipping. These are one-time costs you incur for each unit sold.

Connectivity costs for Blues-based products are simpler than traditional wireless options! Notecard Cellular and Cell+WiFi SKUs include 500MB of data and 10 years of service with the hardware purchase. Beyond that, Notehub uses an event credit system where you pay for events sent to Notehub (topped up to 5,000 each month), without monthly subscriptions or per-device fees. This creates predictable, usage-based costs that scale with actual product usage.

Cloud and infrastructure costs include your downstream systems with your cloud provider (e.g. databases, compute time, dashboards, and any third-party services). These typically scale with device count and/or data volume.

Support costs are often underestimated. Every customer interaction has a cost, whether it's answering questions, troubleshooting issues, or dispatching field service. Design your support model and price accordingly.

Development and maintenance costs continue after launch. Firmware updates, cloud infrastructure improvements, and new features require ongoing engineering investment.

Pricing Model Options

Smart connected products support several pricing approaches, each with different implications.

Hardware-only pricing charges customers a one-time price for the device with connectivity and services included. This model is simple to sell and understand, but requires either high hardware margins or acceptance that you're not capturing ongoing value. It works best when the product's value is primarily in the hardware itself, not the data services.

Hardware plus subscription separates the device cost from ongoing service fees. Customers pay upfront for hardware, then monthly or annually for connectivity, cloud services, and support. This model captures ongoing value and creates recurring revenue, but requires customers to commit to ongoing payments. The subscription portion needs to clearly deliver ongoing value.

Subscription-inclusive pricing bundles hardware cost into a subscription, sometimes with low or zero upfront cost. This reduces the barrier to initial adoption and creates predictable recurring revenue. However, it requires you to finance the hardware cost and recover it over the subscription period. Customer churn before payback creates losses.

Usage-based pricing charges customers based on actual product usage like events sent, data consumed, or actions taken. This aligns your revenue with the value customers receive, but creates unpredictable revenue and can make customers hesitant to use the product fully.

Price Positioning

Set prices based on the value delivered, not just the cost to build.

If your product saves customers $10,000 per year in avoided downtime, reduced maintenance, or operational efficiencies, pricing at $2,000 per year represents a strong and defensible ROI, even if your cost to deliver the service is significantly lower. The goal is not to maximize margin in isolation, but to create a clear and compelling value exchange.

When defining pricing, consider the following:

Start with Value Capture, Not Cost Recovery

For entirely new products in emerging categories, value-based pricing is critical. Estimate the measurable financial value created per device, per site, or per deployment. Then determine what percentage of that value your organization can reasonably capture while still leaving the customer with a strong ROI story.

Your sales narrative should make this math easy to explain. A simple "5x return" message is far more powerful than a technically accurate but financially vague explanation. Early pilot deployments are essential to validate and quantify real-world value creation before scaling pricing broadly.

Subscription Pricing Is an Iterative Experiment

If your model includes SaaS or recurring revenue, treat pricing as a structured experiment. It is generally easier to adjust pricing downward over time than to raise prices after customers anchor to a lower number.

When in doubt, consider starting slightly higher to preserve flexibility. Monitor conversion rates, sales cycle length, churn, and expansion patterns to inform future adjustments. Pricing refinement is normal, but resetting expectations upward is difficult.

Preserve Margin for Strategic Flexibility

For hardware or bundled models, leave room for volume discounts, channel margins, or enterprise negotiations. If you begin with minimal margin, you limit your ability to scale through distribution partners or strategic accounts.

Pricing should support your growth strategy, not constrain it.

Benchmark Competitive Alternatives

If similar products exist in the market, conduct structured benchmarking:

• How are competitors pricing hardware versus services?
• Are they bundling subscriptions?
• Are they discounting aggressively to gain share?
• What features or service levels justify price differences?

If your goal is rapid market expansion, you may choose to undercut incumbents. If your goal is premium positioning, ensure your differentiation such as reliability, user experience, integration simplicity, or support model clearly supports the premium.

Consider Geographic and Market Dynamics

Launching across multiple regions introduces additional complexity. Differences in purchasing power, distribution models, tax structures, regulatory requirements, and local support expectations may justify differentiated pricing by geography.

Be deliberate about whether pricing parity or regional variation better supports your strategy.

Sales Enablement

Selling a smart connected product is rarely the same as selling traditional hardware.

Connected offerings often introduce subscription revenue, multi-stakeholder buying groups, ROI-driven purchasing decisions, and IT or security conversations. Without deliberate enablement, sales teams may default to feature-based selling, discount subscription value, or struggle to convert pilots into scaled deployments.

Sales enablement is not just training. It is ensuring your organization can confidently sell financial and operational impact, not just product specifications.

Define What Selling This Product Requires

Before building materials, clearly define what "good" selling looks like for this offering.

Connected products often introduce one or more of the following shifts:

• Recurring or subscription revenue instead of one-time hardware sales
• Value tied to data, workflow improvement, or insights rather than physical features
• Greater involvement from IT, security, or operations teams
• Purchasing decisions driven by ROI rather than specifications

Sales must be able to clearly articulate:

• The operational problem being solved
• The financial impact created
• How value is realized over time
• What changes are required from the customer

Document this explicitly before assessing your team.

Assess Your Sales Readiness

Not every sales organization is immediately prepared for a connected sales motion.

Evaluate your team across four key dimensions:

1. Technical fluency: Can reps confidently explain connectivity, cloud integration, and data flow at a high level?
2. Selling motion alignment: Are they comfortable with consultative discovery, multi-stakeholder engagement, and ROI conversations?
3. Incentive alignment: Are subscription or recurring revenues financially attractive relative to hardware? Are expansion and renewals rewarded?
4. Leadership commitment: Is connected revenue clearly prioritized and reinforced in pipeline reviews?

If structural gaps exist, address them directly. Incentive misalignment or unclear ownership can undermine even strong product-market fit.

Determine Your Sales Model

Based on your assessment, determine whether to:

• Retrain the existing sales team
• Introduce specialist overlays for early connected deals
• Build a dedicated connected sales function

Organizations with strong consultative sellers and aligned incentives can often retrain effectively. Teams with hardware-centric, transactional motions may require additional structural change.

Build the Essential Enablement Assets

Every rep selling your connected product should be able to confidently answer:

1. What specific problem does this solve?
2. How is value created?
3. What does the financial impact look like?
4. What is required to implement successfully?
5. Why are we differentiated?

If reps cannot answer these clearly without engineering support, deals will stall or default to price.

Most teams overbuild materials and underbuild clarity. Focus on a minimum viable enablement stack:

• A concise value narrative deck that clearly explains who the product is for, what problem it solves, and how financial value is created.
• A simple ROI framework or calculator, especially if value varies by customer.
• A connected product sales playbook including ideal customer profile, discovery questions, qualification criteria, and common objections.
• A short objection handling guide covering pricing, integration, security, battery life, and competitive alternatives.

Reinforce Through Structured Education

Enablement does not end at launch. At minimum, plan:

• A foundational training session at launch and periodic refreshers.
• Structured pipeline reviews during the first 60 to 90 days to improve deal quality.
• Ongoing refinement of messaging based on real customer objections.
• Regular product and technical updates to maintain credibility.

Connected revenue is often strategic for the business. Treat sales enablement as a continuous capability, not a one-time event.

note

Many smart connected product sales involve a pilot or proof of concept before full commitment. The Pilot Planning Guide provides detailed guidance on structuring pilots effectively.

Customer Onboarding

The onboarding experience sets the tone for the entire customer relationship. Customers who struggle during setup become support-intensive or churn, while customers who succeed quickly become advocates.

Designing the First Experience

Map your customer's journey from receiving your product to experiencing its value. Identify every step and potential friction point.

Unboxing and physical setup should be intuitive. Clear packaging, minimal required accessories, and obvious first steps reduce setup friction. Include a quick start guide that gets customers to first success with minimal reading.

Device activation and provisioning connects the physical product to your cloud services. For Blues-based products, this typically involves scanning a QR code to associate the device with the customer's Notehub project or your provisioning system. Design this flow to be foolproof.

First data and verification confirms everything works. Customers should see their device sending data within minutes of setup, not hours. This "time to first data" metric is critical. A device that sits inert after setup creates doubt, while a device that immediately shows activity builds confidence.

First value realization is when customers experience the "aha moment", a.k.a. the reason they bought the product. This might be seeing a dashboard, receiving an alert, or accessing a report. The faster customers reach this moment, the more likely they are to succeed long-term!

Onboarding Metrics

Measure customer onboarding success to identify and fix problems. Here are some common metrics that may make sense for your product:

1. Time to first data measures how quickly devices come online after customers receive them. Long times indicate setup friction.
2. Activation rate tracks what percentage of shipped devices actually get activated. Low rates may indicate installation problems, customer confusion, or products sitting unused.
3. Support tickets during onboarding reveal friction points. If customers consistently contact support about the same issues, improve documentation and communication to prevent these issues.
4. Time to first value measures when customers achieve that "aha moment". Depending on the product, this can be harder to measure but more meaningful than almost any other metric!

Support Infrastructure

Efficient support that resolves issues remotely costs a fraction of field service. Inefficient support that requires site visits erodes margins and frustrates customers.

Support Model Design

Design your support model before you need it.

Support tiers segment issues by complexity and route them appropriately. "Tier 1" might handle initial contact, basic troubleshooting, and common questions. "Tier 2" may handle more complex technical issues requiring deeper investigation. "Tier 3" could involve engineering for issues requiring code changes or deep product expertise.

For smart connected products, define what each tier can see and do in Notehub. A "Tier 1" support person might have read-only access to device status and recent events. "Tier 2" might have the ability to modify environment variables for diagnostic purposes. "Tier 3" could have full access including firmware update abilities.

Support channels determine how customers reach you. Email and ticketing systems work for non-urgent issues. Phone support provides immediacy for urgent problems but is expensive to staff. Chat and self-service portals offer middle-ground options.

Response time commitments (a.k.a. SLAs) set customer expectations. Define and publicize what response times you commit to for different issue severities.

Design your support model before you need it. Early deployments can succeed even when support processes are informal. At scale, those weaknesses compound quickly.

As device volume increases:

• Installation friction slows rollout
• Escalations become unclear
• Resolution times lengthen
• Engineering becomes overloaded
• Customer confidence declines

A defined support structure ensures consistent resolution and protects both margins and customer experience.

Define Issue Categories

Before launch, identify the expected types of issues your team will encounter, such as:

• Installation and setup
• Hardware defects
• Connectivity and provisioning
• Firmware behavior
• Data accuracy or integration

Clarify which issues are likely customer-caused versus product-caused. Document common symptoms and likely root causes. This reduces ambiguity and accelerates resolution.

Design Tier Structure and Responsibilities

Support tiers should clearly define what can and cannot be resolved at each level. For example:

1. Tier 1 should focus on repeatable, scriptable troubleshooting.
2. Tier 2 should handle configuration changes and deeper investigation.
3. Tier 3 should be reserved for defects, systemic failures, or engineering-level analysis.

Explicit scope boundaries prevent premature escalation and protect engineering bandwidth.

Map the Escalation Flow

Document the exact path from issue intake to resolution. Define:

• Escalation triggers
• Handoff rules between tiers
• Expected response times between teams
• A single internal owner for each issue category

Customers should not be left navigating between hardware, connectivity, and software teams. Internal clarity prevents external confusion.

Define Partner Engagement

If your solution relies on external platforms or partners, clarify:

• When escalation to a partner is appropriate
• Who owns communication with that partner
• How response time expectations are managed

Maintain a single point of accountability to the customer, even if multiple vendors are involved behind the scenes.

Leveraging Notehub for Support

Blues-based products have significant support advantages through Notehub's remote capabilities.

Device visibility in Notehub lets support staff see device status, recent events, and connectivity history without physical access. When a customer reports an issue, your support team can immediately check whether the device is online, when it last synced, and what data it's sending.

Session data reveals connectivity patterns like connection frequency, session duration, error rates. This helps diagnose intermittent issues that customers struggle to describe.

Watchdog events automatically detect inactive devices, letting you proactively contact customers about problems they may not have noticed yet.

Smart Fleet rules can automatically categorize devices needing attention, creating operational dashboards that highlight problems across your entire fleet.

Consult the Cloud Architecture Guide for more information on making the most out of Notehub.

SLA Management

Service Level Agreements (SLAs) define your support commitments to customers. For smart connected products, SLAs typically cover response time (i.e. how quickly you acknowledge issues), resolution time (i.e. how quickly you resolve issues), and uptime (i.e. what percentage of time devices are operational).

Before committing to SLAs, ensure your operational capabilities can consistently support them. Overpromising on response or uptime without adequate monitoring, staffing, or escalation processes creates both financial and reputational risk.

At minimum, define:

• Issue severity levels and how they are classified
• Target first response times by severity
• Target resolution times by severity
• Communication cadence during active incidents
• Uptime expectations, if applicable

Severity definitions should be explicit. A device offline in a non-critical environment may not require the same response time as a fleet-wide outage affecting production operations.

Operational readiness determines whether SLAs are achievable. Proactive monitoring, remote diagnostics, and clear escalation paths reduce breach risk and improve customer confidence.

Define SLAs deliberately before launch. They should balance competitive expectations with sustainable execution.

Handling Replacements and RMAs

Device failures are inevitable. A defined RMA policy ensures replacements are handled consistently without disrupting customer operations or eroding margins.

Before launch, clearly define:

• What qualifies for warranty replacement
• What conditions fall outside warranty
• Who approves RMA requests
• Whether replacements are shipped in advance or after return
• Who bears shipping or replacement costs

Policy clarity prevents inconsistent decisions and protects both customer experience and financial performance.

Operationally, RMA workflows should:

• Capture device state before replacement
• Transfer configuration to the new device
• Update fleet records to reflect the swap
• Decommission or archive returned devices

Maintain structured records of failure reasons. Patterns tied to firmware versions, environmental conditions, or deployment timing provide valuable input for product improvement.

An effective RMA process balances responsiveness with discipline. Fast replacement builds trust, but consistent qualification prevents unnecessary cost.

Product Documentation

Don't overlook the documentation that accompanies your product! Beyond the installation guides covered in the onboarding section above, plan for user manuals, an online knowledge base, and release notes for firmware and cloud updates. Regulatory compliance statements (e.g. FCC IDs, CE marks, RF exposure warnings) must appear in your product materials.

See the Product Certification Guide for specific requirements.

Go-to-Market Checklist

Before commercial launch, verify you've addressed these areas and you'll set yourself up for success:

Pricing and Commercial

• Full cost structure modeled, including hardware, connectivity, cloud, support, and ongoing maintenance
• Pricing model selected and validated with pilot customers
• Value-based pricing logic defined and ROI narrative clearly articulated
• Subscription pricing approach defined, including iteration strategy
• Competitive pricing benchmark completed, if applicable
• Geographic pricing strategy defined for multi-market launches
• Billing, invoicing, and payment systems operational

Sales Enablement

• Definition of "good" connected selling documented
• Sales readiness assessed across technical fluency, sales motion, incentives, and leadership alignment
• Incentive structure aligned with recurring or subscription revenue goals
• Sales model determined (retrain, hybrid, or dedicated team)
• Clear value narrative deck and ROI framework created
• Connected product sales playbook and objection handling guide completed
• Structured enablement and training plan defined

Customer Onboarding

• Quick start guide created and validated in real-world conditions
• Full installation and activation documentation complete
• Installation and activation workflow tested by non-development personnel
• Onboarding metrics defined (time to first data, activation rate, time to first value)

Support Infrastructure

• Issue categories defined and documented
• Tier structure defined with clear scope boundaries
• Escalation paths documented with defined ownership
• Partner escalation process clarified
• SLAs defined with severity levels and response targets
• Support team trained on remote diagnostics and Notehub troubleshooting

Replacements and RMAs

• Warranty and RMA qualification policy documented
• Approval and replacement process defined
• Configuration transfer and fleet update procedures documented
• Failure reasons tracked for product improvement

Documentation and Compliance

• User manual and knowledge base complete
• Firmware and cloud release notes process defined
• Regulatory and compliance statements finalized

Resources and Next Steps

Launching a smart connected product requires aligning pricing, sales, onboarding, and support into a cohesive commercial motion. Use the checklist above to verify readiness, and leverage the resources below for deeper guidance on specific topics.

Blues Resources

• Pilot Planning Guide
• Making the Business Case
• Managing Devices at Scale
• Blues Pricing

Getting Help

If you have additional questions about commercializing your Blues-based product:

• Post questions on the Blues Community Forum
• Contact Blues sales for partnership and volume discussions