Why does Swiggy say my restaurant is unserviceable from a customer’s location?

Swiggy calls this serviceability, and it has published how the system works in more detail than any other platform here, which restaurant operators can use directly. Swiggy’s own engineering blog describes a customer being told “This restaurant is unserviceable from your location” and then explains why: the Serviceability System filters restaurants by proximity, computes the real route distance rather than a straight line, checks whether the delivery fleet has capacity, and predicts the delivery time, all before deciding whether to show your restaurant at all.

The source is Swiggy Bytes, the company’s technology blog, in a post called “What Serviceability means at Swiggy?” published in December 2020. It is engineering writing rather than partner documentation, so treat the mechanism as described by the people who built it and the current parameters as unstated. What follows is what Swiggy says its system does, not a claim about today’s thresholds.

What is Swiggy’s Serviceability System responsible for?

Six things, and Swiggy lists them. Filtering outlets by geographical proximity to the customer, “Calculating the actual route distance between the restaurants/store/outlet to the customer location in order to check if the distance is feasible to deliver or not”, making a capacity check on the delivery fleet, predicting and promising the delivery time upfront, determining surge pricing, and then “Making the final decision if the restaurant or the store can be displayed on the customer app based on the delivery feasibility determined by various factors such as distance, delivery time and stress.”

Read that last item carefully, because it is the whole page in one sentence. On Swiggy, whether your restaurant is displayed is an output of a delivery feasibility calculation. Not of your opening hours, not of your menu, not of a radius you set. Three named inputs, distance, delivery time and stress, decide whether a given customer is shown your restaurant at a given moment, and two of those three change during the evening.

Does Swiggy use a circle around the restaurant?

No, and it explains why not. Swiggy describes the obvious approach, “drawing an imaginary circle of a X radius around the customer location”, and then rejects it: “a major drawback of the above approach is that it lacks directionality during GeoFiltering. Directionality during GeoFiltering would allow to have controlled, granular and well-defined boundaries of delivery, defined based on diverse geographical and operating conditions.” What it uses instead is polygons: “the Serviceability system determines the customer cluster by marking a point-in-polygon search for the customer location, and then from there it does a directional discovery of target clusters of restaurants and stores.”

Distance is then measured properly rather than approximated. Swiggy states that “The distance calculation here is not ‘as a crow flies’ calculation, but it is the actual route distance which will be travelled by the Delivery Partner”, computed on Open Street Maps data with Google Directions as a secondary source. It also gives the reason a global number would not work, comparing “making a 4-kilometre delivery in a light traffic road network in Ahmedabad” with “a 4-kilometre delivery in a heavy traffic road network in Bangalore”. The same kilometre buys different reach in different cities, which is why the maximum distance is not a constant.

What happens on Swiggy when demand outruns the fleet?

The map narrows on purpose, and Swiggy has a name for it. The blog describes a stress system that tracks the demand to rider ratio in each zone in real time and then “notifies the serviceability and other systems whenever the delivery fleet is under stress to gracefully degrade their respective services.” The concrete behaviour is spelled out: “under stress the Serviceability system would avoid taking up orders which have longer last miles or higher delivery times, depending on the magnitude of the stress, to prevent accumulation of further stress.”

Longer last miles are the first thing dropped. That is the mechanism behind the pattern operators describe as their outer districts going quiet at exactly the hours they were counting on. Swiggy also names the triggers, and they are not only demand: “There are also external factors like rains, festivals, natural calamities which cause the Delivery Partners to operate under a stress scenario.” The system is modelled as a state machine, “with nodes representing the stress levels and the edges representing the transitions between those states”, and it recovers on its own, relaxing “the services back to normal levels again” once supply and demand rebalance.

Why does the delivery time Swiggy quotes matter for coverage?

Because the prediction is an input to the display decision, not just a label on it. Swiggy says the predicted time to deliver is “One of the most important factors while determining the Serviceability of a restaurant or the store and also to commit on a delivery time promise to the customer”, and lists what feeds it: “delivery fleet parameters, store and restaurant factors, route distance and traffic scenarios”. Your kitchen’s own behaviour is inside that calculation, which means your prep performance can affect whether distant customers are offered you at all.

Swiggy also explains why it cannot simply pad the number. If the real time greatly exceeds the promise “it ruins the customer expectations and experience”, but if the predicted time is much higher than reality “the customer might not even place an order with the restaurant or the store due to wrong expectations.” So the platform is pushed towards accuracy from both sides, and an accurate quote for a far customer during a stressed evening is a long quote, which suppresses the order even where serviceability held.

Is a Swiggy coverage gap ever the restaurant’s fault?

Rarely in the way operators assume, but not never. Nothing in Swiggy’s description gives a restaurant a delivery area to configure, so there is no radius setting to have got wrong. What a restaurant does influence is the store side of the delivery time prediction, since Swiggy names “store and restaurant factors” as an input, and the outlet’s own location data, since the whole calculation begins from a point in a polygon.

Everything else described in that post belongs to Swiggy: the polygons, the route distance engine, the fleet capacity check, the stress state machine and the final display decision. An operator arguing about coverage on this platform is arguing about a system, not about a setting, and the only useful currency in that conversation is dated observations of what real customers at real addresses were offered.

How do you observe Swiggy serviceability from outside?

By asking the app the same question a customer asks, from the addresses that matter, at the hours that matter. Swiggy has told you that stress degrades serviceability from the longest last miles inward, so a reading taken on a quiet weekday afternoon shows a map you do not have on Friday night. Reading only the quiet hours is the commonest way operators convince themselves nothing is wrong.

Record the quoted delivery time next to the yes or no, since Swiggy places both under the same system, and repeat the reading so that a stressed evening and a permanently lost district stop looking alike. Capturing availability and quoted wait together, at hours you choose rather than hours averaged across the week, is what Kitchain (kitchain.co) Coverage does at kitchain.co. Our fuller profile of the platform is at https://kitchain.co/aggregators/swiggy/.