Briqhaus CRM · Internal tool

A year inside one CRM

Briqhaus is the system a builder's sales team lives in all day: leads, inventory, bookings, payments, and the state of every deal. Several builders now run their sales on it, so every decision has to survive companies that work differently from the one I sit in.

A rough CRM was already working and in daily use when I arrived. The look was already decided, so I kept it. People use this every day, and changing how it looks would only slow them down.

What it did not have was a system underneath. Nothing said what a table, a state or an empty screen should be, so every new feature drifted a little further from the last. That was the job: build the system under the look I inherited, then design seven modules inside it. In the year since, seven modules shipped on top of it: an agent, a knowledge bank, meeting minutes, two admin dashboards, call analysis and channel partner campaigns. My job was that they arrive as one product rather than seven.

Five things shaped everything after that.

People live in it. Six hours, not six minutes, so anything clever gets tiring by the fortieth repeat.
It is dense. 154 tables and about 740 screens behind it.
Four roles share one record. Executives, managers, channel partners and directors each need a different slice, which shaped the structure more than any screen did.
Some of the process cannot move. RERA compliance steps, lead assignment, and the booking and payment stages are fixed, so the software fits the paperwork rather than the other way round.
It was already running. Every change had to land in a product people were using that day.

I spent the time on the system instead of the screens

What I built into it

Seven modules in a year, on top of a product that was already running.

Briqhaus AI. An agent over the whole CRM. The product is deep enough that using it well takes prior knowledge, and that is exactly what a new user does not have, so this is the way in. Type the job, assign a hundred leads to one executive or pull the analytics on lead 501, and the agent carries it out. It runs on credits, because the work behind it is real. I designed the flow and the interface, and spent most of the time on the harder question of how someone actually asks for something.
Briqpedia. A real-estate knowledge bank. RERA governs construction in India, so an answer here has to be right rather than plausible. The legal team researches the regulation and hands over the source material, that becomes the database, and the assistant answers out of it instead of out of a model's memory.
Meeting MOM. Records a client meeting and returns minutes with the action items pinned to the people who were in the room. It has its own case study.
Projection module. The admin view of a portfolio: every project, flats sold and unsold, the agreement value against each, the demand generated, and what is due to arrive at milestone one and milestone two. I did the flow, the screens, and the analysis behind what it shows.
Banker Snapshot. Built for raising a round. It takes what the CRM already knows, asks for the few things it cannot know, and returns the PDF a builder walks into the meeting with.
Call analysis. Reads the call so a salesperson does not have to sit through it again: what was said, what was promised, what state the buyer is in.
Channel partner campaigns. Channel partners are the agents who sell the flats, and builders need them as much as they need builders. A launch gets assigned to partners here and then tracked: revenue generated, which partner is actually performing, campaign by campaign.

Call analysis: five minutes a call, twenty calls a day, a hundred minutes spent reviewing calls instead of making them

Briqhaus AI: the way into a product that otherwise takes prior knowledge. Ask in plain English, and the credit balance sits in the corner because the work behind it is real

Briqpedia answers out of an indexed corpus rather than a model's memory, and says how many documents it is answering from

The projection module: every entity and project in one view, sold against unsold, agreement value, and what is due at each construction milestone

Banker Snapshot. The left panel is filled from the CRM automatically; the sections beside it are the due-diligence facts the system cannot know and has to ask for

Channel partner campaigns: a launch assigned to partners, then tracked by window, channel and state

I also make the films that sell these modules: I design the feature, write the pitch, and cut the video.

AI Studio: reads a project and builds the brochure

Reports: hand it anything, get the answer back

Compliance answers inside the CRM: RERA, stamp duty, FSI and GST, asked in plain language and answered from the knowledge base

Projects first, then stages

You work inside a building, not inside a pipeline

Instead of A single pipeline board you drag deals through

A generic CRM starts with the stage. This business starts with the building. A salesperson thinks "Tower B, what is left, who is close", not "show me everything in negotiation".

So you work inside a project and the deals sit under it. The structure of the software matches the way the room already talks.

After Unit availability and deal stage stopped being two separate lookups.

Dense on purpose, a second click is heard

A CRM gets judged on one thing: can you find what you need while you are on a call. Before this, the answer was somebody's memory: leads in spreadsheets, conversations in WhatsApp, inventory in one place, payments in another, and a generic CRM that knew nothing about towers, units or bookings.

The default screen carries the load

Instead of A clean default with the detail buried a click away

The usual advice is to hide density. That is wrong here, because people are on a call and the cost of a second click is the buyer hearing you hunt.

So the work went into making dense information readable rather than making it smaller. Hierarchy, alignment, and restraint with colour, so the number that matters is the one you see first.

After The answer is on screen before the buyer notices anyone looking for it.

The default screen carries the load: revenue, collections, pipeline, unit inventory and what is overdue, without a second click

Leads at a real day's density, and the state of every one of them. Designed against real data, never against six tidy rows

Payments: demanded, approved, pending, and the ledger behind them

The least visible thing I did here

Build the system, not more screens

Instead of Designing each new module to fit the look

The look was not mine to change, and it did not need changing. What was missing was the system under it: every new feature meant deciding again what a table, a state or an empty screen looks like, and the answers drifted apart.

So I spent the time on components and patterns instead of pixels per screen: one standardised library in Figma that every module is built from, so a new screen starts from decisions already made rather than from a blank frame.

I also run the QC pass on what gets built, from a designer's eye rather than a checklist. Building the front end myself is part of that, because the gap between the file and the screen is where consistency usually goes, and it does not survive being someone else's job.

Nobody points at it. It is also the only reason seven modules in a year did not turn into seven products.

After Seven modules, from the agent to the banker PDF, all shipped looking like one product.

Multiple builders run their sales on it

It is not an internal tool any more. Several builders run their sales on it, so every decision has to survive companies that work differently from the one I sit in.

The clearest number is the one call analysis gives back. It reads a call so a salesperson does not have to: five minutes a call, twenty calls a day, a hundred minutes a day each that used to go on reviewing calls instead of making them. That is more than a full working day a week, per salesperson.

The base I would rebuild

The inherited structure fights every new module. It was right for the product in front of it at the time, and it is now why some things take three screens that should take one.

I would rebuild that base. Not a redesign for its own sake: the next six modules should be cheaper to build than the last six, and right now they are getting more expensive.