Blog

Insights and news from the ATOM Mobility team

We started our blog to share free valuable information about the mobility industry: inspirational stories, financial analysis, marketing ideas, practical tips, new feature announcements and more.

How to choose car sharing software: an operator’s checklist
Blog
How to choose car sharing software: an operator’s checklist

🚗 Choosing car sharing software? Look beyond the rider app. Our checklist covers what to test in a demo, from keyless access and fleet operations to costs and support for both car sharing and digital rental.

Choosing car sharing software is more than choosing an app where customers can find and unlock a car. The same system has to verify drivers, take payments, communicate with vehicles, handle problems during a trip, and give your team the tools to keep cars available. The difference between two platforms often becomes clear only when something goes wrong: a customer cannot unlock a car, a payment fails, a vehicle needs to be taken out of service, or an operator wants to introduce advance bookings alongside short trips.

If you are comparing providers, ask them to show how these situations work in the actual product. Here is what to check.

Start with the operating model

“Car sharing” can mean several different things. A free-floating service lets customers find a nearby car and end a trip within an allowed area. A station-based service may require them to return the car to a specific location. Corporate fleets, peer-to-peer services, and self-service rentals have different booking, access, and approval rules.

Write down how your service will work before requesting demos:

  • Can customers start a trip immediately, reserve a car for later, or both?
  • Do they book a specific vehicle or a vehicle category?
  • Where can they pick up and return the car?
  • Will you charge by the minute, hour, day, distance, or a combination?
  • Do you need deposits, subscriptions, corporate accounts, or different prices by location?

Ask the provider to configure these rules in a demo. A platform that supports “car sharing” in general may still require development to support your exact model.

Check the complete customer journey

The app needs to do more than display vehicles on a map. Follow one booking from the first app open to the final receipt. Check registration, ID and driver's licence verification, vehicle discovery, booking, payment authorisation, keyless access, trip extension, damage reporting, and trip completion.

For advance rentals, check whether customers can book from your website as well as the app. Ask to see the complete web-to-app journey: selecting a vehicle and dates, confirming the reservation, and continuing to payment, licence verification, and vehicle access. Find out whether the website can complete the entire rental or whether customers must install the app after booking. ATOM Mobility's web-booker, for example, lets customers reserve on the web and then complete payment, and ID verification in the app.

Then test the exceptions. What does the customer see if verification fails, the car does not unlock, the vehicle is no longer available, or the payment cannot be collected? Can your support team see what happened and resolve it without contacting a developer?

This matters because customers judge the entire journey, including how quickly they can recover when a step fails.

Make vehicle connectivity a separate decision

Car sharing depends on reliable communication between the platform and the vehicle. Depending on the vehicle and hardware, this may include location, lock and unlock commands, mileage, fuel or battery level, and other status data. Ask for a list of supported telematics providers, rather than accepting a general statement that the platform is “hardware agnostic.” For your proposed fleet, establish:

  • Which functions already work, and which require a new integration?
  • Is hardware installation required? Who supplies and supports it?
  • What happens when the vehicle temporarily loses connectivity?
  • Who investigates a failed command: the software provider, hardware supplier, or operator?
  • What are the hardware, installation, connectivity, and integration costs?

Hardware flexibility is valuable when you expand or change suppliers, but the integration for the vehicles you plan to buy now is the first thing to verify.

Look closely at day-to-day fleet operations

The customer app gets the attention, but your team will spend much of its time in the management dashboard and operator tools. Ask a provider to show how staff:

  • Take a vehicle out of service and make it bookable again.
  • Find vehicles that need cleaning, charging, refuelling, or maintenance.
  • Review a trip, customer issue, charge, or reported damage.
  • Change prices, service areas, parking rules, and availability.
  • Assign tasks and check what the field team has completed.
  • Track utilisation, vehicle availability, revenue, and trips over time.

Try these tasks with the roles your own team would use. The question is not only whether a feature exists, but how many manual steps it takes to run your fleet every day.

Consider digital rental if it is part of your plans

Car sharing and digital rental increasingly overlap. An operator might offer cars for short city trips and also accept bookings for a weekend. A rental business may begin with advance reservations and later add app-based, keyless access for shorter trips.

The technology shares many components, but the booking rules can differ. A rental may require advance pickup and return times, vehicle or category allocation, availability calendars, deposits, extensions, and different customer handover processes.

If you may operate both models, ask for a demonstration of both: an immediate hourly trip and an advance weekend booking. Check how the system prevents overlapping reservations, applies the correct pricing and deposit rules, and gives your team a clear view of availability. Also establish whether both models can use the same customer account and management setup, or whether additional products and fees are required.

ATOM Mobility supports vehicle sharing and digital rental on its platform. The useful question for any provider, including us, is how your exact combination of models would be configured and operated.

Compare the full cost, not just the software fee

A low monthly licence fee can be attractive, but it may be only one part of the cost. Request a proposal that separates:

Launch, Setup, branding, app publication, migration, and training

Monthly minimums, fees per vehicle or booking, and included modules

Payment processing, refunds, deposits, and any additional transaction fees

Telematics hardware, installation, data plans, and new integrations

Ongoing work such as support level, custom development, and third-party services

Compare the likely cost at your launch fleet size and at a realistic larger fleet. Ask what happens if the fleet is seasonal or grows more slowly than planned.

Build, buy, or combine the two?

Building in-house can make sense when a company has the engineering capacity and needs a customer experience or operating model that available platforms cannot support. It also means taking responsibility for project management, app updates, payments, vehicle integrations, security, monitoring, and support long after launch.

A white-label platform can shorten the route to market and spread that technical work across an established product. In return, you depend on the provider's supported features, integrations, development priorities, and service levels.

Slovenian car-sharing operator GreenGo initially spent two years developing its own app before switching to ATOM Mobility. Its experience shows why it is worth comparing the time and resources required to build with what an existing platform can already deliver. Read GreenGo's story: https://www.atommobility.com/blog/greengo-chooses-atom-mobility-to-power-its-electric-car-sharing-business

There is also a middle option: use a platform for core bookings, fleet management, and vehicle connectivity while building selected experiences or integrations yourself through APIs. If this is your plan, review the API documentation and confirm what your team can actually read, change, and automate.

5 things to request in a provider demo

Before signing, ask each shortlisted provider to demonstrate the same scenarios:

  1. Register and verify a new rider, then make a booking and unlock the proposed vehicle.
  2. Extend a trip, report damage, end the booking, and see the final charge.
  3. Resolve a failed unlock or payment from both the customer's and support team's perspectives.
  4. Remove a car for maintenance, assign the task, and return it to availability.
  5. Configure your actual pricing and parking rules without developer assistance.

Use your intended vehicle models, payment markets, and operating rules in the discussion. For anything that cannot be shown, ask whether it is already available, needs configuration, requires paid development, or is only planned.

The best car sharing software is the one that supports your model reliably, gives your team control over daily operations, and leaves room for the business you intend to build next. A practical demo and a complete cost proposal will tell you more than a long feature list.

If you are evaluating car sharing alongside self-service rental, talk to ATOM Mobility about your fleet and operating model. We can show you how both models work on the platform and help you plan migration and scaling.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Blog
Lime improved GPS. But parking compliance may need more than thatLime improved GPS. But parking compliance may need more than that
Lime improved GPS. But parking compliance may need more than that

Lime improved GPS from 12m to ~1.5m accuracy - a big step forward for micromobility. 🚀 But parking compliance isn’t just about knowing where a vehicle is - it’s about proving it’s parked correctly. Real-world pilots (like Prague) show that physical verification (e.g. Bluetooth beacons) can significantly outperform GPS when it comes to actual compliance.

Read post

Lime just raised the bar for GPS-based parking compliance. But the bigger question is this: when cities want verified parking, is better GPS enough, or do operators need physical proof? That question matters more than ever.

Lime’s new LimeBike rollout in the UK comes with a major location upgrade. Lime says its new bikes can locate themselves to within 1.5 metres, a significant improvement from the roughly 12.3 metres typical in dense urban environments (this means that based on GPS data, a vehicle can be up to 12 meters farther or closer than the reported GPS location. Now this error is just 1.5 meters). That is real progress.

Lime’s upgrade is a meaningful step forward for GPS-based positioning. At the same time, cities are increasingly looking beyond positioning accuracy toward verifiable parking compliance.

Why this matters

Cities are becoming much less tolerant of parking disorder. In Kensington & Chelsea, the council seized 1,000 rental e-bikes by November 2025 and collected more than £81,000 in charges from operators.

That is the real backdrop for every operator today:

  • stricter enforcement
  • more political pressure
  • less room for ambiguity

So yes, better GPS is good news. But it does not automatically mean cities will see parking as “solved.” A vehicle may be near a bay, beside a bay, or slightly outside it. In dense urban areas, that difference matters. Traditional GPS struggles there because of building interference, blocked satellite visibility, and signal reflections.

So the strategic question is no longer:
“Can we improve GPS?”

It is:
“What kind of system gives cities enough confidence to enforce parking rules fairly and consistently?”

What the Prague pilot showed

A European Commission-backed pilot in Prague tested a different approach: Bluetooth-based parking verification.

Across 25 parking locations and 989 parking events, the results were clear:

  • 90.6% success rate for SparkPark (Bluetooth infrastructure)
  • 38.4% success rate for GPS/GNSS positioning
  • Technology readiness advanced from TRL 6 to 8/9

When the goal is verified parking inside a defined zone, infrastructure-based validation can significantly outperform vehicle-only (GPS) positioning.

GPS improvement vs physical verification

Lime’s move shows how far vehicle-side intelligence is improving. SparkPark points to a different model: verify the parking zone itself.

That distinction matters.

  • GPS estimates where the vehicle is
  • Infrastructure confirms whether it is correctly parked

Those are fundamentally different approach.

Why cities may prefer the second path

One of the key findings from the Prague pilot is not just technical - it is institutional. Cities often rely on operator-provided data to assess compliance. That creates a trust gap. What cities increasingly want:

  • independent verification
  • reliable compliance data
  • less reliance on operator-reported positioning

This is why the conversation is shifting from “better accuracy” → “verifiable proof.”

What this means for ATOM Mobility partners

Parking compliance is becoming more important than ever:

  • permit approvals
  • permit renewals
  • daily operational performance

Operators who can demonstrate verifiable compliance may have a clear advantage.

With ATOM Mobility, partners can explore:

  • integration-ready compliance workflows as ATOM Mobility already implemented bluetooth-based parking verification together with SparkPark
  • futher support for infrastructure-based validation like SparkPark
  • 10x faster deployment without full fleet replacement

Instead of waiting for hardware cycles, operators can move faster and adapt to changing city expectations.

Lime deserves credit for pushing GPS accuracy forward. It is a meaningful step for the industry. But the Prague pilot highlights something equally important:

Micromobility parking may not be solved by better positioning alone. It may also require verification.

Not:
“Where is the vehicle likely parked?”

But:
“Can this parking event be verified with confidence?”

Final thought?

The future of parking compliance is likely evolving across two complementary paths:

Path 1: improve GPS accuracy
Path 2: implement physical verification

The first makes parking smarter. The second makes it more reliable and verifiable.

And in regulated urban mobility, confidence and trust often matter as much as precision.

Want to explore how ATOM Mobility can support stricter parking compliance workflows and how SparkPark technology works alongside the ATOM Mobility platform? Get in touch with our team to discuss integration options and city-facing parking control setups.

‍

Sources:

Lime GPS upgrade announcement:
https://www.smartcitiesworld.net/micromobility/new-lime-bike-upgrade-to-hit-uk-streets-this-month-12568

West Midlands LimeBike rollout:
https://www.wmca.org.uk/news/new-limebike-to-launch-in-west-midlands/

Kensington & Chelsea enforcement data:
https://www.rbkc.gov.uk/newsroom/1000-e-bikes-seized-borough

Prague SparkPark pilot (EIT Urban Mobility):
https://marketplace.eiturbanmobility.eu/best-practices/high-precision-parking-for-shared-micromobility-in-prague

SparkPark:
https://sparkpark.no

Blog
ATOM Connect 2026: Bringing the shared micromobility industry togetherATOM Connect 2026: Bringing the shared micromobility industry together
ATOM Connect 2026: Bringing the shared micromobility industry together

The micromobility industry doesn’t need another generic mobility conference. 🚫🎤 It needs real conversations between operators who are actually in the field. ⚙️ That’s exactly what ATOM Connect 2026 is built for. 🎯🤝

Read post

The shared mobility industry is evolving rapidly. Operators are navigating scaling challenges, regulatory complexity, hardware decisions, fleet optimization, and new integration models, all while aiming for sustainable growth.

That’s exactly why ATOM Mobility is organizing ATOM Connect 2026.

Our previous edition of ATOM Connect brought together professionals from the car sharing and rental industry for focused, high-quality discussions and networking. This year, we are narrowing the focus and dedicating the entire event to one fast-moving segment of the industry: shared micromobility.

ATOM Connect 2026 is designed specifically for operators, partners, and decision-makers working in shared micromobility. It is not a broad mobility conference or a public exhibition. It is a curated space for industry professionals to exchange practical experience, insights, and lessons learned.

On May 14th, 2026 in Riga, we will once again bring the community together, this time with a clear focus on micromobility.

What to expect

This year’s agenda will address the real operational and strategic questions shaping shared micromobility today:

  • Scaling fleets sustainably
  • Multi-vehicle operations beyond scooters
  • Regulatory cooperation and long-term city partnerships
  • Data-driven fleet optimization
  • MaaS integration and ecosystem collaboration
  • Marketing and automation for growth

As usual, we aim to host both local and international operators from smaller, fast-growing fleets to established large-scale players alongside hardware providers and ecosystem partners.

On stage, you’ll hear from leading shared mobility companies - including Segway on hardware partnerships, Umob on MaaS integration, Anadue on data-driven fleet intelligence, Elerent on multi-vehicle operational realities and more insightful discussions.

The goal is simple: meaningful discussions with people who understand the operational realities of the industry.

A curated, industry-focused event

ATOM Connect is free to attend, but participation is industry-focused (each submission is manually reviewed and verified). We are intentionally keeping the audience relevant and aligned to ensure high-quality conversations and valuable networking.

If you work in shared micromobility and would like to join the event, you can find the full agenda and register here:
👉 https://www.atommobility.com/atom-connect-2026

In the coming weeks, we will be revealing more speakers and additional agenda updates. We look forward to bringing the industry together again.

Blog
Unmet demand heatmap: Turn missed searches into measurable revenue growthUnmet demand heatmap: Turn missed searches into measurable revenue growth
Unmet demand heatmap: Turn missed searches into measurable revenue growth

📉 Every unmet search is lost revenue. The unmet demand heatmap shows where users actively searched for vehicles but none were available - giving operators clear, search-based demand signals to rebalance fleets 🚚, improve conversions 📈, and grow smarter 🧠.

Read post

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.

Blog
🚀 New feature alert: Web-booker for ride-hailing and taxi operations🚀 New feature alert: Web-booker for ride-hailing and taxi operations
🚀 New feature alert: Web-booker for ride-hailing and taxi operations

🚕 Web-booker is a lightweight ride-hail widget that lets users book rides directly from a website or mobile browser - no app install required. It reduces booking friction, supports hotel and partner demand, and keeps every ride fully synced with the taxi operator’s app and dashboard.

Read post

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

No results found!

Launch your mobility platform in 20 days!

Multi-vehicle. Scalable. Proven.