Case Study: How [Agent] Increased Showings with an Automated Scheduler

The Failure Point: Manual Lead Triage and Phone Tag

The agent’s lead management system was a combination of direct SMS, a cluttered email inbox, and a CRM that was updated whenever he remembered. Leads from Zillow and his own site would arrive at all hours. The process involved manually texting each lead, suggesting a few times for a showing, and waiting for a response. This round-trip communication could take anywhere from two to eight hours.

Anything that arrived after 9 PM was dead in the water until the next morning. By then, the lead had already clicked on three other properties and spoken to two other agents. The core problem wasn’t a lack of leads. It was the latency between lead acquisition and meaningful contact. Every hour of delay was a measurable drop in conversion probability.

Quantifying the Bleed

Our initial audit identified the primary metrics of failure. The agent was receiving approximately 150 new leads per month. Of these, around 30% never received a response within the first 12 hours, effectively becoming lost opportunities. Another 20% were lost during the back-and-forth of scheduling. The total lead leakage was approaching 50% before a single showing was even confirmed.

Double bookings were a constant issue, creating friction with potential buyers and forcing last-minute apologies. The agent estimated spending 10 to 15 hours per week just managing his calendar and chasing down replies. This was time that should have been spent on negotiation, client management, and closing deals. The system was broken, inefficient, and expensive in terms of lost commissions.

Case Study: How [Agent] Increased Showings with an Automated Scheduler - Image 1

Architecture of the Solution: A Centralized Logic Core

We rejected off-the-shelf solutions that promised an “all-in-one” fix. Those platforms create data silos and offer limited control over the logic. Instead, we designed a lean, event-driven system built around a central AWS Lambda function. This function would act as the traffic cop, ingesting data from multiple sources and routing it to the appropriate services with specific instructions.

The goal was to build a system that did not require the agent to change his primary tools. He would continue to use his existing CRM and calendar. The automation would operate in the background, bridging the gaps between these services. We didn’t want to add another dashboard for him to check. We wanted to make his existing tools smarter.

The Ingestion and Processing Workflow

The process begins the moment a lead submits a form on Zillow, Realtor.com, or the agent’s own WordPress site. These services are configured to fire a webhook with a JSON payload to a dedicated AWS API Gateway endpoint. The endpoint’s sole job is to trigger our primary Python Lambda function and pass the payload along.

The Lambda function executes the core logic:

Data Sanitization: The first step is to strip and normalize the incoming data. Different lead sources use different field names for ‘name’, ‘phone’, and ’email’. The function maps these variations to a standardized internal format. It also logic-checks for malformed phone numbers or invalid email formats.
CRM De-duplication: The function makes a GET request to the agent’s CRM API (in this case, Follow Up Boss) using the lead’s email or phone number. This prevents creating duplicate contacts. If a contact exists, the function pulls the contact ID. If not, it executes a POST request to create a new one and retrieves the new ID.
Dynamic Link Generation: With the contact’s information, the function constructs a unique Calendly scheduling link. We pass the lead’s name, email, and the property address they inquired about as URL parameters. This pre-fills the form on the Calendly page, reducing friction for the user.
Multi-Channel Dispatch: The function then makes two simultaneous API calls. One call to the Twilio API to send an immediate SMS to the lead with the personalized scheduling link. A second, parallel call to the SendGrid API sends a more detailed email with property information and the same link.

This entire sequence, from webhook ingestion to the lead receiving a text message, executes in under two seconds. It converted a multi-hour manual process into a near-instantaneous automated action.

Code Example: Stripping Webhook Data

The following is a simplified Python snippet demonstrating the initial data parsing and normalization logic within the Lambda handler. This isn’t the full production code, but it illustrates the core principle of mapping inconsistent source data to a clean, usable dictionary before any further processing occurs. It’s a defensive measure against API changes from lead providers.

import json


def lambda_handler(event, context):

    try:

        body = json.loads(event.get('body', '{}'))

    except json.JSONDecodeError:

        return {'statusCode': 400, 'body': 'Invalid JSON payload'}
    # Define mapping for different lead sources

    source_mappings = {

        'zillow': {'name': 'FullName', 'email': 'Email', 'phone': 'Phone'},

        'website': {'name': 'contactName', 'email': 'contactEmail', 'phone': 'contactPhone'}

    }
    # Identify the source (e.g., from a header or payload field)

    source_type = event.get('headers', {}).get('X-Lead-Source', 'website').lower()
    mapping = source_mappings.get(source_type, source_mappings['website'])
    lead_data = {

        'name': body.get(mapping['name']),

        'email': body.get(mapping['email']),

        'phone': body.get(mapping['phone']),

        'property_inquiry': body.get('propertyAddress', 'Not Provided')

    }
    if not all([lead_data['name'], lead_data['email'], lead_data['phone']]):

        # Logic to handle missing critical data

        return {'statusCode': 422, 'body': 'Missing required contact information'}
    # ... subsequent calls to CRM, Twilio, SendGrid APIs
    # This architecture is like using the serverless function as a high-speed data clutch,

    # engaging and disengaging between the lead source API and the CRM to prevent grinding gears.
    return {'statusCode': 200, 'body': 'Lead processed successfully'}

Case Study: How [Agent] Increased Showings with an Automated Scheduler - Image 2

Closing the Loop: Confirmation and Reminders

Once the lead selects a time in Calendly, the job is only half done. Calendly fires its own webhook back to a second, separate API Gateway endpoint. This triggers another Lambda function dedicated to post-booking logistics.

This second function performs these actions:

CRM Update: It updates the lead’s record in the CRM, adding a note with the confirmed showing date and time. It also changes the lead’s status from “New” to “Showing Scheduled.” This gives the agent immediate visibility without checking his email or calendar.
Calendar Event Creation: The function creates an event on the agent’s Google Calendar, complete with the property address, buyer’s name, and contact information.
Reminder Queue: The system queues up two automated reminders via Twilio: one 24 hours before the showing and another 1 hour before. This single step was critical in reducing the no-show rate.

The entire system is stateless. Each function executes its specific task and terminates. This makes it cheap to run and simple to debug. If the CRM update fails, it doesn’t stop the calendar event from being created. We built in logging to CloudWatch to track failures for each discrete step.

Results: Measurable Impact on Core KPIs

The transition from a manual to an automated system produced hard data within the first 30 days. We moved beyond anecdotal evidence of “feeling busier” to tracking specific, quantifiable improvements in the sales funnel. The results were not surprising, but the magnitude was.

The agent’s calendar became a tool for planning, not a source of constant negotiation.

Key Performance Indicators: Before and After

We tracked four primary metrics to validate the project’s success. The “Before” data is based on a 3-month average from the agent’s manual records and CRM history. The “After” data was pulled directly from API logs and the CRM over the first 60 days of the system being live.

Average Lead Response Time: This dropped from over 4 hours to an average of 1.8 seconds. The system eliminated the human delay entirely for the initial contact and scheduling offer.
Showings Scheduled per Month: Increased by 42%. By engaging leads instantly and providing a frictionless scheduling tool, we captured a significant portion of the leads that were previously lost to slow follow-up.
No-Show Rate: Decreased from approximately 25% to under 10%. The automated SMS reminders were directly responsible for this improvement, confirming appointments and reducing forgotten showings.
Agent Time Saved: The agent reported saving a minimum of 10 hours per week previously spent on scheduling logistics. This time was reallocated to higher-value activities like client follow-up and market analysis.

The cost of the API services (AWS, Twilio, Calendly) came to roughly $150 per month. Given the increase in closed deals directly attributable to the higher volume of showings, the return on investment was realized within the first month. The system paid for its annual operating cost with a single additional commission.

Case Study: How [Agent] Increased Showings with an Automated Scheduler - Image 3

System Fragility and Maintenance

This solution is not without its weaknesses. Its stability is entirely dependent on the consistency of third-party APIs. If a lead source changes its webhook payload structure without warning, the ingestion function will fail. If the CRM provider deprecates an API endpoint, the update logic breaks. The system is powerful but brittle.

Maintenance involves periodic checks of API documentation and monitoring CloudWatch logs for an increase in execution errors. The modular nature of the Lambda functions means a failure in one part of the system does not bring the entire thing down. This isolates points of failure, making troubleshooting a targeted process instead of a system-wide hunt.