Most real estate teams that run kvCORE spend their first year fighting the pipeline. The default stages — New, Attempted Contact, Active, Under Contract, Closed — look clean in a demo, but they don't reflect how deals actually move at a team with a separate pre-qualification step, an in-house transaction coordinator, and a post-close referral sequence. Agents either skip stages or create informal workarounds in texts and sticky notes, and the broker ends up with a pipeline report that tells them almost nothing.
This is a solvable problem. kvCORE exposes enough of its configuration and webhook surface that a custom plugin can insert the stages your team actually uses, trigger automations at the right moments, and push status changes to the tools that need them — without touching the underlying platform or migrating to a new CRM.
Why default stages break down
kvCORE's pipeline is built for a generic brokerage workflow. For a team that runs its own lead qualification before an agent ever makes contact, "New" and "Attempted Contact" are already the wrong starting point. The lead came in from a paid campaign, was screened by a qualification call, and arrived in the pipeline already warm — but the stage history shows three days at "New" because no one bothered to update it manually.
The downstream effect is real. Say a team processes 40 leads a week. If 30 percent of those get stuck in the wrong stage for more than 48 hours, the broker's pipeline report consistently understates how many active buyers are in play. Referral follow-up sequences that should fire after closing never trigger because the "Closed" stage only gets set when the agent remembers to move the card.
What a custom plugin adds
A plugin in this context is not a full software product. It is a lightweight integration layer — typically a webhook listener and a small set of API calls — that sits between kvCORE and the rest of your stack. It does three things.
First, it maps your real stages to kvCORE's status fields. kvCORE allows custom smart filters and tags that function as surrogate stages. The plugin enforces naming conventions, prevents duplicates, and ensures that when a lead moves from "Screened" to "Appointment Set," that transition is recorded with a timestamp in both kvCORE and your transaction management tool.
Second, it triggers automations at stage boundaries. When a lead reaches "Under Contract," the plugin can fire a task in your TC software, send a Slack notification to the listing coordinator, and start a document checklist — all without the agent doing anything beyond moving the stage in kvCORE. The agent's action becomes the system's trigger.
Third, it keeps reporting accurate. Because stage transitions now write to a log, the broker can pull a real pipeline report: how many leads are at each stage, how long they've been there, and where deals are stalling. This is the kind of operational visibility that most teams assume they have from kvCORE's built-in reporting, but rarely do.
The build sequence that works
Before writing a line of code, the right approach is an audit of the current pipeline. What stages do agents actually use, even informally? What triggers matter — what needs to happen when a lead reaches a given stage? What other tools need to know about a stage change? That audit usually takes one or two conversations with the team lead and the TC, and it surfaces the real requirements that a developer would otherwise have to guess at.
From there, the build is straightforward: configure kvCORE's webhook to fire on lead updates, set up a listener that maps incoming payloads to your stage logic, and connect the relevant downstream tools. For most teams, the integration involves a CRM update, a task trigger in a TC platform, and a notification to a messaging channel. The entire stack can be operational in under a week.
Real Estate AI Group's standard approach is to audit before building — mapping what the team actually does versus what the CRM currently records — so the plugin reflects the real workflow rather than an idealized version of it.
Keeping it maintainable
The failure mode for custom plugins is that they work perfectly for six months and then break when the team lead changes, an agent leaves, or kvCORE updates its webhook format. Build for that from the start: document the stage map, version the webhook handler, and write a simple health check that fires a test payload once a day and logs whether the downstream tools received it.
Ownership matters here. Any custom integration should write to a log your brokerage controls — not just to the third-party platform's activity feed. If something breaks or someone disputes a timeline, you need a record that isn't locked inside a vendor's interface.
Where to start
Pull your current kvCORE pipeline report and count how many leads have been sitting at the same stage for more than five days. If the number is more than 10 percent of your active pipeline, your stages aren't working. That number is the business case for a plugin — and it gives a developer a concrete target to measure against once the integration is live.