Project Overview

A small US online store selling across three sales channels, their own website, a marketplace, and a third-party retail partner, was managing inventory entirely through manual spreadsheets. The owner spent the better part of each week reconciling numbers across platforms, and even then, the data was inconsistent enough that overselling and stockouts were a regular occurrence. We were brought in to replace that manual process with a lightweight ML system built on the data they already had.

The Challenge

The core problem was that the owner had no unified view of inventory. Each sales channel reported stock levels differently, with no automated sync between them. Orders placed on one channel would sometimes sell through inventory that was already committed elsewhere, triggering customer complaints and emergency restocking orders at poor margins.

• Inventory data was scattered across three platforms with inconsistent formatting and no shared product identifiers
• Reorder decisions were made manually based on gut feel and weekly spot-checks, with no predictive visibility
• Stockouts were only discovered after customers had already placed orders for unavailable items
• The owner had no data science background and no budget for technical staff to manage a complex system

Our Solution

We built a lightweight ML model trained on six months of the client's sales history that automated two things: predicting reorder points for each SKU across channels, and flagging low-stock risks 48 hours before a projected stockout. The solution connected directly to their existing sales channel data, requiring no new platforms or manual data entry from the owner.

• Data Unification Layer: We built a simple ETL pipeline that pulled inventory and order data from all three channels into a single normalized table, resolving inconsistent product naming and formatting across platforms.
• Demand Forecasting Model: A gradient boosted model trained on the client's own sales history, accounting for day-of-week patterns, promotional periods, and seasonal variation in their product categories.
• Automated Reorder Alerts: The model calculated dynamic reorder points per SKU and sent the owner an automated summary each morning flagging items projected to stock out within 48 hours, with a suggested reorder quantity.

Technical Approach

Given the absence of any technical staff on the client side, the system was designed for near-zero maintenance. The pipeline runs on a lightweight scheduled job that pulls data from each channel's API nightly, runs the forecasting model, and writes alert outputs to a simple dashboard the owner accesses each morning. No model retraining or intervention is required unless the product catalog changes significantly. We used Python with scikit-learn for modeling and built the pipeline to run on a low-cost cloud instance within the client's existing budget constraints.

Results and Impact

• Stockouts reduced significantly in the first two months following deployment, with the owner identifying and restocking at-risk items before they ran out
• Manual inventory tracking eliminated completely: the owner no longer maintains spreadsheets across channels
• 8 hours per week recovered that had previously been spent on manual reconciliation and reactive restocking
• 3 channels unified into a single inventory view for the first time in the business's history
• 48-hour advance warning on low-stock events gave the owner enough lead time to reorder before any customer-facing impact

Lessons Learned

The most important decision on this project was scoping the solution to match what the client could actually operate. A more sophisticated system with real-time sync and automated purchase orders would have been technically possible, but it would have introduced complexity the owner couldn't manage or troubleshoot independently. By keeping the output simple, a daily alert summary with clear reorder suggestions, we ensured the system got used consistently rather than abandoned when something unfamiliar appeared.

The data unification work also proved to be the most time-consuming part of the engagement, not the modeling. Getting three platforms with inconsistent SKU naming into a single clean table required more iteration than expected. For small businesses with data spread across multiple tools, that foundational step is almost always where the bulk of the early effort needs to go.

Project Overview

An early-stage US SaaS startup with a founding team of three was being overwhelmed by customer support volume. The same 40 questions accounted for 70 percent of all tickets, but the team had no system to identify, route, or respond to them efficiently. Tickets were piling up overnight with no one available, and the team was spending hours each day on support that was pulling them away from product and sales work. We built an ML classification model that changed how incoming tickets were handled from the moment they arrived.

The Challenge

The team was using a basic shared inbox with no tagging, routing, or prioritization. Every ticket required a human to read it, decide what it was, and find the right response. For a team of three doing everything, that overhead was unsustainable as the user base grew.

• No ticket categorization or routing in place: every message landed in a single queue in the order it arrived
• The same 40 questions made up 70 percent of total ticket volume, but responses were being written from scratch each time
• Tickets were piling up overnight and during weekends with no coverage and no automated handling
• The team needed something they could operate themselves, with no dedicated support staff and no ongoing technical help

Our Solution

We built an ML classification model that automatically tagged incoming tickets by category and urgency the moment they arrived, and pre-loaded suggested responses for the 40 most common issue types. The system was designed to be operated by non-technical founders without any ongoing maintenance from our side.

• Ticket Classification Model: A multi-label classifier trained on the startup's historical support ticket data, categorizing incoming tickets by issue type across categories including billing, onboarding, feature questions, and bug reports.
• Urgency Scoring: A secondary model component that assigned urgency flags based on signals in the ticket content, surfacing time-sensitive issues to the top of the queue automatically.
• Suggested Response Library: For each of the 40 most common issue categories, we built a template response that appeared pre-loaded in the agent interface when a ticket was routed to that category. The team could send, edit, or override at their discretion.
• Integration: The model was integrated directly into their existing helpdesk tool via API, requiring no new interface or workflow changes for the team.

Technical Approach

The classification model was built using a fine-tuned text classification approach on the client's historical ticket data, with categories defined collaboratively with the founders based on the issue types they dealt with most frequently. We used a lightweight transformer-based classifier that ran efficiently within the startup's budget constraints. The integration layer connected to their helpdesk via webhook, so classification and routing happened in real time as new tickets arrived, including overnight and on weekends when no one was available to triage.

Results and Impact

• First response time cut by 50 percent, as routine tickets were being auto-tagged and pre-loaded with suggested responses before any team member opened them
• 70 percent of incoming tickets auto-tagged correctly on arrival, eliminating the manual triage step for the majority of support volume
• Team focused exclusively on complex tickets that required genuine human judgment, with routine queries handled through the suggested response workflow
• Overnight and weekend ticket backlog eliminated, as classification and routing happened automatically regardless of when tickets arrived
• The founders were able to operate the system entirely independently after a brief handoff, with no ongoing technical management required

Lessons Learned

The most important design constraint on this project was that the team could not rely on us to maintain or troubleshoot the system after delivery. That shaped every decision, from choosing a simpler model architecture that was easier to inspect, to building the suggested responses as editable templates rather than automated replies. A fully automated response system would have been faster, but a suggested response that a founder reviews before sending was the right balance of efficiency and control for a team at this stage.

Defining the ticket categories collaboratively with the founders also turned out to be essential. Their intuition about how customers described problems was more accurate than any topic clustering we ran on the raw data. The categories we landed on through that conversation produced a significantly better training dataset than a purely data-driven categorization would have.

Overview

A small US medical clinic was losing revenue and wasting clinical capacity through a no-show rate running between 20 and 25 percent. Every missed appointment meant a slot that could not be filled on short notice, a clinician with unused time, and a patient who did not receive care they had scheduled. The clinic's existing response was a paralegal making blanket reminder calls the day before to every patient on the schedule. The calls helped at the margins but did not move the no-show rate meaningfully because every patient was treated as equally likely to miss regardless of their actual risk profile. We built a lightweight ML model trained on 18 months of their appointment data that predicted no-show probability for each upcoming appointment, allowing staff to direct their outreach effort toward the patients who actually needed it.

The Challenge

The clinic had a consistent no-show problem with no structured way to distinguish which patients were genuinely at risk from those who were reliably on time. Blanket outreach consumed staff time without producing meaningful improvement.

• No-show rate of 20 to 25 percent consistently across all appointment types
• Blanket reminder calls consuming staff time with no differentiation between high and low risk patients
• No visibility into which patient segments or appointment types drove the majority of no-shows
• Small clinic with limited historical data compared to a large hospital system, requiring a model approach that worked with the data available
• Patient data required HIPAA-compliant handling throughout the entire project

Our Solution

We built an ML prediction model trained on the clinic's appointment history that scored each upcoming appointment by no-show probability, enabling the team to concentrate outreach on the patients most likely to miss rather than calling everyone on the schedule.

• Data Audit and Preparation: We pulled 18 months of appointment records including show and no-show outcomes, appointment type, time of day, day of week, lead time between booking and appointment, and reminder response history.
• Feature Engineering: We identified the variables most predictive of no-show behavior in this specific clinic's patient population.
• Prediction Model: A lightweight ML model trained on the prepared dataset producing a no-show probability score for each upcoming appointment.
• Automated Flagging: Appointments above the risk threshold were flagged automatically for a second outreach touchpoint 48 hours before the appointment.
• HIPAA-Compliant Handling: Data anonymization during model development and secure integration with the clinic's scheduling system ensured compliant handling throughout.

Technical Approach

The model was built in Python using a gradient boosting approach which performed best on the clinic's tabular appointment data during cross-validation testing. Feature importance analysis revealed that lead time between booking and appointment date, prior no-show history, and appointment type were the three strongest predictors in this clinic's dataset. The model was integrated with the clinic's scheduling software via a lightweight API that ran the prediction each morning for appointments in the next 48 to 72 hours, writing risk scores back to the scheduling system and triggering the automated secondary outreach workflow for flagged appointments.

Results and Impact

Deployment produced measurable improvement across the clinic's scheduling operation within the first 60 days.

• No-show rate reduced measurably in the first 60 days following deployment
• Schedule utilization improved as fewer appointment slots went unfilled
• Staff reminder call time reduced because outreach was concentrated on flagged high-risk appointments rather than the full schedule
• Revenue per clinical day improved as the no-show reduction translated directly into more completed appointments
• Feature importance analysis identified two appointment types that drove a disproportionate share of no-shows, which the clinic used to redesign their booking confirmation process for those specific appointment categories

Lessons Learned

The feature importance analysis was one of the most valuable outputs of the project beyond the model itself. Knowing which variables drove no-show behavior gave the clinic operational insights they could act on independently of the ML system. The finding that two specific appointment types drove a disproportionate share of no-shows led the clinic to redesign their confirmation messaging for those categories, a change that did not require any AI system to implement and that contributed to the overall improvement in schedule utilization. The best ML projects often produce insights that create value beyond the model itself.

Project Overview

A US subscription box company had a churn problem it could not see coming. Customers were cancelling without warning, and by the time the team found out, the window to retain them had already closed. Winback campaigns were being sent after cancellation, which converted at a fraction of the rate of a well-timed pre-cancellation offer. The team wanted to flip that model: identify at-risk customers early, while there was still time to act. We built a churn prediction model on their existing Shopify and email engagement data that gave them that window.

The Challenge

Subscription churn is a lagging signal by nature. Customers signal their dissatisfaction through behavior weeks before they cancel, but those signals are subtle and scattered across different tools. Without a system to read and combine them, the team had no way to distinguish a customer who was about to leave from one who was just quietly engaged.

• No visibility into which customers were at risk until after the cancellation had already occurred
• Retention efforts were entirely reactive: winback campaigns sent post-cancellation rather than pre-cancellation outreach
• Behavioral data existed in Shopify and email engagement logs but had never been combined into a churn signal
• The team had no data science capability in house and needed a solution that integrated with tools they already used without requiring technical management on their end

Our Solution

We built a churn prediction model trained on the client's Shopify transaction history and email engagement data that flagged at-risk customers two weeks before their likely cancellation date. When a customer crossed the risk threshold, a targeted retention offer was triggered automatically through their existing email tool, shifting the team from reactive winback to proactive retention.

• Feature Engineering: We combined Shopify order data with email engagement metrics, including open rates, click-through rates, and engagement recency, to build a behavioral signal set that captured early churn indicators. Features included order frequency changes, days since last engagement, product category shifts, and subscription tenure.
• Churn Prediction Model: A binary classification model trained on historical subscription data, calibrated to predict cancellation likelihood within a two-week horizon at a level of confidence sufficient to act on without triggering too many false positives.
• Automated Retention Trigger: When a subscriber crossed the risk score threshold, an automated retention offer was sent through the client's existing email marketing platform via API integration, requiring no manual intervention from the team.

Technical Approach

The model was built using gradient boosted classification on the combined behavioral dataset, with a training set constructed from historical subscribers whose cancellation outcomes were known. The risk score threshold was calibrated conservatively so that the retention offers were being sent to genuinely at-risk customers rather than a broad swath of the subscriber base, which kept offer costs controlled and maintained the perceived value of the retention offer for recipients. Integration with the email platform was handled via API, keeping the system within tools the team already operated daily.

Results and Impact

• Retention rate improved in the period following deployment, with at-risk customers receiving timely outreach before their likely cancellation date rather than after
• Two weeks of advance warning provided enough lead time for a targeted retention offer to land before the customer had made a final decision to cancel
• Proactive outreach replaced reactive winback as the primary retention mechanism, shifting from a low-conversion post-cancellation campaign to a higher-conversion pre-cancellation offer
• The system required no ongoing technical management from the client's team after deployment and integrated fully with tools they were already using
• At-risk customers were identified early enough that the team had time to test different offer types and messaging, creating a feedback loop for retention optimization over time

Lessons Learned

The most consequential design decision was the risk score threshold. Set too low, the model flags a large proportion of the subscriber base and the retention offer loses its targeted value. Set too high, genuinely at-risk customers are missed. We worked with the client to define what a false positive cost them in offer discount versus what a missed at-risk customer cost them in lost subscription revenue, and calibrated the threshold accordingly. That economics-based calibration produced a much more useful model than optimizing for statistical accuracy alone.

The two-week prediction horizon was also a deliberate choice. A longer horizon would have produced more noise. A shorter one would not have given the team enough time to act. Testing different horizon lengths against the client's historical data confirmed that two weeks was the point where predictive signal was strongest and operational lead time was sufficient, which is not always the same answer for every subscription business.