Bulk Move-in Smart Upload

Problem

Staff spent the morning after move-in typing a spreadsheet into Entrata

On move-in day, staff stay offline so the line can move. They mark names on a printed roll or a laptop sheet, hand over keys, and send the resident on. The next morning someone opens that file and types every person into Entrata. For a 300-resident property that was about eight hours of overtime. Desktop Bulk Move-In, the existing tool for processing many residents at once, barely showed up in peak months.

The first product I designed accepted that workaround. Keep the spreadsheet. Upload it. Let an agent match the rows. Do not force the table to change before we could recover the system of record.

Why a missed move-in matters to the business

Student properties made up a majority of Entrata’s clients. For that segment, move-in week is when the building turns over and the lease is supposed to become a current resident in the system the operator pays for. If that week lives in a spreadsheet, Entrata is optional on the highest-volume days of the year, for the customers who make up most of the book.

The advantage of shipping this is that Entrata gets the record back before billing, occupancy, and the lease status drift for another day. A property that finishes a 300-resident file in under an hour has a reason to stay in the product. A property that spends eight hours re-keying has a reason to keep the workaround. The bet was that a reviewed upload would make the first outcome the normal one.

If student properties still skip the tool in peak months the way they skipped desktop Bulk Move-In, or if a 300-resident file still takes most of a day, the bet is wrong. The targets at the end are what would prove it or kill it. They are not results.

Process

Why the overnight upload stopped being the main bet

Site visits and interviews for the table app changed what this product was for. The resident already felt finished at the breezeway. Catching Entrata up overnight, even in under an hour, still left the system of record wrong while keys were going out. We shifted the main bet to a phone in the line. This upload stayed for properties that keep the paper and process it the next day.

The targets at the end of this case are the bet for that overnight job. They are not results. Pilot actuals are not in yet.

Solution

The review before anything is written

The walkable prototype treats the spreadsheet as the source of truth. It does not ask staff to map columns by hand. What they have to check is the match. After the file lands, rows go into three buckets: people who will be moved in, people who will be moved in with a follow-up task, and rows the agent will skip unless a person steps in.

A missing pet screening or vehicle registration does not block the move-in. The agent still processes the resident and creates a follow-up. When two people share a name, staff pick the lease. Confidence sits on that choice. They can confirm, skip, or turn the row into a task. Nothing commits until they do.

What's next

How we would know the overnight upload worked

The prototype is the artifact: a file becomes a preview, a person can still correct a match, and then the agent can write. It is not a claim about production time. The table-side case is the product we took further.

Each row below is a way the hypothesis could fail. If the clock stays near eight hours, the upload did not replace the re-key. If staff still touch most rows, the agent is not doing the work. If peak months look like the old Bulk Move-In baseline, student properties did not switch.