NeoKe

NeoKe is a digital traveller ID network making manual hotel check ins a thing of the past for corporate travellers. Companies can seamlessly approve, reserve and verify their employees business trips.

Comment

NeoKe: The next generation passport to travel the world.

Inspiration.

NeoKe is founded by ex. Booking.com executives who have dedicated their lives in making it easier for people to travel. We are a team of industry experts in Travel, product development, SSI & Blockchain.

In this project we are addressing problems associated with business/corporate travellers. As business travellers ourselves we know that they want to save as much time as they can so that they can close that next deal and make more revenues. Today, business travel is full of friction as the user:

  1. seeks for company approval for travel and is often unaware of the benefits and entitlements
  2. uses multiple platforms to book one trip, without reuse of traveller data. Often unaware of corporate benefits and entitlements.
  3. dislikes standing in long lines at hotel check ins/outs to verify IDs, sign documents and get keys. Even after multiple visits at the same hotel month after month
  4. post travel, submits expenses via clunky reimbursement system and has to prove verification of stay by sharing confirmation and the invoice.

What it does

In a nutshell, NeoKe allows companies to verify their employees by creating their traveller ID as a one time setup. This verified credential replaces the process of KYC, and enables the user to quickly login to any travel provider (the likes of Booking.com, Expedia, marriott.com, etc), digitally check-in by sharing IDs, sign documents and get a proof of stay to be presented back to the employer. This solution, makes it efficient for business traveller to getting verified once and using their data wherever it is needed.

More in detail, what NeoKe does could be split into 3 stages:

  1. Account setup : This is done only once (in the context of demo), traveller ID is created by asking for employee information. Traveller id serves as a proof of identity and employment to hotels and other travel providers. with employee’s corporate email as a recipient of our credential, we transform the employer into a “KYC provider” certifying the identity and employment status of a traveller. Alternatively, this flow could also be initiated by the employer, who issues proofs as they have already verified information of their employees. Moving forward, this account would also be enriched with the user’s travel preferences, such as preferred type of hotels (in terms of location, prices, amenities, etc), dietary preferences (vegan) or room preferences (non smoking).

  2. Reservation process : It starts with the user logging in securely on a travel site using their Proof of ID as verified employer credential. Now, traveller is able to make the reservation with pre filled information and is issued a proof of reservation as a confirmation.

  3. Key creation & Check-in process : a key is issued within 48 hrs of arrival - user shares proofs (ID/ employment and reservation) - equipping the hotel with all they need. On arrival, the user can certify that all the documentation has been previously provided by presenting a QR code - to be scanned by the frontdesk personnel. Once that’s done, the user will receive the key to the room and the proof of stay. In the future, we could optimise it by issuing digital NFC hotel keys as well.

How we built it

This process had 7 steps:

  1. Gathering of learnings about travel pain points, from the users’ and travel-providers’ perspectives
  2. Building a cross-functional team, composed by travel and technology experts
  3. Cross-pollination, where the team members learnt from each other’s crafts
  4. Iterative definition of ideal user flow
  5. Understanding of the MSFT Entra platform
  6. Definition of flow, in the context of the hackathon use case
  7. Implementation

As mentioned above, this process started a couple of months ago (before the publication of this hackathon) with some realisations and learnings - coming from our own experience in the travel industry and interviews we’ve held with users and travel-providers alike - about the main pain points remaining in travel, many of which happen after the reservation is made. That’s where the main online travel agencies “drop the ball” so to speak, as their main KPI is typically conversion to purchase. These pain points relate mostly to the check-in process at the front desk of the hotel/ car-rental service, which typically entails signing contracts, filling up forms and presenting identity documents. This can get worse - depending on the number of guests related to a reservation or on the regulations for check-ins in specific countries/ areas. It could also amount to a considerable amount of time, depending on the number of users in the check-in line, and on how often a given user needs to stay at hotels since - say - people that travel for work, would spend a considerable amount of their lives either lining up or checking in a travel service.

All of the above is very surprising given the amount of incumbents in travel tech and the fact that there’s typically plenty of time - in between the reservation of a hotel/ car-rental/ flight and the moment where we’re actually going to use it - for completing the tasks (signing contracts, presenting documents, etc) required to use those services.

That’s how we first build a team of people experienced in travel (from the business’ and the user’s perspectives) and in the SSI technology, to come up with a solution to the above stated problems/ learnings. Once we had the team, we started the cross-pollination process of having the “SSI” people learn about travel, and the “travel” people learn about the opportunities presented by SSI. Once we had a common understanding of the problem and the opportunities available, we started the process of definition of an ideal user flow - where we eventually introduced the concept of “key creation” (or pre-check in) and defined different ways for the user to check in at the hotel, included a key-less one, where the traditional key to the room is replaced by the user’s mobile phone.

Once we had defined/ conceptualised a flow with a certain level of resolution, we learned about Microsoft Entra and its hackathon, which is when our team started getting its hands dirty with its technology, by reading the doc and running the first tests, which happened only a couple of weeks ago. After that, we combined our understanding of the Entra platform with the previously defined flow to define the scope of our hackathon-implementation (by keeping in mind the deadline). The last point to mention here was the actual implementation (from the tech and UX perspectives) which - even though was “eased” by the previous steps mentioned - still presented its own challenges, to be mentioned in the “challenges” and “feedback” sections of this submission.

Challenges we ran into

There have been a couple of challenges we ran into, related to the usage of the Entra platform itself, which we have detailed in the feedback section. Other than that, the main challenge worth mentioning was how to represent our solution (hackathon submission) in a somehow understandable flow, given that we have 5 “interfaces” to consider: The Authenticator app, NeoKe’s page (to create the account), user-facing Travelsoft (to make a reservation),hotel-facing Travelsoft (to check/ manage reservations) and the email notification flow.

Accomplishments that we're proud of

In general, we’re quite proud of submitting a solution that works (given that we implemented it in a couple of weeks), proposing a flow that entails 3 VCs, that includes 2 types of users (end users and hotels) and considers an email-notification flow towards both types of users. This interface doesn’t only work technically, but it’s also visually appealing and it has some level of UX validation.

Apart from that, we’re proud of 2 specific “break-throughs” offered by our solution:

  1. The “key creation” step, where important information about the user is shared beforehand, helps the hotel in its room planning/ allocation process and allows the user to breeze through the check-in front desk. This may be similar to what happens in the flow to take a flight, where the user can check-in days before coming to the airport.
  2. The fact that we considered an employer as an identity provider, which makes sense as any average employer would do some sort of identity check on its potential employee prior to their hiring, and which helped us simplifying our solution and the UX flow

What we learned

Some travel & user related learnings have been described in the “How we built it” section. From the tech side, and after testing some other SSI providers, we’ve been positively surprised on Entra’s capabilities which seem quite well suited for young and fast-moving teams like ours. In particular, these are the 2 learning-points we’re most happy about:

  • How easy and quick is to deploy changes (after the initial setup). This has been fundamental to accomplish and deliver what we set out to do, given the couple of weeks we had (between the moment we learnt about the hackathon and the submission deadline)
  • The fact that the blockchain is free to use, which has also allowed us to run multiple tests without worrying about the bills. This might very well be the main reason why we’ve picked Microsoft to build our solution on.

What's next for NeoKe

NeoKe dreams of building a global Traveller ID network as a one-stop solution for all travel-related needs. With NeoKe, a traveller can securely login to any travel service without having to remember multiple usernames and passwords, seamlessly travel with pre check ins at airports/hotels/car rentals and simply store their trip details, IDs & credentials in one place making it easier for the traveller to stay on top of each moment of the trip. We call this the 'connected trip'.

Built With

Share this project:

Updates