Smart Receptionist

The Idea

Every office building has a reception desk, and the process is always the same. You walk in, tell someone who you are here to see, they call the person, you wait, maybe they are late, you keep waiting. Nobody knows how long it will take. It is slow, manual, and kind of awkward for everyone.

At Junction 2016 (the biggest hackathon in Europe right now), our team asks: what if the building itself handles this? Not a person at a desk, but a chatbot that talks to the visitor, checks the employee's status, and guides the visitor around — all connected to the building's actual sensor data.

Junction 2016 main stage

How It Works

The smart receptionist is a chatbot on a mobile app. A visitor walks into the building and the flow goes like this:

The bot checks the employee's availability through Slack — the employee can reply "I will be right there" or "five minutes late," and the visitor sees it immediately
If the visitor needs to wait, the bot guides them to the nearest coffee machine using an indoor map
When the meeting room is ready, the bot shows the visitor how to get there
Room occupancy is pulled from building sensors, so the bot knows what is actually available, not just what the calendar says

The key insight is that buildings already have a lot of data — occupancy sensors, room booking systems, access control — but none of it is exposed to the visitor. We just connect the dots.

Architecture

Three components talking to each other:

Mobile app — the visitor-facing chatbot interface
Java data provider — pulls real-time data from Tieto's intelligent building sensors (720 API and others). This is where occupancy, room status, and indoor positioning come from
Node.js Slack bot — bridges the gap between visitors (on the mobile app) and employees (on Slack). When a visitor checks in, the employee gets a Slack message and can respond without leaving their desk

The mobile app sits in the center and orchestrates the flow. The interesting part is that the chatbot is not just a dumb script — it reacts to live sensor data to make decisions (e.g., "the meeting room is occupied, let me suggest another one").

Offline-First

We want this to work everywhere, including places with bad or no internet. So we design it to initialize the connection through a QR code on the wall. Scan it, and the app bootstraps without needing network for the initial handshake. This is a small detail, but it means the same system can work in a hospital in a developing country, not just a fancy tech office in Helsinki.

Beyond Office Buildings

The same pattern applies to many places:

Banks / post offices — take a queue number through the bot, get dynamic waiting time estimates that adjust as people leave
Hospitals — auto-register patients on visit without scanning ID barcodes
Public transport — detect new passengers and charge based on route

These are all the same problem: a building (or vehicle) has data, a person needs information, and the connection between the two is still manual and slow.

Result

We just won the challenge at Junction 2016!

The team after winning at Junction 2016

What I Take Away

Building a working end-to-end prototype in 48 hours forces you to make sharp decisions about scope. We start with a much bigger idea and cut it down to the smallest thing that still tells the full story. I think that is the most useful hackathon skill — not coding fast, but scoping well. Next step is to see if we can turn this into a real product.