Post-demo decision path
After a broker understands the public Rising Hills site and private Lead Hub, the next move is not more explanation. It is choosing the first launch track, collecting the right inputs, and turning the conversation into a scoped proposal.
Proposal tracks
A brokerage that wants to prove AIRES with one community, neighborhood, listing campaign, or model-home workflow.
A team that wants the first launch plus agent pages, agent portal rollout, Smart Lists, stronger reporting, and repeatable routing.
A brokerage that wants AIRES to become the reusable operating layer across multiple communities, teams, events, and CRM workflows.
Decision inputs
Which one community, listing campaign, agent team, registration event, or brokerage workflow should prove the system first?
Who can approve the build package, support tier, timeline, public-site content, Hub access, and CRM/export path?
What should the first launch prove: more captured inquiries, faster routing, cleaner follow-up, better event registration, or broker accountability?
Should launch start with broker dashboard, CSV export, saved preset, CRM handoff job, webhook/API planning, or weekly report?
Is this a broker-only workflow first, or should agents receive their own profiles, portals, queues, and listing tools on day one?
Does the client need Core Operations support, Scale & Agent Growth support, or a larger custom rollout cadence?
Close sequence
Pick Community Launch, Brokerage Growth, or Multi-Community OS based on the first proof point.
Use the launch-intake form and First Launch Plan to gather brand, roster, listing, routing, CRM, and support details.
Use the Proposal Builder preset that matches the selected track, then adjust price range, modules, timeline, and assumptions.
Schedule a scope review with the decision owner and define what is needed to approve the first milestone.
Approval packet
This is the bridge between a strong demo and a sendable proposal. Each item should have an owner, a decision, and a proof point before the final package goes out.
Decision: Community Launch, Brokerage Growth, or Multi-Community OS.
Proof: Match the package to the smallest public site plus Hub workflow that proves value.
Decision: Core Operations, Scale & Agent Growth, or custom enterprise support.
Proof: Confirm monthly hosting, maintenance, updates, and response expectations before proposal send.
Decision: CSV export first, saved export preset, queued handoff job, webhook, or API sync discovery.
Proof: Use the CRM worksheet to capture fields, credentials, sample data, and failure-handling needs.
Decision: Who gets owner, broker admin, reviewer, team, and agent access on day one.
Proof: Named Hub accounts replace shared demo access after session login proof and client approval.
Decision: Registrations captured, routed leads, follow-up speed, agent accountability, or reporting clarity.
Proof: Tie the first launch to one metric that can be reviewed in the Broker Dashboard.
Decision: Scope review date, milestone approval, launch target, and post-launch check-in.
Proof: The proposal should close with the exact next meeting and what must be provided before build setup.
Send-ready output
One selected track with initial build range, included modules, and monthly support tier.
Community story, roster, listing links, routing rules, CRM/export needs, access roles, and timeline.
Proposal Builder summary, print/PDF view, follow-up email, and decision-owner ask.
Client-safe guide, First Launch Plan, CRM worksheet, and protected Hub screen-share plan.
Common decision points
No. The first launch can use broker dashboard plus CSV/export. API or webhook sync can come later once fields, credentials, and failure handling are clear.
No. Start curated: listing links, community story, and high-quality calls to action. IDX/MLS can be scoped later if it materially improves the workflow.
The first agent rollout should be small and focused: their own leads, tasks, profile, and featured links, without exposing global brokerage settings.
AIRES is structured as a reusable client layer: branding, modules, feature flags, agents, routing, support package, and roadmap live as repeatable operating controls.
Follow-up generator
Choose the recommended track, add the client context, and copy a polished follow-up with the right links and next-step ask.
Recommended next move
The post-demo follow-up should name the recommended track, ask for the launch inputs, and schedule the proposal review. That keeps AIRES positioned as a system they can approve, not a neat demo they might revisit later.