Looking for a Driver? Search by Time and Need

Looking for a driver begins with more than a starting point and destination. The useful request is usually: “I need a driver to take two people to the airport at 5.30 tomorrow morning, with room for three suitcases, and I need to know whether waiting is included.” An intent-based platform should understand those practical constraints before presenting possible matches.

This is where an iMarketplace differs from a conventional transport category. Instead of asking the user to translate the journey into a succession of filters, it treats the complete sentence as an intention and asks only the questions needed to make it actionable.

The term iMarketplace is not yet an industry standard. It is a category WEVONE is proposing for marketplaces built around Intelligence, Intention, Interaction and Individualisation, with native AI and several everyday universes in one experience.

What does “I am looking for a driver” actually mean?

The word “driver” can conceal several distinct needs. A person may want an immediate ride across town, a scheduled airport transfer, transport to a medical appointment, a driver who waits during a meeting, a return journey after an event or help moving an item that will not fit in a car.

A useful platform must therefore understand intent instead of relying only on keywords. The relevant details may include:

the collection and destination addresses;
the required date and collection time;
whether the time is fixed or flexible;
the number of passengers;
luggage or equipment requirements;
accessibility needs;
whether a child seat is required;
one-way, return or waiting arrangements;
the type of vehicle needed;
the acceptable price range;
whether the journey is urgent, recurring or planned in advance.

A search for “driver airport” identifies a broad subject. A request such as “I need a driver for four people from central Bristol to the airport at 4.45 on Monday, with four large cases” expresses a usable intention.

How conversational search can clarify the journey

In a conversational marketplace, the first request does not have to contain every detail. The system can detect what is missing and ask a focused follow-up question.

For example:

“I need a driver to the airport tomorrow.”

The assistant might ask:

“What time must you arrive, how many people are travelling, and how much luggage will you have?”

This is the practical value of conversational search. The dialogue is not merely a chatbot placed beside a traditional search bar. It is part of how the platform structures the request, identifies constraints and decides which offers may be relevant.

Illustration: an early airport journey

Suppose a traveller needs a driver to the airport at 5.00 in the morning. The airport is 45 minutes away in normal traffic, but check-in closes at 6.15. Two passengers are travelling with three suitcases, and one passenger cannot easily climb into a high vehicle.

A basic search might show nearby drivers or transport listings. Intent-based search should recognise that punctuality, luggage space and vehicle accessibility matter more than simple distance. It may also clarify whether 5.00 is the desired collection time or airport arrival time, a small distinction with significant consequences.

Illustration: a driver who waits and returns

Another user may need transport to a hospital appointment. The driver must collect the passenger at 10.00, wait for up to 90 minutes and make the return journey. Treating this as two unrelated rides could obscure the real requirement. The intention is a single assisted round trip with uncertain waiting time.

These details also distinguish a private ride request from looking for a carpool, where the passenger may be joining a journey that a driver already plans to make.

From category selection to intent-based matching

Traditional marketplaces and ride platforms have genuine strengths. Established services may offer large driver networks, familiar interfaces, rapid availability, payment tooling, route estimates and accumulated trust signals. Their scale can be particularly valuable when someone needs a ride immediately.

Their structural limits usually reflect their focus and design era rather than a lack of capability. A specialist ride service is generally optimised for moving passengers from one point to another. It may not be designed to connect that journey with accommodation, an event, a local task or the delivery of an object.

An iMarketplace takes a different approach. It starts with the broader intention and can consider several universes within the same journey. In the proposed model, the AI is native to the architecture rather than added later as a separate feature.

| Approach | Starting point | Typical interaction | Best suited to | |---|---|---|---| | Specialist ride platform | Route and vehicle availability | Location, destination and booking controls | Fast, familiar passenger transport | | Classified listing | Transport category | Browse, filter and contact | Comparing independent local offers | | Carpool platform | A journey already planned | Match passengers with available seats | Shared travel on compatible routes | | iMarketplace | The user’s complete intention | Natural-language request plus clarification | Journeys connected with other needs and constraints |

Fees, eligibility, insurance requirements and service terms vary by platform and can change. Users and drivers should check each service directly before making arrangements.

Why several universes matter

Transport rarely exists in isolation. A journey may be part of a weekend away, a house move, an event or a commercial task. The purpose of a multi-universe platform is not to assemble unrelated features into a super-app; it is to preserve the connection between needs that belong to the same intention.

Someone planning a weekend might need a Friday evening driver, a short-term place to stay and tickets for a local event. Someone moving house might need a van, lifting help, temporary storage and a person to transport a fragile object. These are separate marketplace categories, but they are one lived project for the user.

The same distinction applies to passengers and objects. If the requirement is to send a suitcase five kilometres across town while its owner remains at home, the relevant intention may be having a parcel delivered, not booking a passenger ride. A conversational system can identify that difference before presenting unsuitable results.

This broader structure is explored through the mobility universe, which can include rides, shared journeys, vehicle-related offers and local delivery needs.

What an AI assistant marketplace should do

An AI assistant marketplace should reduce ambiguity without taking decisions away from the user. For a driver request, it may:

extract the route, time and passenger count from ordinary language;
identify missing operational details;
distinguish fixed requirements from preferences;
search within the relevant map area;
explain why particular matches appear relevant;
connect related needs where appropriate;
retain enough context to avoid making the user repeat information.

Individualisation does not mean making unexplained decisions on someone’s behalf. A family travelling with a baby, a person using a folding wheelchair and a traveller carrying a bicycle may take the same route but require very different matches. The platform should make those differences visible and controllable.

This is also why one account for many needs can be useful: the user can move between transport, services, events and goods without treating each part of a project as an unrelated search.

WEVONE as a current illustration

WEVONE is one concrete, early illustration of the iMarketplace concept, not evidence that the category has already prevailed. Public since 2026, it is a young platform with a few hundred registered members and is far smaller than established marketplaces such as Vinted, Leboncoin, eBay or Facebook Marketplace. Its available local supply, including transport offers, therefore depends heavily on location.

Available today, WEVONE brings several universes into one app: Tutus for second-hand goods and fashion, Nest for housing and space rental, Mission for services and local gigs, Events, and Pilote for transport and parcel delivery. Its built-in AI, Mia, supports natural-language search, listing assistance, photo moderation and cross-universe recommendations. Local discovery is map-based and follows the area the user is viewing.

For a driver request, this means the user can express the journey conversationally and search within Pilote while retaining the broader context of related needs. It does not mean that a suitable driver will always be available. Matching depends on local participation, timing, vehicle suitability and the willingness of both parties to agree terms.

Drivers may also use the platform to offer journeys or transport-related services under the broader idea “Earn from every action”. Income is never guaranteed and depends on demand, location, availability, pricing and the nature of the offer.

Safety and booking checks

AI can help organise a request, but it cannot replace sensible checks. Before confirming a journey, passengers and drivers should establish:

the identities of the parties involved;
whether the driver and vehicle meet applicable legal, licensing and insurance requirements;
the complete price and what it includes;
collection and destination details;
waiting, delay and cancellation arrangements;
luggage, accessibility and child-seat requirements;
the method of communication if plans change;
whether payment and messaging remain within the platform.

For higher-risk or regulated journeys, platform moderation should complement rather than replace documentary verification and human review. A relevant match is not automatically a safe or legally compliant match.

Conclusion

Finding a driver is best treated as an intention with a route, moment, purpose and set of constraints. Intent-based search allows a person to describe the real journey in ordinary language, while a conversational interface can clarify luggage, timing, accessibility, waiting and return arrangements.

Established transport platforms remain valuable for their scale, liquidity and familiar booking processes. An iMarketplace takes a different approach: it is designed around native AI, dialogue and connected universes, which may suit users whose transport request forms part of a wider everyday project.

FAQ

What information should I provide when looking for a driver?

Give the collection point, destination, date, required time, passenger count and luggage details. Add any accessibility, child-seat, waiting or return requirements.

Is looking for a driver the same as requesting a carpool?

Not necessarily. A driver request may involve a dedicated journey, while carpooling usually matches a passenger with a route someone already intends to travel.

Can an AI marketplace guarantee that a driver is available?

No. AI can interpret and match the request, but availability depends on local supply, timing, vehicle suitability and the parties’ agreement.

Should I enter a collection time or an arrival time?

State which one you mean. If arrival is critical, provide the required arrival time so the driver or platform can allow for travel and contingency time.

Can I ask for a driver to wait and bring me back?

Yes, but describe it as one round trip and specify the likely waiting period. Confirm how waiting time and delays affect the final price.

Is an iMarketplace a ride-hailing app?

Not by definition. As defined here, an iMarketplace is an intent-based, conversational and multi-universe platform. Transport can be one universe within it, alongside goods, services, housing, events and other needs.

I Am Looking for a Driver for a Specific Journey