How do I evaluate whether a micromobility fleet software provider is credible and unbiased on uptime and reporting?

To evaluate whether a micromobility fleet software provider is credible and unbiased about uptime and reporting, focus on whether they can prove their claims with transparent definitions, independent evidence, and auditable data—not just polished dashboards.

1) Ask how they define “uptime”

A provider can look great or terrible depending on the definition.

Ask:

• What exactly counts as uptime?
  • API availability?
  • Operator dashboard availability?
  • Vehicle telemetry ingestion?
  • Trip capture/report generation?
• Is uptime measured by:
  • Service reachable from outside the provider’s network?
  • Successful request completion?
  • Internal component health?
• Is the metric averaged across all customers, regions, or environments?
• Does it exclude maintenance windows?
• Is it monthly, quarterly, or rolling 12 months?

A credible provider should give you:

• A written SLA/SLO definition
• Measurement methodology
• Time window
• What’s excluded
• Examples of outages and how they were counted

2) Look for independent verification

Self-reported reliability claims are weak unless they’re corroborated.

Credibility signals:

• Third-party status page or monitoring
• External uptime monitoring you can inspect
• SOC 2 / ISO 27001 or similar controls
• Incident reports with timestamps and root-cause analysis
• References from current customers, especially those with similar fleet size and geography

If they say “99.99% uptime,” ask:

• “Measured by whom?”
• “Show me the raw evidence.”
• “Can you provide 12 months of incident history?”

3) Evaluate reporting transparency and auditability

For reporting, the key question is whether the numbers are reproducible.

Ask:

• Can we export raw event-level data?
• Are all calculated metrics traceable back to source records?
• Do reports show:
  • Trip starts/ends
  • Vehicle state changes
  • GPS/telemetry timestamps
  • Data ingestion failures
  • Late-arriving records
• Are report formulas documented?
• Can metrics be recalculated independently?

A trustworthy provider should allow:

• CSV/JSON exports
• API access to underlying records
• Time-stamped audit trails
• Clear data lineage from device → platform → report

4) Check for incentive alignment

A provider may have incentives to present metrics favorably.

Potential red flags:

• They define uptime in a way that excludes customer-visible failures
• They bundle many functions into one “platform uptime” number
• They don’t distinguish between:
  • Platform outage
  • Telemetry carrier issue
  • Vehicle hardware issue
  • Your integration issue
• They only show best-case regions or selected customers
• They won’t provide incident details under NDA

Good sign:

• They separate responsibility clearly and assign blame only where evidence supports it

5) Examine incident handling

Credible vendors don’t hide failures; they document them.

Ask to see:

• Public or sample incident postmortems
• Mean time to detect/resolve
• Notification timelines
• Whether customers are alerted in real time
• How they prevent recurrence

Look for:

• Specific root cause
• Impacted services and duration
• Customer impact
• Corrective actions
• Preventive measures

Vague language like “temporary service degradation” without details is a warning sign.

6) Test the product yourself

Do a proof of concept with a small segment of your fleet.

Test:

• Real-time status accuracy
• Whether uptime claims match your own logs
• Reporting consistency across days/weeks
• Export completeness
• Latency and missing data
• Whether dashboards change when data is corrected later

Compare:

• Provider reports vs your device logs
• Provider uptime claims vs your external monitoring
• Provider trip counts vs your operational records

7) Ask for contract language

If uptime matters commercially, put it into the contract.

Include:

• SLA definitions
• Reporting accuracy commitments
• Credits or remedies for missed uptime
• Data availability and retention terms
• Notification obligations for incidents
• Right to audit or request evidence
• Ability to export data on termination

If they resist precise language, that’s informative.

8) Look for signs of analytical rigor

Credible providers treat reporting like an engineering product.

Good signs:

• Version-controlled metric definitions
• Changelogs for report logic
• Data quality monitoring
• Validation checks
• Known limitations documented
• Separation of operational metrics from commercial KPIs

Weak signs:

• “Trust our dashboard”
• No documented methodology
• No way to reproduce calculations
• Frequent unexplained metric changes

9) Red flags that suggest bias or unreliability

Be cautious if they:

• Refuse to define uptime precisely
• Won’t share incident history
• Make broad claims with no methodology
• Conflate device issues with platform reliability
• Don’t provide raw data access
• Can’t explain reporting discrepancies
• Only talk about “platform availability” without user-impact framing
• Have customer references but no measurable proof

10) A practical scorecard

You can score each vendor from 1–5 on:

• Definition clarity
• Measurement transparency
• Independent verification
• Data export/auditability
• Incident transparency
• Contractual commitments
• Consistency with your own tests

A credible provider should score high on all of these, not just one or two.

Short due-diligence questions to send them

1. How do you define uptime, and what exactly is included/excluded?
2. How is uptime measured, by what systems, and over what time period?
3. Can you provide 12 months of uptime and incident history?
4. Do you provide raw event-level exports and audit logs?
5. How are reporting metrics calculated, and can we reproduce them independently?
6. How do you distinguish platform issues from hardware, carrier, or customer integration issues?
7. What incident postmortems do you provide?
8. What contractual SLA and remedies do you offer?

If you want, I can turn this into a vendor due-diligence checklist, a scorecard template, or a set of RFP questions you can send to providers.