Why a Resident Concierge App Deliberately Didn't Automate the Concierge Away

A property developer came to us with a concierge app for a new high-rise block, a budget already worked out and a feature list already written. The ask was straightforward. Put every building service into the app so residents never have to walk up to the concierge desk and ask. Fewer questions, less standing around, a cleaner operation.

What we handed back gave each concierge a profile in the app listing the things they liked talking about. Football. Motorsport. Whatever it happened to be. The product spent a good part of its design encouraging the exact conversations the brief had been written to remove.

The brief asked us to delete every conversation, and conversation turned out to be the whole product.

That change came from focus groups, and from one group in particular who were never going to buy a flat in the building. We ran sessions with social housing tenants because they already had the thing the developer wanted to manufacture, which was a set of neighbours who knew each other.

This piece walks through how that project went from a directory and maintenance logger to something closer to a social network, which features we dropped on the way, and how we now decide which parts of a service should be handled by software and which parts people should keep doing themselves.

The Brief: Put Everything in the App So Nobody Needs to Ask

The developer arrived with a suggested budget and a fairly settled idea of what they wanted. They were after a sense check rather than a proper scoping exercise. The thinking behind it was sound on paper. Concierge staff spend their day answering the same questions, so move the answers into an app and the questions stop.

The list was long. Recycling locations. Fire drill procedures. Emergency contacts. Maintenance requests. Local area guides. Building rules. Everything a resident has ever asked at a desk, packaged up and handed over on the day they get their keys.

What the client pictured

The picture in their head was a complete building directory. A resident moves in, opens the app, and the whole building is in there. Self-service from minute one, with the concierge freed up to do other things.

Sitting underneath that was a second ambition, mentioned almost in passing. They also wanted the app to build a sense of community in the block. High-rise developments have a reputation for people living two metres apart and never learning each other's names, and the developer wanted this building to feel different. They were selling flats, after all, and a building where people know each other sells better than one where they do not.

Both goals went into the same brief, in the same paragraph, as though they were pulling in the same direction.

The Contradiction Hidden in the Brief

They were pulling in opposite directions. A product that removes every reason to speak to another human being will not produce a building where people speak to each other. The first goal eats the second one.

Think about how you got to know anyone in a block of flats you have lived in. It was probably a lift, a parcel, a question about the bins, a dog in the lobby. Small, slightly boring exchanges that gave two strangers a reason to open their mouths. Strip those out and you have efficient residents who remain strangers for years.

Why communication was the real brief

Communication was the thread running through everything the developer actually wanted, including the commercial part. IREM report that renters who are happy with how their property management company communicates are four times as likely to recommend the property to others, which lines up with what we were hearing. People judge a building by whether they feel known in it.

So we had a brief asking for a product that would reduce human contact, written by a client whose business case depended on human contact. Pointing that out before design work started was the single most useful thing we did on the project.

Why We Insisted on Discovery Before Design

The client did not want discovery. They had a budget, a feature list and a timeline, and discovery looked like a tax on all three. We pushed back and asked for focus groups and user workshops before anyone drew a screen.

We push for this because we have watched what happens when a product gets discovery in one place and not another. On a dating app we worked on, enormous care went into onboarding, identity verification and proving that the person signing up was real. Messaging never got the same attention and was built to a generic pattern, which left the door open to exactly the fake, automated messages the onboarding had been designed to stop.

A product can argue with itself when one half gets discovery and the other half gets a pattern library.

The same risk was sitting in the concierge brief. Design the self-service directory beautifully, bolt a community feature on afterwards, and you get a product whose two halves cancel out.

Discovery also turned out to be the cheaper route. What the sessions told us was that the product needed to be much simpler than the client had drawn it. Features came out. Budget came down. The thing we built cost less than the thing they walked in asking for.

What Social Housing Tenants Taught Us About Community

We ran focus groups with two very different sets of people. One was the target market, high-net-worth individuals buying into a premium development. The other was people living in social housing, who were never going to be customers and who we brought in on purpose.

We brought them in because they already had what the developer was trying to build. Neighbourliness. Openness. Knowing who lives behind which door. That quality is usually missing from high-rise developments at the premium end, and we wanted to understand where it comes from rather than guess.

If the quality you want in your product exists somewhere outside your target market, go and research the people who have it. They will teach you more than another round with your own customers.

What we found in those sessions was the depth of the conversations people were having with each other. They were not swapping pleasantries about the weather on the way to the car park. They were talking about work, health, family, money worries, the things going on in each other's lives. That depth was what produced the sense of community, and the superficial version of the same exchange produced nothing.

Sitting in those rooms made the strategic recommendation obvious. The app should take on the dull, transactional traffic and then work hard to protect the conversations that matter.

Familiarity as the Real Product: Names, Jobs, Children, Pets

The thing underneath those deeper conversations was familiarity. People in the social housing groups knew each other's names, what each other did for a living, how many children they had, what the dog was called, who was into what. None of it was remarkable on its own. Accumulated over months, it added up to a feeling of belonging.

That gave us something concrete to design towards. A sense of community is what happens once a certain number of personal details have passed between two people, and every one of those details arrives through an interaction. Remove the interactions and the details never surface, which means the belonging never arrives either.

Designing for disclosure

So we started treating those small personal facts as the output the product existed to produce. Residents could build a profile with their interests, what they do, whether they have a dog, which floor they are on. The app surfaced the overlaps, so someone who runs sees two other people in the building who run.

Every feature then got measured against one question. Does this put a personal detail about one resident in front of another resident, or does it take one away? A maintenance form takes nothing away, because nobody bonds over a broken tap. A chatbot that answers every question a resident has about the building takes away quite a lot.

Giving the Concierge a Profile

The concierge was the hardest part of the brief to rethink, because the original plan treated the role as an information desk that happened to have a person standing behind it. Replace the desk with an app and the role shrinks to parcels and door entry.

We argued for the opposite. In a building where most residents have no relationship with anyone, the concierge is the one person everybody passes every day. That makes them the most valuable social connection in the block, and the product should be building that relationship rather than winding it down.

So each concierge got a profile in the app. Their name, their face, and a short list of things they are happy to be stopped about. Talk to me about football. Talk to me about motorsport. Whatever that person genuinely cares about, written as an open invitation.

It sounds like a small feature and it did a surprising amount. A resident who has read that profile has a reason to say something beyond asking whether a parcel has arrived. The concierge stops being staff and becomes a person called Danny who follows the same team you do. Residents who talk to Danny end up talking to each other through Danny, because he knows who everybody is.

The profile modelled the behaviour the whole building needed.

From Building Directory to Social Feed

Once familiarity became the point of the product, the shape of the thing had to change. What the client had specified was a directory with a maintenance logger attached. What we built put a social feed at the heart of the app and pushed the building management features into a secondary layer.

Residents could post. They could ask their neighbours for help with something, lend things, flag that a van had been blocking the entrance all morning, or ask whether anyone knew a decent plumber. The concierge team posted updates. Local charities posted too, which tied the building into the streets around it rather than sealing it off.

It went from a directory product to something much closer to a social network with a building attached.

Moving the feed to the centre changed what opening the app felt like. A directory rewards you with a fact. A feed rewards you with a person, which is a very different reason to come back.

The maintenance request form still existed and still worked well. It just stopped being the front door of the experience, and that reordering did more for the community goal than any feature we could have bolted on later.

Automating the Mundane to Make Room for the Human

We stopped looking at the product as a machine for solving every problem that currently gets solved offline. Instead we sorted the building's traffic into two piles, automated one of them hard, and spent the saved time on the other.

The automated pile was everything with no social value in it. Logging a maintenance request. Finding out where the recycling goes. Checking the fire drill procedure. Booking the lift for a delivery. Nobody has ever felt closer to their neighbours because they both read the same evacuation notice. Those tasks are pure admin and admin is what software is good at.

Clearing that pile gave two groups of people their time back. Residents stopped spending their attention on building logistics. The concierge stopped repeating the same six answers twenty times a week.

What the freed time was for

Time on its own does nothing, so the product had to point it somewhere. A concierge with a quieter morning and a profile full of conversation starters will have different exchanges with residents than a concierge fielding questions about bin collections. Residents who are not chasing a maintenance ticket are more likely to read the feed and see that someone three floors up has the same dog.

Efficiency bought the room. Design decided what went in it.

Timing Information to the Emotional State of Moving In

The industry default is to hand a new resident the entire building directory the moment they download the app. Recycling, emergency procedures, local area guides, rules, contacts, all of it, on day one. It looks generous and it is emotionally tone deaf.

Think about the state someone is in on the day they move. The flats in this development were being bought by people in wildly different circumstances. Some had just bought their first property and were elated and broke. Others were moving in after a separation or a divorce, into a flat they had not planned on needing. Both groups were surrounded by boxes and neither was in a frame of mind to absorb forty screens of building information.

Write down the emotional state your user is in at the exact moment each piece of content arrives. If the content assumes calm attention and the moment does not have any, move it.

So we drip-fed it. Recycling information turned up a couple of days after move-in, around the time the packaging starts piling up. Local area recommendations landed over the first weekend, when someone finally has an hour to go and find a coffee. Each notification arrived close to the moment it became useful.

Bombarding people with everything at once would have contradicted the entire promise of the product. A human thing does not shout its whole contents at you in the first thirty seconds.

The Features We Cut, and What That Saved

Discovery took features out rather than adding them. A good chunk of the original list existed to replace systems the building already ran perfectly well, and rebuilding those in an app would have cost real money for no gain to anyone living there.

What came out fell into a few recognisable groups.

• Features that duplicated building systems already working in the block
• Features that answered questions the concierge was better placed to answer in person
• Content dumps that assumed a resident wanted everything at once
• Anything that let a resident complete a social task without any social contact

Cutting that lot did three things. The build cost dropped below the budget the client had walked in with. The remaining features got more design attention, because the effort went into fewer places. And the product became easier to explain to a resident, which matters enormously for something people open in a stressful week.

The client's instinct had been that a fuller app was a better app. What discovery showed was that most of the fullness was working against the one outcome they cared about commercially, which was people wanting to live there and telling other people so.

Less product, more building.

How to Tell Which Tasks Should Be Automated and Which Shouldn't

The sorting question we used on that project has held up since. For any task a person currently does by speaking to another person, ask what the repetition of that task builds up over time. If the answer is nothing beyond the task being done, automate it without hesitation.

If repeating it slowly produces familiarity, trust or a relationship, automating it destroys something the business is paying for elsewhere.

Automate the tasks that build nothing when repeated, and protect the ones that quietly build everything.

The test is useful because it stops the conversation being about what software can technically do. Software can handle almost any of it. The question worth answering is what disappears from the service when it does.

What This Means for Any Service With People At Its Heart

The same sorting applies well beyond property. On a group travel booking flow we designed, the work of entering passenger details got spread across the people going on the trip, so one person stopped shouldering the whole thing. That works nicely for a group of friends or colleagues heading off together.

It works less well for a family, where a parent has their children's details and nobody else does. So the shared version sat alongside manual entry rather than replacing it. Anyone who wanted to fill in every field themselves still could, and the collaborative route was there for the people it suited.

Make any feature that redistributes effort between people an option rather than the only path. The social version helps some users and gets in the way of others.

The other habit worth borrowing is cheap and oddly effective. When we play a change back to a client, the reaction is immediate, because everyone in the room is a user of products like this one. Asking a client how a change feels to them sits comfortably alongside formal testing and catches emotional misfires early.

Hotels, salons, gyms, clinics, restaurants. Any service where somebody greets you by name has the same question sitting inside it. Which parts of this are admin, and which parts are the reason people come back.

Conclusion

The developer asked for an app that meant nobody needed to speak to the concierge. They got an app that handles maintenance requests, fire drills and recycling without any fuss, and then spends its remaining energy getting residents to talk to Danny about the football and to each other about everything else.

It cost less than the original plan because discovery took features out instead of adding them. It worked really well, and the reason is that we stopped treating the concierge as a cost to be designed around and started treating the relationship with them as the thing residents were buying.

Every service business has a version of this choice sitting in its roadmap. There is always a pile of repetitive work that software should have taken over years ago, and sitting next to it there is usually a handful of small human exchanges that look just as repetitive and are doing something completely different.

Telling them apart takes research rather than instinct, and it is much cheaper to do before the build than after it.

If you are weighing up what to automate in your own product and which bits to protect, let's talk about where the human part of your service sits.

Frequently Asked Questions