Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Calculate ETAs in Operations using Environment data

The Problem & Our Current Understanding

For our dispatchers and route planners, they are creating inefficient routes based on inaccurate ETAs because our system doesn't account for real-world conditions like traffic, weather, or construction. This is critical now because it is the #1 request from our CXT User Group and a major source of customer frustration, wasted fuel, and unreliable service that directly impacts their bottom line.

Evidence: The status of this as the top request from our user group is the primary evidence of its urgency. The cost of inaction is continued operational inefficiency for our customers and a growing perception that our platform lacks a professional-grade routing engine, putting us at a competitive disadvantage.

Target Users & Context

Primary Persona Profile: A Dispatcher or Route Planner for a logistics or field service company. This user operates in a high-pressure environment where time and accuracy are business-critical. They manage numerous routes and drivers simultaneously from a desktop computer and are judged on the efficiency of their operations and the reliability of the ETAs they provide.

Jobs-to-be-Done (JTBD): When I am calculating a route, I want real-time traffic, weather, and construction information to be automatically accounted for, so that I can make intelligent routing decisions and provide accurate ETAs to drivers and customers.

Current Pains & Impact:

  • Pain: "Flying blind" and making decisions based on incomplete, static data.

    • Quote (Representative): "Our ETAs are useless during rush hour or if there's a storm. I have to manually check other apps and guess how much time to add, and my drivers get frustrated when the route is bad."

    • Impact: Inaccurate ETAs lead to customer complaints and damaged trust. Inefficient routes lead to significant costs in wasted fuel and driver overtime.

Current Workarounds: Users must consult external, third-party applications (Google Maps, weather apps, traffic reports) and then manually adjust times and routes within our system, an inefficient and error-prone process.

Secondary Stakeholders:

  • End-Clients: Care about receiving trustworthy and accurate arrival times.

  • Drivers: Care about receiving efficient, reliable routes that minimize their time on the road.

  • Administrators: Care about the ROI of the software and enabling features that improve efficiency.

Key Objectives & Success Metrics

  • Objective 1: Dramatically improve the accuracy and reliability of system-generated ETAs.

    • KR1: Decrease support tickets related to "inaccurate ETAs" by 60% within 6 months of General Availability. (Lagging)

    • KR2: Achieve a "highly accurate" rating from 90% of beta program participants in post-beta surveys. (Leading)

  • Objective 2: Drive adoption of and revenue from our premium routing capabilities.

    • KR1: Achieve a 25% adoption rate for the feature among eligible "Fleet" and "Enterprise" customers within 6 months. (Leading)

    • KR2: Achieve target Monthly Recurring Revenue (MRR) from add-on purchases and tier upgrades attributed to this feature. (Lagging)

    • Instrumentation Plan: We must implement tracking (via Pendo or similar) to measure the number of routes optimized using this new engine.

Hypotheses & Assumptions

Opportunity Hypothesis: We believe that by automatically incorporating real-world data (like traffic, weather, and construction) into our ETA calculations, we will empower dispatchers to create more accurate and efficient routes. This will result in significant operational savings for our customers and will serve as a powerful incentive for them to upgrade to our premium tiers.

Key Risks & Assumptions:

  • Financial Risk: The API costs from third-party data providers, especially for multiple data types, could be volatile and erode the feature's profitability.

    • Mitigation: Conduct a detailed cost-benefit analysis of data providers and build robust API usage monitoring from day one.

  • Technical Risk: Integrating and processing multiple real-time data feeds is complex and could negatively impact application performance.

    • Mitigation: Begin with a technical spike focused on a single data source (e.g., traffic) and performance test before expanding scope.

  • Value Perception Risk: Customers may not perceive the improvement in ETA accuracy as significant enough to justify paying a premium price.

    • Mitigation: Use the beta program to gather testimonials and case studies that quantify time and fuel savings to build a strong value proposition for the marketing launch.

Discovery Partners & Interested Customers

  • Primary Discovery Group: Members of the CXT User Group who voted this as their #1 feature request. (Status: To be contacted).

  • Secondary Discovery Group: Customers who operate in regions with high traffic congestion or variable weather conditions (e.g., Northeast, Pacific Northwest, major metro areas). (Status: To be identified from customer data).

  • Specific Leads: Customers who have previously submitted support tickets or feature requests about inaccurate ETAs. (Status: Awaiting list from Support).

Validation Plan (Next 4-6 Weeks)

(Timeline: July 10, 2025 – August 21, 2025)

Goal: Validate which real-world data source (Traffic, Weather, or Construction) provides the most immediate value to our users and de-risk the financial and technical feasibility of integrating it for an MVP.

Activities:

  1. User Interviews: Conduct interviews with 5-7 dispatchers from the CXT User Group to stack-rank the importance of Traffic vs. Weather vs. Construction data in their daily planning and decision-making. (Owner: Product Manager, ETA: July 24)

  2. Data Provider Analysis: Research and compare the top 2-3 data providers that offer combined or individual data feeds for traffic, weather, and construction. Evaluate their pricing models, data quality, and API documentation. (Owner: Lead Engineer, ETA: Aug 7)

  3. Financial Modeling: Build a preliminary cost model based on sample API pricing and projected usage to determine the financial viability of offering this as a premium feature. (Owner: Product Manager, ETA: Aug 14)

Key Questions to Answer:

  • Which data source is the most critical to include in a Minimum Viable Product (MVP) to solve the core user pain?

  • Is it more feasible to launch with a single data source (e.g., just traffic) or a bundled solution?

  • Which data provider offers the best balance of cost, data quality, and ease of integration for our specific needs?