In the context of the internet industry, "algorithms" are often endowed with excessive imagination: they seem capable of improving efficiency, balancing fairness, eliminating redundancy, enhancing user experience, and even reshaping the order of an entire industry.
However, for startups or early-stage (0 to 1) projects, this imagination often outpaces reality. Resources are limited, data is scarce, development capabilities are constrained, and the business itself is in a constant state of trial and error and iteration.
At this point, overly complex algorithms not only fail to bring greater 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 but important truth: A startup project does not need to pursue a "perfect scheduling system," but rather a rule system that is sufficiently stable, explainable, 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 is necessary to outline the realistic background of the business.
The client for this project is a traditional hospital logistics service company, primarily offering services such as patient care, cleaning, and transportation. Essentially, it is a typical offline operations-driven enterprise without an internet gene:
- No experience in online operations;
- Internal systems rely on manual scheduling;
- Limited informatization, with discontinuous and non-standard data collection;
- Not a fully internet-based business, with no need for internet traffic operations;
- Management's understanding of algorithms and rule systems comes more from intuition than from model-based thinking.
This means that any complex algorithm cannot be truly implemented, not because the algorithm is not advanced enough, but because the organization itself cannot handle such complexity. Therefore, the first prerequisite for designing a dispatch system is not "can it be done," but "can the client use it, maintain it, and understand it?"
Given such organizational capabilities, over-designing not only fails to improve efficiency but also makes business implementation more difficult.
Only by respecting the realistic boundaries of operational capabilities can algorithms move beyond being paper solutions and become systems that truly operate within hospitals.
Moreover, this information is not something the client will proactively provide; it must be discovered during the process of communicating requirements and must be a key consideration in business design.
Throughout the collaboration with ChatGPT to design the algorithm, I consistently adhered to two simple but often overlooked principles: usability and cost awareness.
Usability means two things:
- The algorithm must be quickly implementable within the 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 awareness is equally critical:
- On one hand, control development costs and future technical maintenance costs;
- On the other hand, avoid the algorithm imposing additional burdens on operations, 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 startups and determine whether the algorithm can ultimately enter the production environment.
Unnecessary complexity: The "good-looking solutions" I rejected on the spot
In the back-and-forth discussions with ChatGPT, some seemingly reasonable advanced methods were quickly rejected by me. The reason is not complicated: they looked good but were useless and unnecessary. They did not bring positive returns to the business but instead increased technical and operational costs.
ChatGPT's proposed "smarter" solution: A dual smoothing model of distance and ratings
Initially, ChatGPT offered a seemingly standardized suggestion:
- Use a distance-based smoothing algorithm to give higher weight to those closer to the order location;
- Use a refined scoring based on user ratings to more accurately reward or penalize individuals with different performance levels;
This is a typical scheduling framework in urban delivery scenarios, but in my business, it was entirely "misaligned design."
- Distance-based scheduling: Meaningless in a hospital setting and increases costs
I quickly rejected the distance-based matching solution for three reasons:
- The hospital space is small, enclosed, and fixed: There is no need to calculate differences of two or three kilometers like in food delivery. Within a hospital building, 20 meters and 80 meters make little difference;
- Service personnel do not move between hospitals: There is no cross-city or cross-region scheduling, so there is no need to "select the optimal location";
- Introducing distance means additional system costs: It requires integrating geographic location data, continuously collecting coordinates, handling positioning errors, and maintaining map data.
The distance algorithm looks good but generates no business value, only increasing data and development costs.
- "Over-precision" based on user ratings: Too small a sample, meaningless
Another solution was a rating-driven weighting system, such as:
- Considering the historical proportion of five-star ratings;
- Introducing a complaint decay coefficient;
- Building a service scoring model;
This was also rejected by me. Because the platform is small, with a limited number of service providers:
- Small sample → High data noise;
- Small differences → Refined scoring cannot truly differentiate;
- Occasional complaints → Can lead to model misjudgment;
- High precision → High operational costs, requiring explanation, review, and adjustment.
At this scale, implementing complex scoring is meaningless. Precision is not the goal; control is the goal.
These "rejected advanced solutions" share a common characteristic:
They are more designed to showcase technical capabilities than to solve business problems.
And this is precisely the trap that startups or early-stage projects are most likely to fall into.
Complexity is not the answer; survival is the first principle
Mature platforms often rely on massive amounts of data to train models, use dynamic scheduling systems to predict supply and demand changes, and fine-tune strategies within minute-level 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 care, medical transportation, and cleaning services are essentially labor-intensive services. The goal of scheduling is not precise prediction but reducing waiting times, avoiding extreme situations, and maintaining service quality stability. Rather than building a refined model, it is better to ensure that the most basic rules do not go wrong.
Three core goals form the real constraints of the algorithm
In all dispatch discussions, we always circled back to the same three goals:
- Efficiency: Are orders promptly accepted and executed?
- Fairness: Will newcomers be left without orders for long periods due to system bias?
- Quality: Can service personnel maintain basic standards and avoid accidents and complaints?
An effective dispatch system does not aim to achieve the extreme in each goal but ensures that the tension among the three 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 time being prolonged.
The so-called "algorithm" is more about making the trade-offs among these three adjustable and explainable, rather than deriving an unaccountable score through a mysterious model.
Replacing "complexity" with "explainability"
We initially discussed a seemingly clever fairness adjustment method: penalizing service providers whose order count in the past seven days is significantly higher than the average to avoid monopolization. At first glance, it seemed reasonable, but it quickly exposed several issues:
- The average is structurally pulled up by high-activity individuals, worsening the situation for low-activity ones;
- Linear adjustment cannot reflect the real difference between newcomers (zero orders) and moderately active individuals;
- The formula is complex, making it difficult for the business side to understand and explain to service providers;
- For early-stage businesses with small order volumes and high volatility, such a strategy can produce counterproductive effects.
These issues are not technical challenges but a natural conflict between the "early-stage business environment" and "complex algorithm logic." The insight we ultimately gained was: Algorithms should not exceed the actual maturity of the business.
Thus, fairness adjustment was simplified into a milder and more understandable nonlinear weight:
- Newcomers receive gentle support;
- Moderately active individuals maintain normal status;
- Highly active individuals are slightly weakened but not overly intervened;
It does not pursue mathematical elegance but possesses true 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 (idle or not, timeout or not, skill match or not)
Its advantage lies not in "intelligence" but in:
- All weights can be directly understood and adjusted by the business side;
- It does not require large amounts of historical data or model training;
- Anomalies can be quickly located;
- It can evolve gradually with business growth rather than being fixed at once;
- It is extremely friendly to small-scale businesses.
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 an unexplainable deep water and make the system fragile.
A straightforward and clear dispatch process is as follows:
- Order triggered
- Filter candidates with matching skills and reasonable distance
- Calculate Score ranking
- Push the order to the highest scorer first
- If timeout without acceptance, push to the next candidate sequentially
This is the most implementable and robust scheduling 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 realistic perspective: A system that can run is more valuable than a dream system
Ultimately, the inspiration from this dispatch algorithm goes beyond the scheduling system itself; it is a re-examination of the design approach for startup products:
Do not pursue the "ceiling" of technology, but focus on whether the "floor" of the business is solid.
What a startup project needs is not the "most advanced algorithm in the industry" but the solution that best reduces risk, minimizes friction, can be quickly implemented, 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 thing to adhere to is a realistic restraint. Technology should serve the real business, not become an obstacle to business advancement.
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 be maintained.