Why restaurant food delivery is more sustainable than grocery delivery

I’ve ranted a fair bit about both grocery and restaurant delivery on this blog. I’ve criticised the former on grounds that it incurs both inventory and retail transportation costs, and the latter because availability of inventory information is a challenge.

In terms of performance, grocery delivery companies seem to be doing just fine while the restaurant delivery business is getting decimated. Delyver was acquired by BigBasket (a grocery delivery company). JustEat.in was eaten by Foodpanda. Foodpanda, as this Mint story shows, is in deep trouble. TinyOwl had to shut some offices leading to scary scenes. Swiggy is in a way last man standing.

Yet, from a fundamentals perspective, I’m more bullish on the restaurant delivery business than the grocery delivery business, and that has to do with cost structure.

There are two fundamental constraints that drive restaurant capacity – the capacity of the kitchen and the capacity of the seating space. The amount of sales a restaurant can do is the lower of these two capacities. If kitchen capacity is the constraints, there is not much the restaurant can do, apart from perhaps expanding the kitchen or getting rid of some seating space. If seating capacity is the constraint, however, there is easy recourse – delivery.

By delivering food to a customer’s location, the restaurant is swapping cost of providing real estate for the customer to consume the food to the cost of delivery. Apart from the high cost of real estate, seating capacity also results in massive overheads for restaurants, in terms of furniture maintenance, wait staff, cleaning, reservations, etc. Cutting seating space (or even eliminating it altogether, like in places like Veena Stores) can thus save significant overheads for the restaurant.

Thus, a restaurant whose seating capacity determines its overall capacity (and hence sales) will not mind offering a discount on takeaways and deliveries – such sales only affect the company kitchen capacity (currently not a constraint) resulting in lower costs compared to in-house sales. Some of these savings in costs can be used for delivery, while still possibly offering the customer a discount. And restaurant delivery companies such as Swiggy can be used by restaurants to avoid fixed costs on delivery.

Grocery retailers again have a similar pair of constraints – inventory capacity of their shops and counter/checkout capacity for serving customers. If the checkout capacity exceeds inventory capacity, there is not much the shop can do. If the inventory capacity exceeds checkout capacity, attempts should be made to sell without involving the checkout counter.

The problem with services such as Grofers or PepperTap, however, is that their “executives” who pick up the order from the stores need to go through the same checkout process as “normal” customers. In other words, in the current process, the capacity of the retailer is not getting enhanced by means of offering third-party delivery. In other words, there is no direct cost saving for the retailer that can be used to cover for delivery costs. Grocery retail being a lower margin business than restaurants doesn’t help.

One way to get around this is by processing delivery orders in lean times when checkout counters are free, but that prevents “on demand” delivery. Another way is for tighter integration between grocer and shipper (which sidesteps use of scarce checkout counters), but that leads to limited partnerships and shrinks the market.


It is interesting that the restaurant delivery market is imploding before the grocery delivery one. Based on economic logic, it should be the other way round!

To app or not to app

The difference between using an app and a website is in terms of the costs. The app reduces the per-transaction cost, thanks to customisations and additional user information it possesses. There is a fixed cost in using the app, though, in terms of time, memory and bandwidth incurred in installing it, and user data that the app collects.

The costs of using an app versus using a website, as a function of the number of transactions, is illustrated in the figure here (this is simplified but not far from the truth):

app webThis is the graph you need to keep in mind when you are trying to take your product app-only or web-only. Labels from the graph have been removed on purpose.

For low levels of usage, there is no point in installing an app (unless the reduction in marginal cost is dramatic), for the fixed cost is not going to justify the benefit that the app offers. When the usage is high, it makes sense for the user to install the app, since the fixed cost will amortise over the larger number of transactions.

When a service goes app-only (as is the fashion in India nowadays), it loses the long tail of low volume users who see no value in incurring the fixed cost of keeping the app. On the other hand, a web-only service is likely to lose power users since they have to incur the higher marginal cost each time.

So if you are starting a new service and are wondering whether to launch the service on app first or web first, think of the frequency with which your customers will be using the service, and the incremental value you can add if they use the app (be realistic about these estimates). If it is either a high-frequency service (like email or news, for example) or a service where the value added through the app is massive (like Uber, which can read the user’s location), you better lead with an app.

On the other hand, if the service is low-frequency and the quality of experience in app and web need not be dramatically different, it makes sense to lead with the web offering and add an app later only to hold on to your power users.

From this perspective, I’m not convinced of the logic of Indian companies such as Flipkart and Myntra (which are shopping sites, which most users don’t use that often) to go app only. India being a ‘mobile-first’ nation is at best an excuse.


The above graph also explains why businesses offer attractive incentives to customers to install the app – to mitigate the high fixed cost of installation. The problem is that the fixed cost is borne not just during installation but also over time (app occupying phone space, snooping on you and sending you notifications), so smart users take advantage of these incentives and uninstall the apps after immediate use.



Should USP be part of MVP

First of all, my apologies for the jargon, but this is a way to get attention of those corporate types who I hope to sell to. The MVP here in question is the startup-wala MVP (minimum viable product) and not the sports-wala MVP (most valuable player). There is no ambiguity to USP.

So it’s an accepted mantra in the startup world that product development should follow the “agile model” rather than the “waterfall model” (borrowing from software engineering paradigms). It is recommended that you put out a “minimum viable product” (MVP) out early into the market and get continuous feedback as you continue to hone your product. This way, you don’t end up wasting too much time building stuff the market doesn’t want, and can pivot (change direction to another product/service) if necessary.

The question is how “minimum” the “minimum viable product” should be. Let’s say that your business isn’t something that creates a new market but something that improves upon an existing product or service. In other words, you are building a business around “a better way of doing X” (it doesn’t matter here what X is).

The temptation in this case is to copy X and release it as your minimum viable product. This is rather easy to do, since you can just reverse engineer X, and put out a product quickly. That’s the quickest way to get to the market.

The problem with this approach, however, is that your initial set of users who experience your MVP will fail to see what the big deal about your product is – while they might hear your promises that this is only a start and you intend to do X in a “new improved way”, the first version as they see it shows no indication of this promise.

Worse, when your product is branded as a “new improved X”, it automatically gets anchored in your users’ minds with respect to X. Irrespective of what your product looks or feels like, once you’ve branded as a “new improved X”, comparisons to X are inevitable. And when your MVP is not very different from X, people might lose interest.

On the other hand, if you need to build in your USP into your MVP, it results in a longer product development cycle. In such cases, if the market doesn’t really want your “new improved X”, a lot more effort would have been expended, leading to higher risk (of market not accepting product).

Yet, if your MVP is nothing like what your “real product” is, then you are not really getting feedback from the market on your “real product” – only feedback on your MVP. And the MVP should be something such that you can make use of any feedback you get on it in terms of superior product design.

Some initial thoughts about Vigyapanti

It’s great in theory but soon law of diminishing marginal utility will hit, so the model is not scalable

There are two kinds of content – content that people want to consume and content that people are forced to consume if they want to consume something else. Such content can come in various forms – text, photos, videos, audio or whatever. For example, this post is an example of the former kind of content – you’ll read it only if you want to. It doesn’t come bundled with other content you want to consume.

I don’t make money directly from this blog, but if I wanted to, I’d do so by inserting advertisements. For example, I might put a popup when you reached this page so that you couldn’t read this post unless you read that popup and dismissed it. The popup would then pay me everytime you read it, and you are paying me for reading this with your attention. That’s the traditional model of advertising.

The buzz in the advertising world nowadays is all about “native” advertising. In such advertising, you can’t easily distinguish between content you want to consume and content you’re getting paid (directly or indirectly) to consume. Like I might plug a product in this blog post, for example, for which I get paid.

The reason Vigyapanti, the new venture by comedy group All India Bakchod, is making waves is that it fits right in into native advertising. Their first output, shown below, has been commissioned by dating site TrulyMadly.

In an earlier era, this would have been presented slightly differently. There would have been a song or a sketch or whatever by AIB, and before you watched that, you would be forced to watch a TrulyMadly commercial for 30 seconds or so. In the process you may not have paid the commercial sufficient attention, and so whatever TrulyMadly would have paid AIB (via Youtube) might not have had its necessary impact. So that’s the good thing about native advertising, which has got everyone quite excited about this format.

The problem, in my opinion, is that it is going to be hard to scale. A friend I met yesterday talked about talent to produce such content being hard to scale. That is not at all a concern for me. My concern is that this one works currently mainly because of its novelty value. Once you have plenty of such content around, the impact without the novelty value will be questionable.

As a parallel, think of celebrity endorsements. Back when they started, a celebrity endorsing a product meant a credible message that he/she actually used it, and since people look up to celebrities, this would drive sales. Over time, however, as celebrity endorsements increased, this link got broken, even in the viewer’s minds.

Now the chief value of celebrity endorsement, in my opinion, is that it makes the commercials more watchable. No one believes that celebrities who endorse a particular product are loyal to it. For example, it is fairly common for celebrities to tweet their endorsement for a particular phone brand using a phone made by a competitor!

I think the same thing will happen to these “native comedy advertisements”. After a while, this Creep song will start being recognised as “that TrulyMadly ad” – which I’m not sure is a good thing as far as TrulyMadly is concerned. Then, when AIB do more such ads, the law of diminishing marginal utility will hit. They might control supply and strike exclusive deals, but nothing prevents competition from moving fast to make similar ads.

In conclusion, this is an innovative format, but don’t expect it to scale too much!

Restaurants, deliveries and data

Delivery aggregators are moving customer data away from the retailer, who now has less knowledge about his customer. 

Ever since data collection and analysis became cheap (with cloud-based on-demand web servers and MapReduce), there have been attempts to collect as much data as possible and use it to do better business. I must admit to being part of this racket, too, as I try to convince potential clients to hire me so that I can tell them what to do with their data and how.

And one of the more popular areas where people have been trying to use data is in getting to “know their customer”. This is not a particularly new exercise – supermarkets, for example, have been offering loyalty cards so that they can correlate purchases across visits and get to know you better (as part of a consulting assignment, I once sat with my clients looking at a few supermarket bills. It was incredible how much we humans could infer about the customers by looking at those bills).

The recent tradition (after it has become possible to analyse large amounts of data) is to capture “loyalties” across several stores or brands, so that affinities can be tracked across them and customer can be understood better. Given data privacy issues, this has typically been done by third party agents, who then sell back the insights to the companies whose data they collect. An early example of this is Payback, which links activities on your ICICI Bank account with other products (telecom providers, retailers, etc.) to gain superior insights on what you are like.

Nowadays, with cookie farming on the web, this is more common, and you have sites that track your web cookies to figure out correlations between your activities, and thus infer your lifestyle, so that better advertisements can be targeted at you.

In the last two or three years, significant investments have been made by restaurants and retailers to install devices to get to know their customers better. Traditional retailers are being fitted with point-of-sale devices (provision of these devices is a highly fragmented market). Restaurants are trying to introduce loyalty schemes (again a highly fragmented market). This is all an attempt to better get to know the customer. Except that middlemen are ruining it.

I’ve written a fair bit on middleman apps such as Grofers or Swiggy. They are basically delivery apps, which pick up goods for you from a store and deliver it to your place. A useful service, though as I suggest in my posts linked above, probably overvalued. As the share of a restaurant or store’s business goes to such intermediaries, though, there is another threat to the restaurant – lack of customer data.

When Grofers buys my groceries from my nearby store, it is unlikely to tell the store who it is buying for. Similarly when Swiggy buys my food from a restaurant. This means loyalty schemes of these sellers will go for a toss. Of course not offering the same loyalty program to delivery companies is a no-brainer. But what the sellers are also missing out on is the customer data that they would have otherwise captured (had they sold directly to the customer).

A good thing about Grofers or Swiggy is that they’ve hit the market at a time when sellers are yet to fully realise the benefits of capturing customer data, so they may be able to capture such data for cheap, and maybe sell it back to their seller clients. Yet, if you are a retailer who is selling to such aggregators and you value your customer data, make sure you get your pound of flesh from these guys.

Two way due diligence

In a cash-and-stock or all-stock acquisition, does due diligence take place one way or both ways?

This is a relevant question because not only are shareholders of the acquiring company acquiring shares of the target company, but shareholders of the target company are also acquiring shares of the acquiring company.

Take, for example, Foodpanda’s acquisition of Tastykhana in 2014. The source of this snippet, of course, is the brilliant Mint story about Foodpanda earlier this week.

Shachin Bharadwaj, founder of TastyKhana, a Pune-based start-up that Foodpanda acquired in November 2014. After spending two months inside the company, Bharadwaj was disturbed about the lack of processes and had uncovered several discrepancies—fake orders, fake restaurants, no automation, overdependence on open Excel sheets, which were prone to manipulation, and suspicion over contracts awarded to vendors.

“I know I am making allegations,” he told the people in the room. “All I am asking is that we do an independent audit.”

The others were not interested.

“The past is the past,” said Malhotra. “Let’s just resolve the differences and find a way forward for you and Rohit to work together.”

So Foodpanda acquired Tastykhana, and the Tastykhana founder (who became a Foodpanda employee) later found out that Foodpanda wasn’t the company he had assumed it was, and now owning shares of a company he had overestimated, he rightly felt shafted. It’s unlikely that due diligence happened “the other way” in this acquisition.

I had written on LinkedIn a while back about how employees accepting stock in a company that is hiring them are implicitly investing financially in the company, and that they need to be able to do due diligence before they make such an investment. Acquisition works in a similar way.

So I’m repeating myself yet again in this blog post, but is “reverse due diligence” (acquiree checking acquirer’s books) a standard practice in the M&A industry? Does this work differently in big company markets and in startups? Do acquirers get pissed off when acquirees want to do due diligence before getting acquired (when being paid in stock)?

Note that this doesn’t apply to all-cash deals.

Hyperlocal and inventory intelligence

The number of potential learnings from today’s story in Mint (disclosure: I write regularly for that paper) on Foodpanda are immense. I’ll focus on only one of them in this blog post. This is a quote from the beginning of the piece:

 But just as he placed the order, one of the men realized the restaurant had shut down sometime back. In fact, he knew for sure that it had wound up. Then, how come it was still live on Foodpanda? The order had gone through. Foodpanda had accepted it. He wondered and waited.

After about 10 minutes, he received a call. From the Foodpanda call centre. The guy at the other end was apologetic:

“I am sorry, sir, but your order cannot be processed because of a technical issue.”

“What do you mean technical issue?” the man said. “Let me tell you something, the restaurant has shut down. Okay.”

I had a similar issue three Sundays back with Swiggy, which is a competitor of Foodpanda. Relatives had come home and we decided to order in. Someone was craving Bisibelebath, and I logged on to Swiggy. Sure enough, the nearby Vasudev Adigas was listed, it said they had Bisibelebath. And so I ordered.

Only to get a call from my “concierge” ten minutes later saying he was at the restaurant and they hadn’t made Bisibelebath that day. I ended up cancelling the order (to their credit, Swiggy refunded my money the same day), and we had to make do with pulao from a nearby restaurant, and some disappointment on having not got the Bisibelebath.

The cancelled order not only caused inconvenience to us, but also to Swiggy because they had needlessly sent a concierge to deliver an impossible order. All because they didn’t have intelligence on the inventory situation.

All this buildup is to make a simple point – that inventory intelligence is important for on-demand hyperlocal startups. Inventory intelligence is a core feature of startups such as Uber or Ola, where availability of nearby cabs is communicated before a booking is accepted. It is the key feature for something like AirBnb, too.

If you don’t know whether what you promise can be delivered or not, you are not only spending for a futile delivery, but also losing the customer’s trust, and this can mean lost future sales.

Keeping track of inventory is not an easy business. It is one thing for an Uber or AirBnB where each service provider has only one product which is mostly sold through you. It is the reason why someone like Practo is selling appointment booking systems to software – it also helps them keep track of appointment inventory, and raise barriers to entry for someone else who wants the same doctor’s inventory.

The challenge is for companies such as Grofers or Swiggy, where each of their sellers have several products. Currently it appears that they are proceeding with “shallow integration”, where they simply have a partnership, but don’t keep track of inventory – and it leads to fiascos like mentioned above.

This is one reason so many people are trying to build billing systems for traditional retailers – currently most of them do their books manually and without technology. While it might still be okay for their business to continue doing that (considering they’ve operated that way for a while now), it makes it impossible for them to share information on inventory. I’m told there is intense competition in this sector, and my money is on a third-party provider of infrastructure who might expose the inventory API to Grofers, PepperTap and any other competitor – for it simply makes no sense for a retailer to get locked in to one delivery company’s infrastructure.

Yet, the problem is easier for the grocery store than it is for the restaurant. For the grocery store, incoming inventory is not hard to track. For a restaurant, it is a problem. Most traditional restaurants are not used to keeping precise track of food that they prepare, and the portion sizes also have some variation in them. And while this might seem like a small problem, the difference between one plate of kesari bhath and zero plates of kesari bhaths is real.

Chew on it!