Data Requests at Scaler
How I moved ESG data collection out of email and Excel and into the platform.
- Problem
- Scaler is an ESG data platform for institutional real estate funds. Consultants had given up on its survey tool and were collecting data over email and Excel instead.
- What I did
- I led research, strategy and design with one PM and five engineers, from discovery in January to launch in November 2025.
- Result
- 12 of 30 enterprise accounts switched in the first quarter, and 18 had switched by August 2026.
Almost every response still came through Excel.
The old survey module showed a status for every response, so on the surface it looked like a workflow. In practice, recipients filled in a spreadsheet offline and uploaded it, and the consultant downloaded it again to review it.
When I looked at how it was actually used, 199 of 221 responses had come through that spreadsheet loop, and only one of 33 clients was using the newer tool.
Consultants spent every quarter chasing spreadsheets.
I spoke to consultants, property managers and our own account team. One consultancy contacted ten property managers per client every quarter, sent reminders until the spreadsheets came back, and then spent half their time processing them.
Property managers filled in what they could, usually without much context, and that’s when the follow-up questions started.
“If this could be automated that would help so much.”
One meter reading passed through eight people.
One client walked me through the route a single utility reading took in Portugal. A security guard notes the meter every month, a technician converts the readings to consumption and types them into Excel, and a property manager checks them. The file then goes to the country team every quarter, where someone retypes it into the platform.
What the old flow lacked
Context
Recipients got a link and a spreadsheet, with nothing to tell them which fields mattered or why.
Status
Consultants had to open every file to see what was still outstanding.
Editability
The person who knew the data was wrong couldn’t correct it in the platform.
Review
Submitted numbers went straight in, without anyone checking them.
Clients asked to edit existing data, with review.
I grouped every request from the interviews by impact and by how many clients asked for it, and two clusters stood out. Clients wanted property managers to edit data that already existed, and they wanted to review those edits before anything counted. Nobody asked for a nicer form.
What we heard
Work where the data lives
Property managers wanted to stay in the Input Portal they already knew.
Keep verified data safe
Consultants were happy to bring in outside contributors, as long as verified data stayed safe.
Direct edits, with review
Both sides preferred editing to one-way submissions, as long as someone checked.
Form a hypothesis.
If property managers can edit the asset data directly, inside the platform, and every change is reviewed before it counts, then consultants will stop running collection over email and Excel.
Align on the questions that drive us.
- Can asking for exactly the data you need take minutes and no template?
- Can a property manager open a request and know what to do without an email?
- Can a consultant trust an external edit before it reaches a report?
- Can everyone see what is still outstanding without asking?
I changed the model from a survey to a request.
The old tool worked like a survey that you sent out and collected back. The new one is a request against data that already exists. The consultant asks for the fields they need, the property manager fills them in where the data already lives, and nothing counts until someone has reviewed it.
The four stages now run inside the platform.
The old journey had four stages, with a spreadsheet passed between each one. The shipped flow keeps the same stages, but all of them now happen inside the platform.
Three decisions shaped the design.
Clients were worried about property managers overwriting verified data, so permissions had to work down to a single field. That much control can easily turn request setup into an admin screen. So by default a request covers all the fields in a section, and consultants only pick specific sections and fields when they need to. Contributors can still see the required fields they can’t edit.
One permission level per request. It would have been simpler, but most requests mix verified and unverified fields, so consultants would have gone straight back to Excel.
External users edit directly in the portal. Each change stays pending with a record of what changed and who changed it, and calculations wait until a consultant has approved it. That’s what made direct editing feel safe to the people who own the data.
One-way submissions, like the old survey. Consultants would keep control, but someone would still have to retype every answer into the asset data.
Property managers used to get a spreadsheet with no context at all. Now each section of a request opens with instructions on how to fill it in. Data that is already known is shown but locked, only the requested fields are open, and if something looks wrong they can comment on that one field.
A separate form outside the platform, like the old survey. Property managers would have lost sight of the data that already exists.
Prototyping
We went through five rounds between March and September 2025. The survey turned into a request along the way, and the request gained a meter scope step after Morgan Stanley and Verdani walked us through how they handle meters.
We launched in November 2025, two weeks late to protect client data.
We pushed the launch back two weeks for migration testing, so client data stayed safe during Q4 reporting. Mitiska and Envirosustain were live within the first quarter.
Ask for exactly this
Pick fields or meters from the asset overview, then set the scope and choose who fills it in.
Review, then it counts
Edits stay pending and the old value is kept until a consultant approves them or sends them back. Once approved, the data updates calculations straight away.
Three things we got wrong.
Template reuse should have been in the MVP. Envirosustain asked for it in the first weeks, while consultants were rebuilding the same request for every asset. The cost field should have been optional from day one. And a migration test with real meter histories would have caught the versioning overwrite before it reached production. All three were in the discovery notes, and I gave them too little weight.
After launch, usage data set the priorities. We fixed a navigation break on the received-requests page the same day, and a blocked flow for assets without meters and the simpler template both shipped within the quarter. Import and export, multiple recipients and mobile entry for on-site readings were next on the list, each one traced back to a named client request.