BlueSuit, ML Document extraction for commercial real estate
My Role
Co-Founder, (sole) Principal Designer, Product Owner (from research to shipped feature)
Outcome
Live demo tool that increased prospects advancing through the sales funnel; Company acquired in 2023
Skills
Product ownership · Field research · Journey mapping · Designing for ML constraints · No-code operational tooling · Cross-functional work with engineering and data science
The problem was there was nothing to see
BlueSuit took documents from commercial real estate professionals, ran them through machine learning models that extracted and labeled specific, significant data, and returned data in a digestible format with confidence grades attached.
Our product worked, but it was an API, and an API has no face. When our sales team talked to potential customers, they only has a couple options to show off our product. They could ask prospects to send over a document and follow back with results days later, or try to demo the experience through a command line interface which worked, but required the ability to parse long string of JSON.
As a Co-Founder, I identified it as the thing standing between our technology and our revenue, and as the Principal Designer, I took ownership of solving it.
How I learned more
I interviewed our Head of Sales and Head of Strategy about how they spent their time. I learned that prospects could reach us by several different channels, but there was no single, central place where any of that prospect information lived. I also sat in on several live sales calls to understand where conversations stalled once they reached the demo stage. In those calls, there was a definite pattern: Prospects were interested right up until we tried to demo the product.
I mapped the current user journey from end to end for both our sales team, and our prospects. Then, I created the version I thought it should be, from initial interest to successful sales call. I revised that draft with the wider team and changed it with their input.
In the end, rather than propose one very large solution, I split the problem into two tracks with different constraints and scope: Fix the sales pipeline with creative resourcing and no engineering time at all, and build a sales demo tool with the smallest possible engineering ask.
Track One: Operational infrastructure with zero engineering
I identified an operational problem, designed a solution, built it, tested it, and validated it with users, without using any engineering capacity.
We had no budget for sales tool – HubSpot and similar tools were just too expensive. I research free and low-cost options, and designed a basic pipeline around what we had, and what we could afford.
I built the pipeline myself. Website submissions, interest forms, and inbound emails now all routed through Zapier into a dedicated Slack channel where the sales team would be alerted the moment a demo request came in. I configured the automations, tested them against real cases and edge-case inputs to make sure the team got the right notifications only. After it was built and running, I confirmed with the sales team it was working as it should.
And it was! Alerts reached the team much faster than manual monitoring had, and because it landed right in our communication tool, the team could claim or assign a demo in the channel and start managing a warm relationship immediately instead of discovering the request hours or days later.
Track Two: Make the invisible visible
I worked with our engineers on what we called a “sales enablement tool”, built inside our existing API management dashboard.
I hypothesized that letting a salesperson show the extraction happen live would do more for trust than any claim we could make verbally. My second hypothesis was that if it worked, this was the seed of a no-code way for potential customers to use our product, not just a sales aid.
I took the journey map into a user flow and low-fidelity wireframes, then worked closely with engineering and data science to pressure-test feasibility before committing to anything.
Some Challenges on Track Two
- The models needed specific inputs. Extraction depended on knowing the document type and the data type being requested, so the experience had to start with a short form. I designed it to be smooth enough that a salesperson could complete it while still talking, rather than going silent mid-demo.
- Results took two to five minutes. Anything longer than five minutes could be assumed to have timed out. So I designed for the wait rather than around it: progress visuals that gave the salesperson something to narrate, and clear signals distinguishing “still processing, keep talking” from “this has failed, restart it.” The design had to tell the person running the demo which situation they were in, in real time, in front of a prospect.
- The models couldn’t tell us where the data came from in the document. I had wanted to highlight the source location in the original document, showing not just what we extracted but where we found it, which is the single most convincing thing you can show someone who doubts your accuracy. However, the results package didn’t include location data, so I cut the feature. It was the strongest idea in my original concept, and shipping a version of it that guessed would have destroyed exactly the trust the tool existed to build.
What we shipped was lightweight: a short input form, meaningful visuals during processing, and a human-readable results view sitting next to the source document.
The Results
Sales knew about inbound interest immediately, and could act on it in the same place they learned about it.
The demo tool changed how sales conversations went. We saw a notable increase in prospects moving forward in the process compared to before launch. And I went back and sat in on calls again afterward, which is how I know the qualitative half: prospects were visibly less skeptical about our accuracy.
After launch, I kept working with engineering to refine the sales demo tool. One big change was I improved the information hierarchy on the results page and extending it to handle document results that weren’t purely text, including photographs and maps.
We were preparing to release the demo tool as a no-code way for customers to interact with our system when Berkadia acquired the company. I can’t totally claim the tool caused the acquisition. But I do think that being able to show the technology working, live, to anyone who asked, mattered to how the company was understood.
What I would change
I would instrument earlier. I validated this work through conversation and observation, which told me a great deal about why things were working but left me estimating how much. Analytics from day one would have let me quantify the funnel change precisely instead of describing it. That’s a gap I’ve been deliberate about closing in the work I’ve done since.