How to Set Notification Preferences on DrawMagic

A buyer submits a consented lead on Friday evening — genuinely interested, ready to visit that weekend. Nobody at the developer's sales desk sees it until Monday morning. Not because the lead wasn't captured, and not because the sales team was lazy, but because the notification that should have reached someone went to an inbox nobody was watching, or to a phone that was switched off for the weekend, or simply never fired at all because alerts had been turned off months earlier after one too many irrelevant pings.

By Monday, that buyer has likely visited two other projects and formed opinions about both. The lead isn't dead, but the developer has lost the advantage of being first — and in a market as competitive as Indian residential real estate, first-to-respond is often the difference between a booked site visit and a buyer who's moved on.

This is not a lead-generation problem. It's a notification-configuration problem, and it's one of the fastest things to fix once you know where to look. This guide walks through setting up notification preferences in the DrawMagic builder portal so the alerts that matter — new leads, site-visit requests, proposal responses — reach the right person fast, while the noise that doesn't matter gets muted.

Why Speed-to-Lead and Notification Discipline Go Together

India's residential real estate market rewards responsiveness. IBEF's Real Estate Industry in India report (as of February 2026) notes a sector delivering 406,889 units in FY25 — up 33% year-on-year — with institutional investment climbing alongside it (IBEF — Real Estate Industry in India). More projects, more launches, and more developers competing for the same pool of serious buyers means a buyer submitting interest today has more alternatives than they did two years ago. If your desk takes three days to respond to a consented lead, that buyer has almost certainly already had a productive conversation with someone else by the time you call back.

Notification setup sits directly upstream of that speed. A lead that's captured correctly but never surfaces as an alert to the right person is functionally the same as a lead that was never captured at all — except worse, because the buyer now associates the delay with the developer, not with a technical gap they can't see.

At the same time, over-notifying is its own failure mode. A sales executive who receives a ping for every status change, every internal update, and every automated system event will eventually do what anyone does when a fire alarm goes off too often: start ignoring it. The goal of notification preferences isn't "more alerts" — it's the right alerts, to the right person, through a channel they actually check.

Step-by-Step: Tuning Notification Preferences in the Portal

1. Start at your dashboard. Log in to /builder/dashboard to get oriented on current activity before adjusting settings.
2. Open notification settings. Go to /builder/settings, where the events you want to be alerted about and the channels you want to be alerted through are configured.
3. Choose your events and channels. Decide which event types deserve an immediate alert (new lead, site-visit request) versus a lower-priority digest or no alert at all (routine status updates), and pick the channel — app, email, SMS/WhatsApp where supported — your team actually monitors.
4. Route alerts to the right owners. Notifications are only useful if they reach the person responsible for acting on them. Cross-reference with /builder/leads so alerts about a specific lead route to whoever owns that lead or that project's desk, not a shared inbox nobody checks consistently.
5. Test it. Before trusting the new setup for a live weekend, send or trigger a test alert and confirm it actually reaches the intended person on the intended channel. A setting that looks correct on screen but silently fails to deliver is worse than no setting at all, because it creates false confidence.

Which Events Deserve Priority — and Which Channel to Use

Not every event coming through the portal deserves the same urgency. Use this as a starting framework and adjust based on how your desk actually operates.

The underlying principle: anything that represents a live, time-sensitive buyer interaction (a new lead, a visit request) deserves an immediate, hard-to-miss alert. Anything administrative or reputational (reviews, billing) can wait for a daily or weekly check without costing you anything.

Geographic and Team Realities Shaping Notification Setup

• Speed-to-lead is a genuine competitive edge in India's market. With more developers and more launches competing for buyer attention, the desk that responds first to a fresh, consented lead often earns the site visit — which is why lead and visit-request alerts deserve the highest priority setting available.
• Route alerts to the right desk, not a shared inbox. Multi-project or multi-city developers should configure alerts so a lead about a specific project reaches that project's team, not a single shared inbox that nobody is specifically accountable for monitoring.
• Choose channels your team actually uses. Many Indian sales teams operate primarily on mobile, with WhatsApp and SMS as their default communication tools. A notification system that only sends email to a desktop inbox will be far less effective than one that reaches the channel your executives are already checking throughout the day.
• Plan for festive-season volume spikes. Lead volume around Navratri, Diwali, and other high-demand periods can rise sharply. Review your alert setup ahead of these periods to ensure high volume doesn't degrade into noise that gets ignored.
• Treat lead notifications as personal-data handling, not just operational messaging. Notifications about consented leads carry real personal information about a buyer, and DPDP-era data-handling expectations mean these alerts should route only to authorised team members with a legitimate reason to see that buyer's details — not be broadcast broadly "just in case."

Mini Scenario: A Bengaluru Desk Routes Alerts by Owner and Mutes the Noise

A Bengaluru-based developer's sales desk had notification settings largely untouched since the portal was first set up — every event type pinged every team member's shared device. Over time, executives began muting the app's notifications entirely, including the ones for new leads, simply because the volume of low-priority pings had made the app feel like noise rather than a useful tool.

The sales lead reworked the setup in /builder/settings: new-lead and site-visit-request alerts were routed to the specific on-duty executive for that project, rather than the whole team, and low-priority events like reviews were moved to a daily digest instead of instant pushes. The team re-enabled notifications once the volume dropped to only what mattered. This is one desk's specific fix, not a universal guarantee, but it illustrates the underlying lesson: alert fatigue is usually self-inflicted by over-broad settings, and it's reversible by narrowing who gets pinged for what.

Balancing Responsiveness Against Alert Fatigue

The tension at the heart of notification design is real: too few alerts and a hot lead sits unseen; too many and the team tunes out everything, including the alerts that matter. A few practical ways to hold that balance:

• Reserve instant, hard-to-miss alerts for genuinely time-sensitive events — new leads and site-visit requests. Nothing else needs that level of urgency.
• Use digests for informational events. Reviews, routine status changes, and similar low-urgency updates can be batched into a daily or weekly summary without any real cost.
• Assign per-role or per-desk routing so alerts reach the person actually responsible for that project or lead, not everyone on the team simultaneously.
• Revisit the setup periodically, especially after a period of high volume like a festive campaign, to check whether the balance still feels right or has drifted back toward noise.

Pro Tips for a Notification Setup That Actually Works

1. Prioritise lead and visit-request alerts above everything else. These are the events with the shortest shelf life for a useful response.
2. Route by owner, not by team. A notification sent to five people is often, in practice, seen by none of them with real accountability.
3. Use the channel your team checks — usually mobile. A setup that assumes constant desktop email monitoring will underperform one built around WhatsApp or SMS for time-sensitive alerts.
4. Review your setup after every festive-season spike. What worked at normal volume may need adjustment once volume triples.
5. Test the setup before relying on it for a live weekend. A silent failure in your notification chain is far more costly than a known gap you're actively working around.

Common Mistakes to Avoid

• All notifications off. Usually the result of frustration with noise, but it means genuinely urgent leads go unseen — the exact scenario that opened this guide.
• All notifications on, for everyone. This creates the fatigue that eventually leads a team to disable alerts entirely, including the important ones.
• Shared-inbox routing with no named owner. When an alert goes to everyone, accountability for acting on it goes to no one in particular.
• Never testing the setup. A configuration that looks right on screen but fails to deliver in practice is a silent, ongoing risk until someone notices a missed lead.

Integration with the Rest of the DrawMagic Builder Portal

Notification preferences are only useful in context — an alert about a new lead is only actionable if the recipient can immediately act on it, which is why /builder/settings and /builder/leads work together: settings determine who gets notified and how, while the leads page is where that alert leads to real action. If you're evaluating DrawMagic more broadly as your sales operation scales, /builders covers the full picture of what the builder portal offers beyond notifications.

Value Note: The Right Alerts Protect Speed-to-Lead and ROI

DrawMagic sends the operational alert; your team decides how to route it and how quickly to respond — there's no guarantee attached to notification settings themselves about what happens once a buyer is contacted. But in a market growing as fast as IBEF's figures suggest — 33% higher FY25 delivery volumes than the year before — the developers who respond to a fresh lead within minutes rather than days are simply giving themselves a better shot at converting interest into a booked visit. If your team's current subscription tier or lead volume has changed since your notification settings were last reviewed, it may also be worth checking your plan fit at /pricing.

Key Takeaways

• New consented leads and site-visit requests deserve immediate, high-priority alerts — they are the most time-sensitive events in the sales funnel.
• Route notifications to a named owner per project or desk, not a shared inbox that nobody feels specifically accountable for.
• Choose channels your team actually monitors — mobile push, SMS, or WhatsApp typically outperform desktop-only email for time-sensitive alerts.
• Use daily or weekly digests for low-priority events like reviews or routine status changes, rather than instant pings for everything.
• Plan to review your notification setup ahead of and after festive-season volume spikes, when alert fatigue is most likely to set in.
• Test your configuration before relying on it for a live weekend — a silent delivery failure is worse than a known gap.
• Treat lead-related alerts as personal-data handling under DPDP-era expectations — route them only to authorised team members.
• Avoid both extremes: all-notifications-off (missed leads) and all-notifications-on (alert fatigue that eventually mutes everything, including the important alerts).
• Speed-to-lead is a genuine competitive advantage in a growing, competitive Indian real estate market.
• DrawMagic delivers the alert; the developer's team controls routing and response — no outcome is guaranteed by the notification system itself.

FAQ

Q: Where do I go to change which events trigger a notification? A: /builder/settings is where notification events and channels are configured.

Q: Can different team members get different alerts? A: Yes — alerts can be routed by owner or desk so that, for example, a new lead for a specific project reaches the executive responsible for it via /builder/leads, rather than being broadcast to the whole team.

Q: How do I know if my current notification setup is causing alert fatigue? A: A practical sign is if your team has started ignoring or muting the app's notifications altogether. If that's happening, revisit /builder/settings and narrow high-volume, low-priority alerts to a digest instead of instant pushes.

If a hot lead has ever sat unseen over a weekend on your desk, your notification setup is worth five minutes of attention today. Start at /builder/dashboard, tune your alerts at /builder/settings, and make sure the next consented lead reaches the right person before your competitor's does.