Introducing ATOM Mobility OpenAPI: Empowering mobility operators with seamless integrations

Fleet operators don’t lose revenue because of lack of demand - they lose it because demand appears in the wrong place at the wrong time. That’s exactly the problem the Unmet demand heatmap solves.

This new analytics layer from ATOM Mobility shows where users actively searched for vehicles but couldn’t find any within reach. Not guesses. Not assumptions. Real, proven demand currently left on the table.

What is the unmet demand heatmap?

The unmet demand heatmap highlights locations where:

• A user opened the app
• Actively searched for available vehicles
• No vehicle was found within the defined search radius

In other words: high-intent users who wanted to ride, but couldn’t. Unlike generic “app open” data, unmet demand is recorded only when a real vehicle search happens, making this one of the most actionable datasets for operators.

Why unmet demand is more valuable than app opens

Many analytics tools track where users open the app (ATOM Mobility provides this data too). That’s useful - but incomplete. Unmet demand answers a much stronger question:
Where did users try to ride and failed? That difference matters.

Unmet demand data is:

✅ Intent-driven (search-based, not passive)

✅ Directly tied to lost revenue

✅ Immediately actionable for rebalancing and expansion

✅ Credible for discussions with cities and partners

How it works

Here’s how the logic is implemented under the hood:

1. Search-based trigger. Unmet demand is recorded only when a user performs a vehicle search. No search = no data point.

2. Distance threshold. If no vehicle is available within 1,000 meters, unmet demand is logged.

• The radius can be customized per operator
• Adaptable for dense cities vs. suburban or rural areas

3. Shared + private fleet support. The feature tracks unmet demand for:

• Shared fleets
• Private / restricted fleets (e.g. corporate, residential, campus)

This gives operators a full picture across all use cases.

4. GPS validation. Data is collected only when:

• GPS is enabled
• Location data is successfully received

This ensures accuracy and avoids noise.

Smart data optimization (no inflated demand)

To prevent multiple searches from the same user artificially inflating demand, the system applies intelligent filtering:

- After a location is stored, a 30-minute cooldown is activated
- If the same user searches again within 30 minutes And within 100 meters of the previous location → the record is skipped
- After 30 minutes, a new record is stored - even if the location is unchanged

Result: clean, realistic demand signals, not spammy heatmaps.

Why this matters for operators

📈 Increase revenue

Unmet demand shows exactly where vehicles are missing allowing you to:

• Rebalance fleets faster
• Expand into proven demand zones
• Reduce failed searches and lost rides

🚚 Smarter rebalancing

Instead of guessing where to move vehicles, teams can prioritize:

• High-intent demand hotspots
• Time-based demand patterns
• Areas with repeated unmet searches

🏙 Stronger city conversations

Unmet demand heatmaps are powerful evidence for:

• Permit negotiations
• Zone expansions
• Infrastructure requests
• Data-backed urban planning discussions

📊 Higher conversion rates

Placing vehicles where users actually search improves:

• Search → ride conversion
• User satisfaction
• Retention over time

Built for real operational use

The new unmet demand heatmap is designed to work alongside other analytics layers, including:

- Popular routes heatmap
- Open app heatmap
- Start & end locations heatmap

Operators can also:

• Toggle zone visibility across heatmaps
• Adjust time periods (performance-optimized)
• Combine insights for strategic fleet planning

From missed demand to competitive advantage

Every unmet search is a signal. Every signal is a potential ride. Every ride is revenue. With the unmet demand heatmap, operators stop guessing and start placing vehicles exactly where demand already exists.

👉 If you want to see how unmet demand can unlock growth for your fleet, book a demo with ATOM Mobility and explore how advanced heatmaps turn data into decisions.

What if ordering a taxi was as easy as booking a room or clicking “Reserve table” on a website?

Meet Web-booker - a lightweight ride-hail booking widget that lets users request a cab directly from a website, without installing or opening the mobile app.
Perfect for hotels, business centers, event venues, airports, and corporate partners.

👉 Live demo: https://app.atommobility.com/taxi-widget

What is Web-booker?

Web-booker is a browser-based ride-hail widget that operators can embed or link to from any website.
The booking happens on the web, but the ride is fully synchronized with the mobile app and operator dashboard.

How it works (simple by design)

‍
No redirects. No app-store friction. No lost users.

• Client places a button or link on their website
• Clicking it opens a new window with the ride-hail widget
• The widget is branded, localized, and connected directly to the operator’s system
• Booking instantly appears in the dashboard and mobile app

Key capabilities operators care about

🎨 Branded & consistent

• Widget color automatically matches the client’s app branding
• Feels like a natural extension of the operator’s ecosystem
• Fully responsive and optimized for mobile browsers, so users can book a ride directly from their phone without installing the app

📱 App growth built in

• QR code and App Store / Google Play links shown directly in the widget
• Smooth upgrade path from web → app

⏱️ Booking flexibility

• Users can request a ride immediately or schedule a ride for a future date and time
• Works the same way across web, mobile browser, and app
• Scheduled bookings are fully synchronized with the operator dashboard and mobile app

🔄 Fully synced ecosystem

• Country code auto-selected based on user location
• Book via web → see the ride in the app (same user credentials)
• Dashboard receives booking data instantly
• Every booking is tagged with Source:
  - App
  - Web (dashboard bookings)
  - Booker (website widget)
  - API

🔐 Clean & secure session handling

• User is logged out automatically when leaving the page
• No persistent browser sessions

💵 Payments logic

• New users: cash only
• Existing users: can choose saved payment methods
• If cash is not enabled → clear message prompts booking via the app

This keeps fraud low while preserving conversion.

✅ Default rollout

• Enabled by default for all ride-hail merchants
• No extra setup required
• Operators decide where and how to use it (hotel partners, landing pages, QR posters, etc.)

Why this matters in practice

Web-booker addresses one of the most common friction points in ride-hailing: users who need a ride now but are not willing to download an app first. By allowing bookings directly from a website, operators can capture high-intent demand at the exact moment it occurs - whether that is on a hotel website, an event page, or a partner landing page.

At the same time, Web-booker makes partnerships with hotels and venues significantly easier. Instead of complex integrations or manual ordering flows, partners can simply place a button or link and immediately enable ride ordering for their guests. Importantly, this approach does not block long-term app growth. The booking flow still promotes the mobile app through QR codes and store links, allowing operators to convert web users into app users over time - without forcing the install upfront.

Web-booker is not designed to replace the mobile app. It extends the acquisition funnel by adding a low-friction entry point, while keeping all bookings fully synchronized with the operator’s app and dashboard.

👉 Try the demo
https://app.atommobility.com/taxi-widget

Want to explore a ride-hail or taxi solution for your business - or migrate to a more flexible platform? Visit: https://www.atommobility.com/products/ride-hailing