What a Concierge App for New Homeowners Taught Us About Timing

Moving home sits near the top of every stress scale researchers have ever drawn up. The paperwork, the physical chaos, the disorientation of a new space, the social weight of a decision that probably took years to make. And yet, for the app sitting on a new resident's phone, none of that context usually exists. The app opens, the onboarding flow runs, and the product assumes the person on the other side is calm, curious, and ready to learn.

The app opens and the product assumes the person on the other side is calm, curious, and ready to learn. That assumption is almost always wrong.

We worked on a concierge app for a high-end residential development, and the brief forced us to think about timing in a way that most onboarding work simply does not. The product offered services, local recommendations, building management tools, and community features, but the question was never just what to show. The question was when a person who had just moved house was actually ready to receive any of it.

What we found changed how we think about onboarding altogether. The calendar matters. The week matters. The number of days since someone moved in matters. And none of that shows up in a standard user journey map.

Why Onboarding Usually Ignores the Clock

Most onboarding is designed around a single moment: the first open. The product team asks what a new user needs to know, sequences those things logically, and builds a flow that delivers them in order. That approach treats the first session as a blank slate, a person arriving with attention and appetite, ready to be guided.

The emotional reality is rarely that tidy. People open apps in car parks, in queues, in the middle of conversations. They open apps when they are anxious and looking for reassurance, when they are bored and want distraction, when they are under pressure and need a specific thing quickly. The moment of first use is embedded in a real-world situation that the product has no visibility of, and if the flow ignores that situation, it is effectively talking past the person.

The other thing most onboarding ignores is that first use is not a single event. It unfolds across days and weeks. What a person needs on day one is not what they need on day seven, and what they are capable of absorbing on a Wednesday evening is different from what they can take in on a Saturday morning with coffee. Designing one linear flow for all of that collapses real time into a fiction of constant readiness.

Before you design your onboarding flow, map the real-world situations that bring someone to your product. Arrival context, emotional state, and available attention all shape what a person can process in those first few minutes.

The Concierge App: Context and Stakes

The product we worked on served residents of a premium apartment development. Think doorman service, parcel collection, maintenance requests, restaurant bookings, local area guides. The people downloading it had just signed a lease or completed a purchase on a property that cost a significant amount of money. They arrived with high expectations and, almost certainly, a degree of stress that came with the territory of moving.

The stakes for the product were real. This was a residential community, so retention was not just a product metric. If residents did not engage with the app, they missed services they had paid for and the development's management team lost a direct communication channel. Low engagement had operational consequences, not just commercial ones.

The app also had a genuinely broad feature set. There were things useful on day one, like understanding the key fob system and who to call for an emergency. There were things useful in week two, like booking the gym. And there were things nobody would care about for at least a fortnight, like knowing which bin to use for which type of recycling. Showing all of that at once was not onboarding. It was a wall of information at exactly the moment a person had the least capacity to absorb it.

Mapping the Emotional State of a New Homeowner

Before we designed anything, we mapped the different situations in which someone might end up living in the development. This was not a persona exercise in the traditional sense. We were not building fictional characters. We were trying to understand the range of emotional states that could plausibly walk through the door.

A first-time buyer arriving at their first owned home carries excitement layered over financial anxiety and the disorientation of a major life change. Someone who has downsized after a divorce arrives exhausted, possibly grieving, and looking for control and simplicity above everything else. Someone relocating for work arrives practically minded but socially disconnected. Someone who has finally bought the home they saved for over a decade carries pride and a desire for the experience to match the moment.

The emotional state a user brings to your product is not a variable you can ignore. It is the frame through which everything else is read.

Each of these people opens the same app. The product cannot know which of them it is talking to without asking, and asking on day one adds cognitive load at exactly the wrong time. So the design problem shifted from "what does a new resident need" to "what does a person under stress, in a new space, with low cognitive bandwidth, need in the first hour, first day, and first week."

The answer to those three questions was different each time, and that difference drove the whole temporal approach.

Waiting for the Weekend: Time-of-Week as an Onboarding Variable

One of the clearest decisions we made on this project was about the local area guide. The app included recommendations for nearby restaurants, parks, transport links, and things to do. Useful content, and something residents would genuinely value once they had settled in. But the question was when to surface it.

If someone completed their sign-up on a Tuesday evening, they had almost certainly just arrived or were in the middle of unpacking. Suggesting they explore the local area at that point was tone-deaf. They were surrounded by boxes. They had not slept properly. The idea of going for a walk to find a good coffee shop was not relevant and possibly irritating.

So we built in a temporal delay. If sign-up happened midweek, the system waited until the weekend to introduce the local area features. By Saturday morning, the boxes were more likely to be dealt with, the immediate chaos had settled, and the psychological shift from "surviving the move" to "building a life here" had started to happen. Exploring the neighbourhood becomes an appealing idea at that point. It maps to how people actually feel, not how the product assumes they feel.

Time-of-week sign-up is a usable onboarding variable. If your product has discovery or exploration features, consider delaying their introduction until the user's week structure suggests they have the headspace to engage with them.

Letting the Boxes Empty First: Delaying Practical Information

The recycling decision is the one that tends to generate the most discussion when we describe this project, because it seems counterintuitive. Recycling information is practical. It is the kind of thing a responsible resident would want to know. Why withhold it?

Because knowing where the recycling bins are is only useful once you have something to recycle. In the first two to three days after moving, almost everything a person throws away is packaging. Boxes, bubble wrap, polystyrene. That volume creates a specific need, and by the time someone is asking "where does all this cardboard go", they are probably ready to receive that information. Show it on day one and it gets lost in a flow of orientation information they are trying to hold onto. Show it when the boxes have had time to empty and it lands as a timely, genuinely useful prompt.

The broader principle here is that information has a readiness window. Too early and it competes with everything else the person is trying to process. Too late and the moment has passed and the person has either found the answer elsewhere or given up. Matching information to the point in time when a person is likely to need it is the difference between the app feeling like a helpful presence and feeling like another thing to manage.

According to Business of Apps, 77% of daily active users stop using an app within the first three days of installation. Timing information to match real-world readiness is one of the more direct ways to fight that curve.

Personalisation Beyond the User Profile

The app also used profile data to personalise which features it introduced and when. If a resident had indicated they had children, the app deprioritised bar recommendations and moved towards playground locations, school run routes, and child-friendly events. That kind of personalisation is not unusual. What was slightly different here was how it connected to the temporal logic.

A family with young children has a different week structure from a single professional. The weekend for a family means earlier mornings, different activities, and a different kind of mental availability. Introducing the local area guide on Saturday morning assumes a certain Saturday morning, and that assumption holds differently depending on who the user is.

True personalisation sits at the intersection of who the user is and what is happening in their life right now. A profile field captures the former. Calendar-aware logic captures the latter. Combining them moves the app closer to behaving like a thoughtful friend who knows when to bring something up and when to leave it.

• Profile data tells the app who the user is
• Sign-up timing tells the app where they are in their week
• Days since move-in tells the app where they are in their settling-in process
• Combining all three lets the app surface the right thing at the right moment for that specific person

What the Calendar Knows That the User Journey Map Does Not

A standard user journey map captures what happens inside the product: the screens a person moves through, the decisions they make, the points at which they drop off. It is a map of the product experience, and it is genuinely useful for identifying friction. What it cannot capture is the life around the product.

The calendar knows things the journey map does not. It knows that Tuesday evenings are different from Saturday mornings. It knows that the first 48 hours after a move are qualitatively different from the first two weeks. It knows that someone who just handed over the largest amount of money they have ever spent is not in the same cognitive state as someone casually browsing an app for fun.

When we design onboarding as though the user journey begins at the first tap, we strip out all of that real-world context. We are left with a clean abstraction that performs well on a whiteboard and poorly in the hands of a stressed, tired person surrounded by half-unpacked boxes in a home they do not yet know how to live in.

Add a temporal layer to your journey mapping. Plot what a user does inside your product alongside what is likely happening in their life at each stage. The gap between those two pictures is usually where onboarding goes wrong.

Measuring Whether Temporal Onboarding Actually Worked

Designing around timing is one thing. Knowing whether it worked is another, and the measurement challenge is real. If you hold back a feature until day three and engagement with that feature is higher than average, is that because of the timing, or because the kind of person who reaches day three is already more engaged regardless?

The approach we recommend starts with defining the behaviour you are trying to change before you change the timing. For the local area guide, the question was whether residents who received that prompt on the weekend engaged with it more than residents in a control group who received it on day one. That is a measurable comparison, and it gives you a directional answer even if it cannot be perfectly controlled.

Segment retention data by sign-up day of week, and look for patterns. If users who signed up on a Friday and received weekend prompts show higher 14-day retention than users who signed up on a Monday and received those same prompts on a Tuesday, the temporal logic is probably doing something. It will not always be a clean signal, but over enough users the shape becomes readable.

1. Define the specific behaviour you expect the timing change to affect
2. Set up a comparison group receiving content at the standard time
3. Segment by sign-up day of week to identify patterns
4. Measure engagement with the specific feature, not just overall retention
5. Look for the signal across a large enough sample before drawing conclusions

When to Hold Information Back and When to Surface It

The hardest call in any temporally structured onboarding is knowing which information to delay and which to deliver immediately. Get it wrong in one direction and the user has a frustrating gap where they needed something and the product did not provide it. Get it wrong in the other direction and you surface information the person has no context for, and it vanishes from memory before it becomes relevant.

The framework we use asks three questions about any piece of content or any feature. First, does the user need this to complete the most basic version of the task that brought them here? If yes, it surfaces immediately. Second, does the user need this within the first week, but probably not within the first 24 hours? If so, it waits for a natural pause. Third, is this something that becomes relevant only once a specific condition has been met, like boxes being unpacked or a certain number of days passing? If so, it is triggered by that condition, not by time alone.

The table below maps this out for the concierge app specifically.

The safety-critical information always comes first. Everything else earns its moment.

Conclusion

The concierge app project was, at its core, a lesson in humility about what we actually know when someone first opens our product. We know when they signed up. We know what they told us in their profile. We do not know how they slept, what the move cost them emotionally, or whether they have eaten today. Designing onboarding as though we know all of that is how products end up feeling clinical and indifferent to the person using them.

Temporal onboarding is a discipline of restraint, of asking whether this is the right moment for this piece of information rather than whether this information is correct. The recycling prompt is correct on day one. It is useful on day four. That difference matters more than any copy refinement or visual design decision made to the same screen.

What travels out of this project into everything else we do is the calendar as a design variable. The day of week, the number of days since a meaningful real-world event, the time of day, all of these are available signals that most onboarding flows simply ignore. Using them does not require a sophisticated data infrastructure. It requires a willingness to ask what is actually happening in this person's life right now, and whether what we are about to show them fits that moment.

If your onboarding treats every user as though they arrived in the same state of readiness, it is worth asking what you know about when they actually showed up. Let's talk about your onboarding timing.

Frequently Asked Questions