CRM Reporting for the Monthly Sales Review

The review where everyone is "working on it"

The meeting starts on time. The sales head pulls up a slide with bookings for the month, compares it to the target, and the gap gets explained project by project. Project A is "picking up." Project B has "a strong pipeline." Project C's numbers are "soft because of the festival lull." Each project head gets three or four minutes to narrate their number, the founder nods, someone notes down a follow-up action that sounds like "let's keep an eye on it," and the meeting ends ninety minutes later with nothing actually decided.

This is the most common failure mode of the monthly sales review at Indian developers running more than one active project: it is a status-reading exercise dressed up as governance. Everyone reports what happened. Nobody is forced to say what will change because of it. The reason is almost never a lack of data — most developers have a CRM full of leads, calls, site visits, and bookings. The reason is that the reports being pulled answer "what happened" questions, not "what do we do next" questions, and a review built on the wrong report set will always drift into narration instead of decisions.

This matters more with each passing quarter. According to the IBEF Real Estate Industry in India report (as of February 2026), the sector delivered 406,889 units in FY25, up roughly 33% year-on-year — supply is scaling fast, and a developer managing multiple simultaneous launches without a decision-focused reporting discipline is flying that scale on gut feel. This article lays out the report set that turns a monthly review from a status update into an actual management tool.

Reports that inform vs reports that decide

Not all CRM reports are equal, and the distinction matters more than most sales teams realise. An informing report tells you a fact: bookings this month were 12, against a target of 18. A deciding report tells you what to do with that fact: of those 12 bookings, 9 came from channel partners at an average cost per booking three times higher than consented first-party leads, and the two projects missing target both have inventory concentrated on floors above the 15th with no PLC pricing adjustment to compensate for lower demand at that height.

The first kind of report generates a sentence in a meeting. The second kind generates an action item with an owner and a deadline. Most developers' monthly reviews are built almost entirely on the first kind — gross bookings, revenue booked, site visits conducted — because those numbers are the easiest to pull and the least uncomfortable to present. Deciding reports require slicing the same data by source, by stage, by project, and by rep, which is more work to build but is the only version of reporting that changes what the sales team does next month.

The goal of redesigning your monthly review pack isn't more reports — it's fewer reports, each one built to force a specific decision, reviewed by the people who can actually act on what it shows.

Step-by-step: designing a decision-focused monthly sales review pack

1. Start from the decisions you need to make, not the data you have. List the five or six decisions your leadership team actually needs to make every month — reallocate marketing spend, flag underperforming reps, escalate stalled high-value deals, adjust pricing on slow-moving inventory — and build one report per decision.

2. Separate gross bookings from net bookings everywhere. A gross-bookings-only report hides cancellations, and cancellations in Indian residential sales are not rare enough to ignore — buyers back out after financing falls through, after family disagreements, after a competing project offers a better deal. Net bookings (gross minus cancellations minus deferrals) is the number that should anchor the review.

3. Attribute every lead and booking to its source, and compute payback per source. A /builder/leads pipeline that captures source at the point of first contact lets you compute cost-per-booking by channel — portal-resold leads, channel-partner referrals, and consented first-party leads each have very different acquisition costs and conversion rates, and blending them into one "leads" number hides which channel is actually paying back.

4. Build a stage-conversion funnel per project, not one blended funnel across all projects. A project in its launch quarter and a project in its final inventory-clearance phase have structurally different funnels; blending them produces an average that describes neither project accurately.

5. Report inventory ageing alongside sales velocity. A unit sitting unsold for eight months is a different problem from a unit sitting unsold for six weeks, even if both show up as "unsold" in a simple inventory count.

6. Track proposal-to-booking conversion as its own metric. /builder/proposals data — how many structured proposals were sent, and what share converted to a booking — tells you whether the pricing and terms being offered are competitive, separately from whether the lead flow itself is healthy.

7. Aggregate rep-level performance without turning the review into a public scoreboard shaming session. The point of rep-level data is to identify who needs coaching or reassignment, not to humiliate anyone in front of the founder — keep that data reviewed by the sales head, escalated selectively.

8. Anonymise or aggregate buyer-level detail in any report that reaches a wider leadership audience. Under India's DPDP Act 2023 and its 2025 Rules, buyer personal data should be handled with clear purpose limitation; a monthly review pack circulated to founders, finance, and marketing does not need individual buyer names and contact details — aggregate metrics answer the management questions just as well and reduce data-handling risk.

The core report set: metric, what it answers, decision it drives

Multi-project reality: source-mix payback, net vs gross, and absorption

Most mid-to-large Indian developers are not managing a single project's sales funnel — they're managing three, four, or more simultaneously, often at different cities, price bands, and construction stages. A review pack that presents one blended number for "this month's bookings" across all of that is nearly useless for decision-making, because a strong month at a mature, near-sold-out project can mask a genuinely weak month at a newly launched project that needs the leadership team's attention far more urgently.

Source-mix reporting deserves particular discipline in the Indian context because the three common lead sources behave so differently. Portal-resold leads (the same inquiry sold to multiple developers by a listing portal) tend to have lower conversion rates and higher acquisition costs per booking, because the buyer is often mid-comparison across several projects already contacted by other sales teams. Channel-partner referrals convert better but carry a commission cost that needs to be netted against the booking value to judge true payback. Consented, first-party leads — captured through a developer's own portal rather than resold — tend to convert best and cost least per booking, precisely because the buyer initiated contact with intent rather than being cold-called from a shared list. A monthly review that doesn't separate these three is comparing apples to oranges every single month.

Net-versus-gross bookings matters just as much. Booking-to-registration lag in Indian residential sales can run several months, and cancellations within that window are common enough — financing rejections, family reconsiderations, a better offer from a competing project — that a "bookings" number reported without a cancellation adjustment routinely overstates real sales health. A project that books 20 units and loses 6 to cancellation in the same window is in a materially different position than a project that books 14 units and loses none, even though the first project's gross number looks better on the surface.

Absorption rate — the pace at which available inventory in a given phase is actually selling, relative to the construction timeline — rounds out the multi-project picture. A phase that is 40% sold at 60% construction completion is a different risk profile from a phase that is 40% sold at 90% completion, and only a report that ties sales pace to construction stage will surface that difference before it becomes a cash-flow problem.

Mini scenario: the review that reallocated spend

A developer running three active projects had, for a year, run its monthly review off a single combined bookings number and a project-by-project narrative. One month, the sales head, prompted by a persistently soft number at the newest project despite heavy marketing spend, pulled a source-mix report for the first time in months. It showed that nearly 70% of that project's leads were coming from a single portal-resold source, converting at less than a third of the rate of the smaller volume of consented first-party leads generated through the developer's own portal.

The follow-up wasn't a vague "let's improve marketing" action item — it was a specific reallocation: cut the portal-resold spend by a third, redirect that budget toward campaigns driving traffic to the developer's own consented intake, and re-run the same source-mix report the following month to check whether cost-per-booking actually improved. It did, within two review cycles. That is what a deciding report looks like in practice: it didn't just show a number was low, it showed which lever to pull, and gave the team a way to check whether pulling it worked.

Reading conversion funnels and inventory ageing correctly

A stage-conversion funnel is only useful if you resist the temptation to read it as a single number. "20% site-visit-to-booking conversion" tells you almost nothing on its own — you need to know where inside that funnel prospects are dropping. If most of the drop-off happens between site visit and proposal, the problem is likely the pitch or the unit selection shown during the visit. If it happens between proposal and booking, the problem is more likely pricing, terms, or a trust gap in how the proposal itself was presented — which is exactly the kind of trust issue a transparent, structured proposal is built to close. If it happens between booking and registration, the problem may be financing friction or buyer cold feet during the lag period, which calls for a different intervention (faster documentation support, more buyer touchpoints during the wait) than a pricing fix would.

Inventory ageing needs the same nuance. A unit unsold for two months in a project that only launched three months ago is normal. The same two-month figure on a unit in a project that's 80% sold overall is a signal that something specific to that unit — floor, facing, layout, or price — needs attention, and it's worth flagging before it becomes an eighteen-month-old unsold unit that drags down the project's overall absorption story.

Pro tips

• Build the review pack around five or six reports, not fifteen. More reports produce more narration time and less decision time; be ruthless about cutting anything that doesn't map to a decision.
• Put net bookings, not gross, on the first slide. It sets the tone for the rest of the meeting as a real-numbers conversation.
• Review source-mix payback every month, not quarterly. Channel performance shifts faster than most teams expect, especially around festival seasons and competing project launches.
• Give each report an explicit owner who is expected to propose an action, not just present a number. A report without an accountable owner tends to drift back into narration.
• Re-run the same report the month after a decision, to check whether the decision worked. This closes the loop that most reviews skip entirely.

Common mistakes to avoid

• Presenting only vanity metrics — total leads, total site visits — without conversion context. A large lead count with poor conversion is a cost problem, not a success story.
• Reporting gross bookings without a cancellation adjustment. It systematically overstates health and delays action on projects that need it.
• Skipping source attribution. Without it, you cannot tell which spend to protect and which to cut, and the review becomes an opinion exercise instead of a data one.
• Blending multiple projects into one funnel. It hides the specific project that most needs the leadership team's attention.
• Circulating buyer-level personal data widely inside the reporting pack. Aggregate the data for broad circulation and keep individual buyer detail restricted to the team members who need it operationally.

Integration with other DrawMagic features

/builder/dashboard is built to be the reporting surface underneath this entire review process — pipeline by project, stage conversion, source mix, and rep performance in one place, drawing on consented, first-party data rather than a patchwork of spreadsheets exported from different tools. /builder/leads captures the source and stage detail at the point leads enter the system, which is the only reliable way to get clean source-mix reporting later — attribution bolted on after the fact is rarely accurate. And /builder/proposals turns "proposals sent" into a trackable stage of the funnel, so proposal-to-booking conversion becomes a real, reportable number instead of an anecdote from the sales team.

The value of better decisions from clean data

The cost of a status-reading review isn't the ninety minutes it takes — it's the month of unchanged behaviour that follows it. A developer running the same underperforming lead-source mix, the same unaddressed pricing gap on ageing inventory, and the same under-coached rep for another thirty days because the review didn't surface the problem clearly enough to act on. Clean, decision-focused reporting compounds the same way a stalled deal compounds in the other direction — every month the review actually drives a change is a month of sales performance that a status-only review would have left on the table. Review the pricing page to see which DrawMagic builder plan fits a multi-project reporting need.

Key Takeaways

• A monthly sales review built on gross bookings and blended funnels produces narration, not decisions.
• Separate net bookings from gross by adjusting for cancellations — booking-to-registration lag in India makes this adjustment material, not cosmetic.
• Source-mix reporting (portal-resold vs channel-partner vs first-party) is the single highest-leverage report for reallocating marketing spend.
• Build one report per project, not one blended funnel across all active projects.
• Inventory ageing only means something in context of a project's overall sell-through stage.
• Track proposal-to-booking conversion as a distinct metric from lead-to-visit conversion.
• Aggregate buyer-level data for wide circulation, consistent with DPDP-era data-handling expectations.
• Give every report an owner accountable for proposing — and later checking — an action.
• The FY25 delivery scale reported by IBEF (406,889 units, +33% YoY, as of Feb 2026) means multi-project developers need reporting discipline that keeps pace with supply growth.

FAQ

How many reports should a monthly review actually cover? Five to eight, each mapped to a specific decision. More than that and the meeting reverts to status narration because there isn't time to discuss any one report properly.

Should rep-level performance data be shared in the full leadership review? Aggregate rep performance trends are useful at the leadership level; individual rep coaching conversations are better handled separately by the sales head to keep the review focused on decisions rather than personnel matters.

What's the simplest first change to make if our review is currently gross-bookings-only? Add source attribution and a net-bookings adjustment before anything else — those two changes alone typically surface the most actionable gaps.

Ready to run your monthly review off clean, first-party data instead of spreadsheets stitched together after the fact? Set up your builder portal and start building your reporting pack on /builder/dashboard.