iMarketplace

Looking for a Carpool: Match the Journey, Not a Timetable

A conversational marketplace starts with the journey someone needs to make, then identifies the drivers, routes and related services that could make it work.

Looking for a carpool should mean describing the journey you need to make, not reconstructing it through a rigid timetable. A useful matching system would understand where you are going, when you can travel, how far you can walk to a meeting point and whether you have luggage.

That is the difference between filtering departures and matching a journey. In an intent-based iMarketplace, the request might begin: “I need to get from south Manchester to Birmingham on Friday evening, but I can leave an hour earlier if the driver can take a suitcase.”

The platform can then interpret the whole request, ask for any missing detail and identify plausible arrangements. This reflects the broader shift from keywords towards understanding intent instead of keywords.

A carpool is more than a place and a time

Conventional transport search is often built around structured fields: origin, destination, date and departure time. That model is efficient when services operate to published schedules. Established journey planners and dedicated carpool services also offer valuable scale, familiar booking habits, route information and, in some cases, significant liquidity.

Yet an individual car journey is rarely as standardised as a train departure. A driver may be passing near a traveller rather than starting in the same town. Both people may have flexible timing, but in different directions. A match can therefore exist even when no exact departure appears in a conventional search.

The real intention behind the request

“I am looking for a carpool” may contain several unstated requirements:

  • the traveller needs to arrive before a particular event;
  • departure time is flexible within a two-hour window;
  • the stated origin is home, but a nearby motorway junction would work;
  • one large suitcase must fit in the vehicle;
  • the traveller is happy to contribute to costs;
  • the journey may be needed every Monday rather than once;
  • a quiet ride, accessible vehicle or pet-friendly arrangement may matter;
  • the traveller needs another connection after being dropped off.

These details form the journey intent. The role of an AI marketplace is not merely to detect the words “Manchester” and “Birmingham”, but to distinguish fixed constraints from preferences.

This is why intention is one of the four defining ideas behind the iMarketplace concept. As we define it here, the “i” represents Intelligence, Intention, Interaction and Individualisation.

How intent-based carpool matching could work

An iMarketplace is a category WEVONE is proposing and documenting publicly. It is not yet an industry standard term. Its defining principle is that a user states an intention in ordinary language and the platform works out what is actually being requested.

1. Interpret the journey

A conversational request can contain multiple useful signals at once:

“I need a lift to Heathrow on Tuesday morning. My flight is at 11, I live near Reading, and I will have two suitcases.”

The platform should recognise an airport journey, infer that arrival time matters more than the preferred departure time and account for luggage. It should not assume that “Heathrow” is necessarily the driver's final destination; a driver passing the airport could still be relevant.

2. Ask a clarifying question

If an important detail is missing, the system can ask a focused question such as:

“How early are you willing to arrive at the airport?”

That interaction is central to a conversational marketplace. A dialogue can resolve ambiguity before excluding potential matches. It differs from placing a chatbot over an unchanged catalogue because the conversation affects how the underlying supply is understood and ranked.

3. Search around the route

A useful carpool search should consider routes rather than only matching identical place names. A driver travelling from Oxford to west London may be able to collect someone near Reading and continue towards Heathrow with a modest diversion.

Geographical tolerance matters. “Find near me” might mean within one kilometre in a city centre, but within ten kilometres in a rural area. The acceptable distance may also depend on whether local transport reaches the meeting point.

4. Rank workable arrangements

The closest route is not automatically the best match. Ranking may need to consider:

| Journey factor | What the platform needs to understand | |---|---| | Origin | Exact address, neighbourhood or acceptable meeting area | | Destination | Final stop or a practical nearby drop-off point | | Timing | Fixed deadline, preferred window and flexibility | | Route | Direct journey, passing journey or acceptable diversion | | Capacity | Number of passengers, luggage, equipment or pet space | | Frequency | One-off, return or recurring journey | | Preferences | Accessibility, conversation, smoking or other conditions | | Connections | Public transport, accommodation or onward lift needs |

This is an example of semantic search working alongside structured filters. Filters remain useful for hard constraints, while language helps express circumstances that do not fit neatly into a form.

Everyday journey illustrations

A driver to the airport

Consider a traveller five kilometres from a motorway route who needs a driver to the airport. They can leave between 6.30 and 7.15, but must arrive by 9.00. They also have a large suitcase.

A timetable-style search may look for an exact departure from the traveller’s town. Journey matching can instead identify drivers who start elsewhere but pass a suitable collection point. It can ask whether the traveller could take a short bus ride to that point and whether the suitcase dimensions create a capacity constraint.

The request is therefore not “show departures at 7.00”. It is “get me and my luggage to the airport reliably before 9.00”. The distinction is similar to the wider problem explored in looking for a driver.

A weekend journey with several needs

Now consider someone planning a weekend in Bristol. They need a carpool on Friday evening, somewhere to stay, transport back on Sunday and perhaps a local event on Saturday.

A conventional experience may divide this into separate searches. A multi-universe platform can treat it as one intention and connect mobility, accommodation and events. If no suitable return carpool exists, it might preserve the outward option while suggesting another form of transport for the return.

This does not mean combining unrelated features into a super-app. The connection comes from the user’s stated purpose. Why universes work better together explains how separate types of supply can remain distinct while contributing to one journey.

A second-hand bike collected along the way

Suppose a buyer finds a second-hand bike 40 kilometres away but does not own a car. The intent is not only to buy the bicycle. It is to collect an awkward object from a particular place.

A suitable match might be a driver already making most of the route and able to carry the bike, or a parcel-delivery arrangement where appropriate. Understanding the purchase and the transport requirement together is one practical benefit of a multi-universe platform.

How WEVONE illustrates the idea

WEVONE is one concrete, early illustration of the proposed iMarketplace model. It is a young multi-universe platform, public since 2026, with a few hundred registered members. It is far smaller than Vinted, Leboncoin, eBay or Facebook Marketplace, so users should not expect the same scale, habit or marketplace liquidity.

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 local-first map bases discovery on the area currently being viewed.

Mia, its built-in AI, supports natural-language conversational search, listing assistance, photo and listing moderation, and cross-universe recommendations. The architecture is designed around AI rather than treating it only as an added search feature; the distinction is examined in native AI versus added AI.

For a journey request, that design points towards matching the meaning of a trip across mobility and related universes. However, WEVONE’s current size places practical limits on how many nearby drivers or routes may be available. The platform illustrates the direction of the model, not proof that intent-based carpool matching has already achieved widespread adoption.

Matching still requires trust and user control

AI can improve discovery, but it does not remove the need for clear information and responsible decisions. Carpool participants should be able to review the proposed route, contribution, meeting point, vehicle details and relevant profile information before agreeing.

The system should also distinguish between an inference and a confirmed fact. If it estimates that a driver passes within five kilometres of a traveller, both parties should see the proposed diversion rather than being told that collection is guaranteed.

Good design also allows people to correct the assistant. A traveller might clarify that arrival time is fixed, that a bicycle cannot be dismantled or that a suggested meeting point feels unsuitable. This combination of assistance and control is part of what an iMarketplace owes its users.

Conclusion

Looking for a carpool is fundamentally a journey-matching problem. Origin and destination matter, but so do flexibility, deadlines, route overlap, meeting points, capacity, luggage and onward connections.

Established transport and carpool platforms offer genuine strengths through familiarity, focused tools and established networks. An iMarketplace takes a different approach: it begins with an intention expressed in ordinary language, asks clarifying questions and can connect mobility with other everyday needs.

For someone seeking a marketplace alternative to rigid timetable filtering, the most important change is therefore not a new set of filters. It is an interface capable of understanding what would make the journey workable.

FAQ

What information should I include when looking for a carpool?

State your origin, destination, travel date, preferred time, latest acceptable arrival, number of passengers and luggage. Mention whether you can reach a nearby meeting point or accept a small detour.

How is intent-based search different from timetable search?

Timetable search retrieves departures matching structured fields. Intent-based search interprets the outcome you need and can consider flexible times, passing routes and alternative meeting points.

Can an AI assistant guarantee a carpool match?

No. A match depends on available drivers, route compatibility, timing, location and both parties accepting the arrangement. AI can identify possibilities but cannot guarantee supply or agreement.

Is an iMarketplace the same as a carpool aggregator?

No. An aggregator generally brings together results from different sources. An iMarketplace, as defined here, is designed natively around intentions, conversation and connected universes within one experience.

Why connect carpooling with other marketplace universes?

A journey often supports another purpose, such as attending an event, moving house, collecting an item or reaching accommodation. Connecting these needs can reduce repeated searches while keeping each arrangement clear.

Is WEVONE already a large carpool platform?

No. WEVONE is a young platform with a few hundred registered members and is far smaller than established marketplaces. Pilote includes transport and parcel delivery, while WEVONE’s broader role here is to illustrate how an AI assistant marketplace can approach connected intentions.

Further reading