In the context of the internet industry, "algorithms" are often imbued with excessive imagination: they seem capable of solving efficiency issues, balancing fairness, eliminating redundancy, enhancing user experience, and even reshaping the order of an entire industry.
However, for startups or projects in the 0-to-1 phase, this imagination often outpaces reality. Resources are limited, data is scarce, development capabilities are constrained, and the business itself is constantly undergoing trial, error, and iteration.
In such situations, overly complex algorithms not only fail to bring higher certainty but instead become internal friction that hinders decision-making and product advancement.
Recently, I used AI to design a dispatch algorithm for a hospital logistics service platform. During my collaboration with ChatGPT, I gradually realized a simple yet crucial truth: a startup project does not need to pursue a "perfect scheduling system"; rather, it needs a rule-based system that is sufficiently stable, interpretable, maintainable, and can be implemented in the shortest possible time.
Complexity is not the answer; principles come before algorithms.
Before delving into algorithm discussions, it's necessary to outline the practical business context.
The client for this project is a traditional hospital logistics service company, primarily offering offline services like patient companionship, cleaning, and transportation. Essentially, it is a typical offline operation-driven enterprise without inherent internet DNA:
- No online operation experience;
- Internal systems rely on manual dispatching;
- Limited informatization, with discontinuous and non-standardized data collection;
- Not a fully internet-based business, so there's no need for internet traffic operations;
- Management's understanding of algorithms and rule systems stems more from intuition than from a model-based mindset.
This means any complex algorithm cannot truly be implemented—not because the algorithm isn't advanced enough, but because the organization itself cannot handle such complexity. Therefore, the primary premise for designing a dispatch system is not "whether it can be done," but "whether the client can use it, maintain it, and understand it."
Given this baseline of organizational capability, over-engineering not only fails to improve efficiency but makes business implementation more difficult.
Only by respecting the realistic boundaries of operational capabilities can algorithms break free from being mere paper solutions and become systems that truly function within the hospital.
This information is not something the client proactively provides; it needs to be discovered during communication about requirements and must be a key consideration in business design.
During my collaboration with ChatGPT in designing the algorithm, I consistently adhered to two simple yet often overlooked principles: usability and cost-consciousness.
Usability means two things:
- The algorithm must be quickly implementable under existing organizational capabilities and technical conditions;
- The operations team must be able to understand, master, and maintain it, rather than being "held hostage" by complex rules.
Cost-consciousness is equally critical:
- On one hand, control development costs and future technical maintenance costs;
- On the other hand, avoid imposing additional burdens on operations through the algorithm, such as excessive reliance on metric collection, data cleaning, or manual intervention.
These two principles are essentially a realistic respect for the limited resources of a startup, and they determine whether the algorithm can ultimately enter the production environment.
Unnecessary Complexity: Those "Good-Looking Solutions" I Immediately Rejected
During the back-and-forth discussions with ChatGPT, some "seemingly reasonable" advanced methods were quickly rejected by me. The reason is simple: they look good but are useless and unnecessary. They do not bring positive returns to the business; instead, they increase technical and operational costs.
A "Smarter" Solution Proposed by ChatGPT: A Dual-Smoothing Model of Distance + Ratings
Initially, ChatGPT offered a suggestion that sounded quite standard:
- Use a distance-based smoothing algorithm to give higher weight to personnel closer to the order location;
- Use fine-grained scoring based on user ratings to more accurately reward or penalize individuals based on performance;
This is a typical dispatch framework common in urban delivery scenarios, but in my business context, it was entirely a "mismatched design."
- Distance-Based Dispatching: Meaningless for Hospital Scenarios and Adds Cost
I quickly rejected the distance-based matching scheme for three reasons:
- Hospitals are small, enclosed, and fixed spaces: There's no need to calculate differences of two or three kilometers like in food delivery; within a hospital building, 20 meters versus 80 meters makes little difference;
- Service personnel do not move across hospitals: There is no cross-city or cross-region dispatching, so there's no need to "choose the optimal location";
- Introducing distance means additional system costs: Need to integrate geolocation data, continuously collect coordinates, handle positioning errors, and maintain map data.
Distance algorithms look good but do not generate business value; they only increase data and development costs.
- "Overly Precise" User Rating-Based Weighting: Sample Size Too Small, Meaningless
Another proposal was a user rating-driven weighted system, for example:
- Consider historical five-star rating proportions;
- Introduce complaint decay coefficients;
- Build a service scoring model;
This was also rejected by me. Because the platform is small, with a limited number of service providers:
- Small sample size → high data noise;
- Small differences → fine-grained scoring cannot truly create meaningful gaps;
- Occasional complaints → can lead to model misjudgments;
- High precision → high operational costs, requiring explanation, review, and adjustment.
At this scale, complex scoring is meaningless. Precision is not the goal; controllability is.
These "rejected advanced solutions" share a common trait:
They seem more designed to showcase technical capability than to solve business problems.
And this is precisely the pitfall that startups or startup projects are most prone to falling into.
Complexity is not the answer; survival is the first principle.
Mature platforms often rely on massive data to train models, use dynamic scheduling systems to predict supply and demand changes, and fine-tune strategies within minute-level time windows. For startup projects, such solutions have almost no realistic foundation.
More importantly, the business's need for "perfect matching" is far less urgent than imagined. Scenarios like hospital patient companionship, medical transportation, and cleaning services are essentially labor-intensive services. The goal of dispatching is not precise prediction but reducing wait times, avoiding extreme situations, and maintaining service quality stability. Rather than building intricate models, it's better to ensure the most basic rules don't fail.
Three Core Objectives Form the Real Constraints of the Algorithm
In all dispatch discussions, we consistently circled back to the same three objectives:
- Efficiency: Are orders accepted and executed promptly?
- Fairness: Will newcomers be left without orders for extended periods due to system bias?
- Quality: Can service personnel maintain basic standards, avoiding accidents and complaints?
An effective dispatch system does not aim to maximize each objective but ensures the tension between them remains controllable. What a startup project fears most is a single-point imbalance—for example, high efficiency but severe monopolization, or strong fairness but overall completion times being dragged out.
The so-called "algorithm" is more about making the trade-offs between these three adjustable and explainable, rather than deriving an unaccountable score through a mysterious model.
Replacing "Complexity" with "Explainability"
We initially discussed a seemingly sophisticated fairness adjustment method: penalizing service providers whose order counts in the past seven days were significantly above average to avoid monopolization. It seemed reasonable at first glance but quickly revealed several issues:
- The average would be structurally inflated by highly active individuals, worsening the situation for less active ones;
- Linear adjustments cannot reflect the real differences between newcomers (0 orders) and moderately active individuals;
- The formula is complex, making it difficult for business stakeholders to understand and explain to service providers;
- For early-stage businesses with small order volumes and high volatility, such a strategy is prone to backfiring.
These issues are not technical problems but natural conflicts between the "early-stage business environment" and "complex algorithm logic." The final insight we gained was: Algorithms should not surpass the actual maturity of the business.
Thus, fairness adjustment was simplified into a more moderate and easier-to-understand nonlinear weighting:
- Newcomers receive gentle support;
- Moderately active individuals maintain normal status;
- Overly active individuals are slightly weakened but not excessively intervened;
It does not pursue mathematical elegance but possesses genuine usability.
A "Startup-Level" Minimum Viable Dispatch Model (MVP)
The final algorithm structure is almost simplistic but highly flexible:
Score = W1 * (1 / ETA) + W2 * Service Quality Score + W3 * Fairness Adjustment Coefficient + W4 * Real-time Status (whether idle, whether overtime, whether skills match)
Its advantage lies not in "intelligence" but in:
- All weights can be directly understood and adjusted by business stakeholders;
- No need for large amounts of historical data or model training;
- Ability to quickly locate issues when anomalies occur;
- Can evolve gradually with business growth rather than being solidified all at once;
- Extremely friendly to small-scale operations.
In the real world, such simple models are often more operable than seemingly "smart" complex solutions.
The Essence of the Dispatch Process is "Flattened Decision-Making"
If the algorithm determines "how to score," then the dispatch process determines "how to execute." Overly complex scheduling processes push rules into the deep waters of inexplicability and make the system fragile.
A direct, clear dispatch process is as follows:
- Order triggered
- Filter candidates with matching skills and reasonable distance
- Calculate Score and sort
- Push the order to the highest-scoring candidate first
- If not accepted within timeout, push to the next candidate in sequence
This is the most implementable and robust dispatch chain for a startup project. It may not be perfect, but it is reliable enough, transparent enough, and easy enough to maintain, avoiding the accumulation of technical debt.
Designing from a Realist Perspective: A System That Works is More Valuable Than a Dream System
In the end, the insights from this dispatch algorithm extended beyond the scheduling system itself, leading to a re-evaluation of startup product design approaches:
Do not pursue the "ceiling" of technology, but focus on whether the "floor" of the business is solid.
Startup projects do not need the "most advanced algorithm in the industry"; they need the solution that best reduces risk, minimizes friction, is quickly implementable, and aligns with operational reality. Only when the business truly enters a phase of scaled growth does complexity become meaningful.
Until then, the most worthwhile stance is one of realist restraint. Technology should serve the real business, not become an obstacle to business progress.
This approach is not only applicable to hospital O2O but also to other early-stage service-oriented startup projects. As the business grows, the algorithm can be gradually optimized, but the core principles should always remain.