BizMech Ideas: Crispier
At last count, there are almost 30,000 restaurants in the Big Apple. There’s even a saying: “You could eat a different restaurant, three meals a day, for the rest of your life, and still not eat at every one in NYC”
And after moving here, I think that’s a little off the mark.
What it should say is “You could eat a different cuisine, three meals a day, for the rest of your life, and still not eat at every restaurant in NYC”
You could open your day with congee, have a light lunch of taco salad, and a dinner of Ghanaian curry and fufu. You could have a breakfast smoothie, a pastrami on rye, and yuca con chicharron for dinner.
Then the lockdowns came. And NYC delivered.
A number of restaurants went from no-delivery to pick your delivery platform. And, with the eruption of ghost kitchens, there were now delivery-only restaurants of dizzying varieties!
The problem is that most restaurants never accounted for selling their food via delivery. And that’s a serious problem for food that’s supposed to be crispy but arrives soggy from the trapped steam.
(There’s no data to support this, but I suspect the air fryer trend was a result of people wanting crunchy snacks but only getting damp disappointment when the delivery arrived.)
Then, while gnawing on mushy tempura, the idea struck. So here it is, a solution to soggy snacks.
Value Proposition / Business Model
By approaching the process holistically, Crispier will revolutionize food delivery. Better package design will ensure crispy food never arrives soggy. Better customer reports will help restaurants tweak their offerings. And better engagement with the customers will forge a sustainable path forward.
People, Process, and Technology
People
This workforce is going to be intentionally siloed. Each silo will focus on a single aspect of the full system and competition between silos will be encouraged. I’m not suggesting outright warfare, but the occasional skirmish might not be a bad idea.
The silos will be Product and Customer.
The Product silo will need researchers and specialists in material science. It will also need packaging designers. Their mandate is the better takeout container. At first, it will be a standard container that allows crispy food to be transported without becoming soggy.
This could be something as simple as micropores in the lids or some other neat trick of packaging design. Maybe there’s a way to have a food-safe glue that unsticks at a certain temp/humidity. If that glue is used to hold some vents closed, they would open at that threshold, venting the steam. But, since I’m not a packing designer, I have no idea if that is even feasible.
The Customer silo will interact directly with the end users, gathering their feedback. Their mandate is happier customers. Regardless of Product’s designs, or stress tests, the Customer silo can veto a design because of a valid complaint.
To provide an outlet for this antagonism, and improve engagement, regular team events that pit the silos against each other would be a good idea. Team sports are a good example, but hackathons, potlucks with prizes, and other types of competitions would work here too.
For introverts and people who would prefer to avoid socialized contests, there could be other sorts of outlets. For example: Who can crochet the longest scarf? Who can recite Pi to the most digits? Who can solve a Rubix’s cube the fastest?
Process
Before anything can get started, a prototype container must be made by the Product silo. Without the prototype, there is no business.
The prototype must have clear specifications, tested by the Product silo. The spec’s should cover things like ‘maximum transit time’ and ‘maximum volume capacity’. The prototype is then handed off to the Customer silo. They will field test the container by sending to interested parties (chefs, restaurants, etc). After verifying Product’s claims, the prototype can be offered to the test market.
Once the containers are in use, the Customer silo will wait for customers to engage. To incentivize the end users, those who provide a number of reviews should be given a gift. This gift should be a unique physical object of some type, rather than a discount code or monetary reward. That way, the gift box itself can also be used to send those containers back to Crispier.
Alternately, the customers could drop them off at one of the restaurants that use the containers. Giving the users the option to drop to said restaurants does two things. First, it allows the users a more sustainable option than relying on mail carriers. Second, it demonstrates to the restaurant how many people use the containers.
In either case, getting the product back creates a cyclic economy of sorts, reducing carbon footprint and ensuring that damaged/faulty containers aren’t bouncing around ‘in the wild’.
The data provided by the customers can be used to define clusters. If the clusters are around the same restaurant, then the issue could be the food prep rather than the containers. If the clusters are around the model of the container, that information will be brought back to the Product silo to address the problem.
This is why the silos must be antagonistic towards each other. If Customer’s complaints do not have to do with the packaging, it will be up to Product to prove that. If the complaint is valid, it’s up to the Customer silo to champion the issue and ensure that it is not minimized or ignored.
And as the data is gathered, the containers’ value to restaurants will be easier and easier to prove. The Customer silo can also directly interface with restaurants with the customer data. As in, “Your fries show up soggy. Other restaurants do not have this issue. This is how they do it.”
In this way, the Customer is not just the end user, but also the restaurants themselves.
Technology
Similar to the MVC of TOChanger, but with a few differences
Model — The database will contain the unique ID of each container, where it was sent, if a customer reviewed it, which version of container it is, etc. etc. This will allow the identification of failed designs and facilitate recalls.
Adding a sticker to the lid of the container would be fine as a first step, but in time, incorporating a QR code into the container would be a better idea.
It should also contain a comprehensive listing of the restaurants that have the containers and an up to date listing of their menu.
View — The end user view will allow the customer to enter the container’s unique ID and to report their experience. This should include the restaurant the food came from, and hopefully which specific food was ordered. It should also allow them to report shipping/dropping off containers.
The restaurant view should allow for ordering more containers, returning unused or deprecated models for a discount on future orders, as well as notifications for recipe changes that might reduce customer complaints.
There should be one internal view for each silo, providing full transparency on customer feedback for both teams.
Controller — An analysis suite for identifying correlations should be part of the internal view. The other controller will be a CRUD interface into the Model for the end user and restaurant views.
Scale and Scope
At first, the scale of this venture should be kept within a small urban area. Nothing as sizeable as NYC, but a city the size and density of Zurich would be ideal. That way, the initial designs can be tested and refined in a more forgiving environment.
As the scale of the venture expands, so should the scope. More designs for larger and smaller containers and more sustainable versions would be great expansion opportunities.
