 Okay, so in my 17 years in IT industry, I've been working on product development. I've worked on Drupal for the last 10 years, or more, and UI design, DevOps, product management, of all of which the toughest thing I had to do was walk into a meat shop and talk to a butcher and help him cut his meat better. And me being a vegetarian was the toughest thing for me to do. The question is why? Why had to do it? For a year ago, I was called upon into the executive management office and said, Subbu, we have seven butchers on board the cruise ship and on an average. If they could cut the meat better and we know where the meat goes, that will save us millions of dollars, millions. So I was like, wow, I'd never realized it. And then the question is why? We run, in Princess Cruises, across our 17 ships, more than 250 restaurants, 250 restaurants of which 51 unique chains, which is the same restaurant in multiple ships, and on an average day, per ship, we sell more than 15,000 meals a day in one ship, times 17. So that's the problem we are trying to attempt. Let me show you one quick video, it's a 10 second video, of what happens in the galley. So it is a formal night where we have the waiters coming up to pick up the appetizer. It's one side of the galley, trying to serve for more than 1,000 people as a one minute one. This is the waiters coming and picking up appetizers, that's one, it's not even main food. So this is the busiest restaurant. We feed around 4,000 people within that period of two hours, the dinner. With this kale, times 17, on a given month, we give out or we make 1.1 million slices of pizza, 1.1 million. And let's think about soda, 51,000 gallons of soda a month. And my favorite, cookies, 1 million cookies that we bake on board. And healthy side, bananas, 220,000 pounds of banana. And ice cream is enough to fill an Olympic-sized pool. That's the size of operation. But for the last 50 years, for a decade, I mean 55 decades, they have been managing all of this because we had, as I said, 250 restaurants, we had so many menus. And we manage over 300 menus on board for managing all the ships. Now for creating all this food, because food is big in cruise ships, we have over 3,000 ingredients that's been kept and monitored. Plus the food, because ships are traveling around the world, we have to carry it and buy it from around 500 ports. So there's a logistical problem to get food items and of course other things too, but in mainly food, 500 plus ports. Now all of this, all of this is managed for the last five decades, as I was saying, with paper. Paper, emails. Now on top of this, with paper, we have crew members from all over the world, and we speak 54 languages. 54 languages. Now with all this, how will be the communication? So let's say that's how we represent it. So let's say there is a problem with lobster, which in fact we had. The product they bought and delivered to the ship from corporate office was not good enough. Now the ship found it while they were cooking food for the passengers, and there was a problem with the product. By the time this message reached shore office, and they found the similar problem that's happened all the other ships, and they took a remedial action of getting the next batch of lobster to these ships, took a month, because to identify this problem and making a remedial action, buying it, because it's all emails and things get lost and it's very difficult, which all amounts to a lot of wastage, and it runs into millions. If you do it right, if you do it forecasting is done right. Then since menus were being sent back and forth using emails, the menus were mismatching, and the recipes could be mismatched. Now what happens because of this is we have changed restaurants. So let's say Crown Grill is one of the popular restaurants on board. Somebody likes a steak or made some way and they expect the same when they go to next ship, and better be the same or it'll be a big customer service issue, because we want to keep the quality of the product. Between the restaurants that you visit, it's a big thing. Now everything with this affects the revenue, and of course that's what time to avoid. So this is a problem that is given to us. As a whole, just want to reflect back on what we are attempting. This is a complex problem. So many people, 300 plus restaurants or 250 plus restaurants, food from all over the place, 54 languages spoken, all managed with paper, this is a typical case where we would say this is a case for digital transformation. So what did we do? And this was a Drupal conference. We did it with Drupal. This is a story of how we did this transformation using Drupal. Of course we used Angular, Couch, the decoupled interface. And we knew and we know Drupal for the last 10 years. Drupal has been powering our guest experience platform for the last five years. And Drupal is living on board all our cruise ships, 17 of them, with the master Drupal and show side, and every ship has a Drupal instance running. We had other presentations where we covered this thing. But what did we have to build with Drupal to face this problem that we are facing about food and making it standard? We had to build this. I'm not expecting everyone to read this. We are just going over. What we built was Princess at Sea, which is our guest experience platform, as I was saying now. We built a digital signage platform for outside the restaurants for people to see what is being served. We have a printing system where digital data is used to physically print. There's a print shop on board to print restaurant menus and newsletters. So we used Drupal and services to provide data and build the menus. There is another session that my colleagues did yesterday about Canvas. This explains the Canvas suite, which is our print system. Next one we did was menu management system, which we had to create because we set 300 menus. We had to manage it, standardize it. There's a menu management system. There is a menu scheduling system because a menu is not the same every single day. There is a recommendation from show side how the ship should manage menu. So there is an intelligent system that we built to do a menu scheduling for the ship to make it easy. We also built a room service. That's where the menus are used to do transactions. You could request for room service. That's pretty fascinating. We also built a reservation system for taking orders for our reservation orders from customers. We did tables at order system. That's also built part of this platform. We did a kitchen display system. It's not a regular kitchen display system because we are talking about thousands of people and the orders are in hundreds. So it's a bulk kitchen system, which is not readily available. So we had to build it. Then meal count system to know what has been cooked should go back to the customer. So that's been counted well. And there's a chef planning system that we built, which also we'll show you, as well as the production system, which gives tickets to the butcher, the vegetable place, or all the production units to bring food to the gallery. We'll put a context around it like what we are talking about in the context of a restaurant. This is what we did. Now, going from left to right, if you see, the first is room service on the top left. That's one part. Princess at sea where the guests can see the menu and order for room service in case they want. There is a digital signage system where the guests can see outside the restaurant. Inside there's a table order system and table assignment. There's a food and beverage office on the top. They have a view of what is happening in every restaurant. Then the chef office where they can plan for food in every galley, the meal count system, the kitchen display system, and the butcher shop. This is the contextual view of how we can look at a restaurant and see what we have done. We'll post this in the site and you can take a look at it in detail. I'll give it to Davis to just go over the menu management side of things. By the way, if you have any questions, please talk to us. Come up to the mic and ask a question. We'll be glad to answer those as we go along. Thanks. So, as of now, we have seen the problem which we are facing and an overview idea of what we have built. I'll go in detail in each of the sections which we built and how we achieved it and how was the connection made using Drupal as a backend system. So, when we looked to the entire problem, one thing which we came to know is we were lacking the digital format for anything, like for restaurant menus or menu items. Just to be aware of menu item is not a Drupal menu item. It is a restaurant dish. It's a plate. So, just keep in context. So, the first thing was like the basic pillar to build the system was the menu items. And we didn't have the menu items in a digital format. So, using Drupal as a backend, we created a menu item system which had like the menu names, descriptions, and all the meta tags information which could actually, you know, look, when you look at a menu item, you could say like, okay, this menu item has this kind of allergens or this kind of dietary or this kind of intolerance. So, all this information was stored in the backend system of Drupal. So, in this way, we could create like when we took an account, it was like more than 5,000 menu items which they had in the entire like 17 ships. So, that is a basic first step which we had to take forward. So, we did that. Then the second step when we looked to it was a collection of menu item is a restaurant menu, right? So, that is the second step which we have to build. So, when we did the first step like creating a menu item, what we did is like we have a, so how the system works in our scenarios, like we have a show set instance where the show set admins can create the menu items and it has been replicated into the 17 instance of our ships. This, this, this, this application has been done using the Migrate model, Drupal's Migrate model which was very helpful for us. And we also have Lingotech which has been attached to the top. So, like our system, we support nine different languages. So, we use Lingotech heavily to translate all the menu items. So, a guest who's coming from China can see the menu in Chinese or a Japanese guest can see it in Japanese. So, so the process what happens here is like the show set admins create a menu item. This menu item has been sent to Lingotech for translation and it's coming back to the show set system and using Drupal's Migrate model it has been sent to all the different ships. So, that's the first step which we did. The second step is like collecting all these menu items and creating a restaurant menu. So, I'll go to the next slide. Yeah, so in, in our, yeah, yeah. Sure. Yeah, one plate. Yeah, so that is a plate. Yeah, yeah. The menu item could have sub-recipe. If you look at, that's an exact example that could have other sub-items to make that dish. The main menu item is one line item in the menu and you could have sub-recipes. Sub-recipes could have ingredients. It's a complex problem. We are trying to, we didn't go that deep. We could definitely go and show you all of that side after the demo is covered. We had to cover a lot, so we are trying to skip some of the areas. So, talking about restaurant menu, we had four different kinds of restaurant menu. Okay, and the, and creating the four different kinds of menu was not an easy task for us because it was like four different scenarios which they were using in the ship. And the first one is what you see here is the static menu. So, static menu is basically, for example, take Cheesecake Factory, which has the largest number of menu items, like 250 menu items. So, it's like constant like throughout the season or throughout the year. So, even in ships, we have specialty restaurants or the room service menu, which is constant, which does not change to entire year. And that's what this kind of static menu is being used. If we had to only create this kind of menu, it was a quite simple job with Drupal, but moving forward with the complexity, I'll go with the next one that is the special menu. So, what this is like, we know in ship there's a lot of events happening, right? And say, it's somebody's wedding happening, so a guest of 300 who comes for the wedding, they have to set a different menu for the wedding. They can't give the normal food. So, they go and request to the chef saying that it's a special location and we need a special menu. So, it is like planned like a voyage before when they give the request to the chef and he asked with all his ingredients with him, he has to create a menu for that particular guest. Or say, if a guest of 300 who are vegans who are coming into a ship, they accommodate those guests by making a special vegan menu for them. So, this is made on fly. Not on fly, it's basically done on a previous voyage so they can plan for just one voyage before. But these menus are not set as not done from the shore side. It is done in the ship itself. That's the second kind of menu. Going to the third kind of menu is an ad hoc menu. So, you know how it's buffet, right? In the ship, we have voyages which is lasting from three days to 100 days voyage and you can't serve the same food for all the 100 days in the ship. So, we have to keep on changing the menu and that's when this ad hoc menu comes because say, you can think like you can create this menu beforehand but the problem is we have the menu has been created based on demographics, based on the ports you go, based on the itinerary, where all this has been taken into consideration and based on all these parameters, we have to create this menu. And this menu is only done on the ship side because they have the rights to do it. And moving forward is the most complex time of life menu, that is the menu sequencing. Talk about menu sequencing. So, this is for the main dining room. This is where the most of people eat every night. Now, menu sequencing is say an example here. It's like say a four-day voyage. We have Italian, Asian, American, Mexican for a day, one, two, three, four dinner, let's say. Now, the ship has based on where they are, what time they come into a port and what time they leave the port. So, for example, the ship is leaving at 10 p.m. at night and the chef wants to make sure that the passengers enjoy this food. They would switch the menus between days. So, what happens is the show side will give a recommendation just for planning purposes. Standard menu saying that this is what your recommendation is, but the ship has a override capacity based on which region they are, what's the weather condition, they could switch menus. This we call it menu sequencing. This is a task they do in the ship. So, we had to build a system which gives a flexibility for the ship to control what they do as well as have show side the visibility of what is happening in the ship. So, that was a very tricky thing to do and we kind of achieved it. I think we did achieve it. We'll show you a demo right after this. This is the first part of the demo. This is one part. If anybody has a question, this is a good time to come up and talk. You can come up with the mic if it's possible. Thank you. So, do you want to show that? So, I think I'm understanding that you're doing a short of ship communication with the Migrate module and I'm wondering what the contingency is on the ship if that breaks down, if you lose connectivity or the migration fails for some reason. As I said, the ship has Drupal instances on board. So, it's not necessary that we have designed everything with that assumption that there could be connection problems. So, in most cases, we have done so much on Migrate, updated that it only transmits a little bit. There are good cases where the ship is disconnected for a couple of days, but we have come to a process where ship can run independently. So, that's how the entire system was designed. We can talk to you about that detail offline, but yeah, that's how we have done it because we knew going into the project, that's the uniqueness of our project is it is built around failure. That's how we architected it. It's not like a cloud instance where you know there is connectivity, only in the rare cases that Amazon will go down where you still have connectivity. Our case is not that. It is very much possible so that the connection will go down regularly. So, it's a different architectural thinking that we had to do, but we took all those from what we built on Princess at Sea, the other application that I was talking about as a guest experience application. We had built those for the last five years. So, that's what we are going to do. We also have a session tomorrow. It's a good plug for you, Nate, which is we are talking about our DevOps methodologies of how we implemented DevOps to deploy to these remote environments. So, last year we did around 3,000 plus deployments to the ship. Every week we have two deployments that goes in. So, check that out in tomorrow's session, Nate. It's called the Realized Stories of DevOps. So, you might have more information there. So, going back here, let's focus on a couple of things here. There's a lot of things afterwards we can go and talk about if you want to see it. One thing I want to talk about is the menu item. We go into and one thing to note here, the admins here are chefs. So, we had to redo the entire admin theme of Drupal. Everything is custom built. You'll see a lot more technical. If you have technical questions, please feel free to ask. But everything is custom built so that it's easy for them to see and understand in their way. So, it is built with them. So, here menu item. They click on a menu item. And you'll see there's a list of menu items. And if you click on edit, we have around 5,000 of them. We had to redo the search somehow to bring it up much quicker. The contrast is not very good, but at least hopefully you can see. There's a menu item name here. Which we define menu items. There's a short name that is for the waiters and the galley. Because they don't know the Italian name of a dish. They're not used to doing that. So, they have a chicken item, you know, the chicken dish. That's what they know. So, there is a short name and the passenger friendly name. So, that's for the galley. When we found that, you know, they don't understand exactly the long Italian definition of a dish. We had to change it and create something for them. Then there's a description. All of this is translated, as you see on the top, into nine different languages using Lingotech. Then we can add the skew numbers, the pricing. Also categories of which menu category it falls into. We used a module called chosen. You could quickly add, because the same item would be a salad, would be named differently in an Italian cuisine versus a Mexican cuisine or an Asian one. So, it could fall into different category names. They also have subcategories, all the proteins. The lifestyle choices, in fact, have alligator protein. So, we have all of this, as well as the regions. So, there are region-specific menus. Like a baked Alaska is available only in Alaska. So, it is targeted only for Alaskan region. So, we can target by region, by ship, all and by menu. So, specialty items will show only in the dining rooms, fine dining rooms. So, those things are also built in as a menu item. It also goes much more deeper of what are the sub-recipes, as the gentleman was saying, could be the salad, that goes much more deeper in a different section. But, going back, restaurant menu. So, this is where they create the master menus, where they pick a menu, want to create one. So, all they do is, in the ship, if they want to create a menu, they just select the voyage. It's very limited, but it's also controlled. And they have freedom to add stuff, too. So, they pick an itinerary day. So, they say it's an eight-day voyage. They pick day seven, and the dining location, we have so many dining locations in one ship. So, they pick main dining room, and they're talking about which meal time. So, dinner. This is all custom created for the admins. It is not even for the guests. Now, the menu name. So, they have all the master menus that we call, from show side. So, it's Italian menu. It's much zoomed in, but you can see this. This is a menu that is built based on the taxonomies added, the tags added in the background. It builds a menu for them, based on the region they are. It just builds a menu for the ship. Now, here, they can review this. They can move around things if they want to move items in the menu, or they can remove one, because they have an ingredient problem. They could not pick up a chicken from a port. But still, they want to add another, so, oh, they got a gnocchi. So, no, zucchini. So, they add a new item. So, we had to rebuild the whole interface so that it's easy for them to understand how to build a menu. They can also add sections, you know, move sections around. So, in case they want to add. So, if you see dessert can be removed up, or section can be removed. It's like pretty much a layout system, which is a chef-friendly layout system that we had to build. Also, search goes through and searches the 5,000 of our menu items. It is not limited. So, this is how the menu was done. Move forward. So, on the ship, we talked about the menu sequencing. This is where they select what menu goes in which day. And this is what they do once for the Future Voyage. They pick a itinerary and then pick a dining room. So, it shows what has been recommended from ShowSide. If you see, it is a voyage. It says it's day one, San Francisco, arrival time, departure time. What is the recommendation from ShowSide? This is all the different meal times. It shows D1 is a recommendation from ShowSide. The ship can change it to some other menu based on... So, they change it to Chef1. It actually highlights for them and says you have switched it. And in case they want to make a change, they can click a change and they can do the same thing that I said, modify that menu for that day. So, this change happens only on the ship for that one day. It does not modify. It's a node copy that happens. So, it creates a copy of the node and then it lets them modify that. It is saved. So, the ship will have a menu. However, that information is immediately transferred back to ShowSide saying that there's this change that is happening in this restaurant for that day. So, all of this information is fed back to ShowSide so they can plan accordingly what is happening and check with the ship if there's a costing implication. So, all this information gets kind of real-time based on the connectivity. But they have a dashboard to see what all changes happened. So, we built that entire back-and-forth system. Now, moving on. So, at this time, they go back and assign. That's the only thing regular basis on the ship do is they go in every restaurant and make sure that the menu for the next voyage is same. And once that is done, every dining location will have a menu assigned. So, that's the first step that we did. This is where we used Drupal heavily. And from this point, it kind of distributes itself. So, if we go to the next slide, there it is. Hopefully, it shows up. Yes, it does. So, as I said, the menu was assigned now based on each day of the voyage. Now, it goes into Princess at Sea for passengers to see the menu for that day so the passengers can see, the guests can see the menus for that any dining location for that day so they can choose where to go. As well as we have built for room service and everything, we have built the transaction into it so they can order for room service. That is also controlled. We built the entire system for that. Digital signage, as we talked about, the canvas as well as the production side. Now, going back to room service. When you talk about room service, you can talk here. Yeah. So, as you all know, room service, so if you go to a regular hotel, you get your, like you see a menu card sitting in your room where you have to place an order for your next day's breakfast or any other room service items. So, for the last 50 decades, Princess was also doing the same thing. They give a menu card in your room where you have to take what items you want for the next day and or you can use the telephone to call the room service station and say what you want for the next day. So, since we had the menus in our system, we thought why not make it digital? And that's when we converted the first kind of menu, the static menu into the digital platform which we call Princessy so the guests can come in and place their order for the entire voyage. And this system was built in Drupal where they could see the menu and place the order. Then we created a room service system where this menu will go to the room service station and they can process the orders. One of the interesting things which we did there is like all the orders which are coming in could be printed out from a thermal printer and based on that they could sort orders and do all the stuff using the sorting system which we built. And this was done using Angular over there. So, in a given day we deliver around 500 breakfasts to the cabins. Now, we had to build a delivery system too, which we did. I think we're talking about so many systems but yeah, it's a lot. Where the person who is in the bell box which is a room service station they can orchestrate what is happening. And when the waiters, we have 10 or 15 waiters based on the day will go and deliver food. They kind of know what happens and when they have delivered they have a fulfillment message which goes back to the room service section so they know exactly and the customer experience is kept. So, that was done. I'll quickly go to the next one. We also did a reservation system where earlier the chefs did not know how much they should plan for. There's how many reservations were there. They had to call back to the dining line. There could be 100 people coming to the fine dining restaurant or it could be like 80. They don't know but based on they could plan. So, now we connected that to the dining line. It's what they call. So, the reservation is streaming in live for the chef to make decisions. We also created the table side assignment. So, when you walk into a restaurant, the restaurant manager can assign you a table which sends a message to the waiter because it's a huge restaurant. If you can imagine it's like 800 people sitting in a restaurant. So, a restaurant manager assigns a table to you and the waiter knows somebody's coming to the table. How many of them are coming to the table? He can arrange the table if he wants. Make sure everything is good so that the best experience can be provided. As well as there's a digital table side order system that we built. Again, we'll have time to show. We'll show all those things. That was also built where they can quickly take order. The order the chef is taking gets streamed into the galley for the kitchen display system. So, it'll be like 150 steaks. So, something like this is very simple. But all the orders coming in from the different tables stream into one screen for the chef to prepare. As well as if you go further, the waiter also has a meal track if it is a non-digital place. So, they take paper and take a digital system. So, we'll show a quick video of what happens. When there's no fully digital system, they take orders and they mark what is going back out. It's a very simple thing to do, but it kind of connected everything together for the chef. You see, there's been the background. So, we go to the ship, work with them, and then understand what they need, and then we build there. So, we have one person from culinary who go to the ship and three people from our team. Because it's a digital transformation. So, we have the culinary person helps us speak the chef language and we take it and talk to them and build something on board, living in the ship. And that's why our application success is that we never have rework because we work with the waiters. We work with the chefs. We have another video which comes up later where we see how they're comparing notes between the butcher and the chef, which never happened in the past. So, moving on. So, all the information that's happening from the kitchen display system plus the menu, meal count, the executive chef who's controlling 16 restaurants, 17 restaurants in his office can know restaurant which is say Da Vinci, which is a restaurant, is running out of chicken. Because the people there order all the chicken dish. So, what action should he take? Should he let the waiters know that please promote lobster tonight because we have a stock of lobster? Or should I request the butcher to bring more chicken to that galley? Earlier this used to be used over the phone. They had a call. It's a panic situation. From his office today he can see what is happening in each galley in a given ship. With that information it's so easy for him to walk around with his phone because all responses will be built and it quickly plays order. The food items will come to the galley and be ready for that. So, this is how it is done. So, all he has to do is like put up plus 100 for say I need 100 portions of chicken, which has salads attached to it. So, it creates an order for the butcher to create 100 portions of chicken. And it sends another ticket for the vegetable section to bring the vegetables for that plate. It sends another notification for the diary section to bring the diary or cheese, whatever is needed. So, every production system gets this notification based on the one click of the chef to say I need to plan for 100 chicken, whatever, and that distributes tickets. There's a full ticket order system that brings in this data. This next one is the video. This is where, just before that let me explain. This is a butcher. So, I think it's a faster second time he's using a tablet. So, and that's the sous chef. And again, they're placing orders and they're comparing notes. And actually, in fact, the thing that happened is the butcher is correcting the sous chef saying that you ordered the wrong thing. You can see there's Davis here and there's Manoj from our team. And I was taking the video and the Greg from culinary. So, what is happening here? He's showing how the orders are placed and then the sous chef and the butcher is comparing the screens. This kind of interaction is so happy to see that because it's never happened in the past. They had something that was happening in the butcher station and something else was happening in the galley. Now it became all standard. They started talking to each other. That's great. Now, it's not bad. The majority who is controlling the front of the house, every single table, right? In the normal day, what he has to do is he is to walk to different restaurants with his team, spread out to find if any table, there's a problem. Our customer is waiting for so much time. But when we implement our table set system with all the restaurants that he has, it's not completely launched, but the idea is he would know every single table in the 16 restaurants or 17 restaurants what is happening. Every click is tracked at what course is table number 27 in Sabatini's is waiting or if the guest is waiting for the last 20 minutes and he needs to take a remedial action, he can do it from his office. And this was never possible. So all this information, just like the executive chef seeing everything that's happening in the back of the house and his restaurants, plus the major DCing front of the house for customer experience, all this information is happening in one ship. They can see what is happening in one ship. Show side, all this data gets streamed in from all the 17 ships. So now, when you have so much data coming in, we never expected to see this much data, but it's a quality problem. Now, once you get this data, then we can do really interesting things with data. That's what we're trying to head to because we never had this much data coming in and we're trying to do predictive analytics, things like that, to even say further, on top of standardization, based on say one scenario, say the ship is in Alaska, we have a specific demographic and the weather condition is based on it, we can help the chef. Today it is his knowledge that, okay, I see so many Australians and I know what they would like, so let me plan accordingly, but in the future, all this data coming in, we can predict what kind of items you should you plan for, where people might eat. If it is, say, it's rainy weather, you might not have people on the deck, they might be coming into the dining room, so dining room can get alerted. So such a level of predictive information can be given to the chef. On top of it, food safety is very, very big for us because we need to know what happened. So once you've connected the butcher to the store, to the galley, to the waiter, to the guest, if you think the entire line we are connecting, you know who touched the food. So if there is a recall for a specific type of item, say Jesus being recalled, we know exactly where it went. And it's much easier for us to track what happened. And the data in our entire platform, there is no edit button. Everything is tracked, every click is tracked, so we know exactly what is happening. Training opportunities for the chef or butcher can be tracked. What is happening will be seen, and that gives us auditability, and everything can be traced of what reaches where. And with that, we'll show a quick demo of the application that we have been talking about. So it's a lot, but we'll just try to show some pieces of it. And anybody who's interested, we can take it after the session, we can show you much more what we built. And this is entirely angular-based application taking the menus from Drupal, the itineraries from Drupal, and it heavily depends on Drupal, but it's completely decoupled. So this is the next level, I believe, for Drupal is not 100% dependent on Drupal, but it's mostly there. But it can do its own thing. It does couch DB, it's saving this data. So in case something happens to Drupal, couch will let the application run. So we'll start with Chef ordering. That's pretty interesting. So if you see, for the Chef here, it's very simple. In his tablet, he can see which day of the itinerary it is, what ship time it is, what voyage number. It shows you the different days of the itinerary. So he can plan for next two or three voyages in advance. So he selects his restaurant, so he picks Crown Grill, and he picks a meal time, which is dinner. And the entire menu shows up to him. So all he has to do is go through this, see, and then add, say, 50 black tiger prawn. So what happens in the right side is pretty interesting. It tells you it's four kilograms of black tiger shrimp, another shrimp for 2.3 kilograms. It's scaling, based on 50 portions, how much will be requested to the butcher. So it's raw quantity. Now on top of it, we'll have vegetables and other things added to this list. And also he can assign a delivery date if they need the meat a couple of days in advance to start cooking, like slow cooking. They can assign a delivery time if they want. So they can add it. So it's just add. That's it. So the Chef did not know when he was planning on getting the paper, all of this in the past. Today, he takes his tablet, picks a day, puts in the numbers, and his job is done. The food will come to his galley. So he just goes in and puts in these numbers. We see there's another shrimp item. It shows you how much kilograms, and say salads or any other lobster tail. They have 30, 50 dollar lobster tail. So he can just put this number. If you see, it also shows the system is connected or not. This also let him, because we have a limited Wi-Fi. So the application is having local cash. So he can still work, but it will tell them that it is not synced to the system so that the information is not reaching the butcher or not. So the connection is always shown on the top right, if you can see. And also there's a bell sign, which is a notification. It's like Facebook notification that you get. It tells them, oh, the butcher X has seen your order. So what happens in a service time is, say, I'm running out of chicken as an earlier scenario. The executive chef says, I need 100 portions to be ordered now. Based on the service time, we know that it's urgent. So it creates another visible notification, take out the entire screen of the butcher, and shows that immediately you need to stop everything, and you need to deliver 100 portions of chicken to the galley. And when he says, OK, that notification comes back to the chef, saying that the Nate, who is a butcher for today, has seen the order he's working on it. So this kind of communication also is happening. So this is, if you see, the chef's job is so simple. He just presses a button and his job is done. This is where we said we worked with the chef, saw how he was working, how his process was, and completely did a transformation. And we go back, so this is, the chef logs in. He only sees his area. For us in admin, we see all the other sections. So on the butcher, when he comes in, he also sees his today, tomorrow, all the days. And he knows, based on if I'm a fish butcher, or doing the fish, he knows what are the orders coming in. If you see on the left, I don't know if you can see the red sign. It tells him the order is not complete. So he clicks on the orders that we put in now for the shrimp, the black tiger shrimp, and he clicks on it. He says Crown View has 50 portions of the shrimp to be ordered. So ideally what happens is it also prints at label at the same time. So once he's prepared this, all that the butcher has to do is click the thing. It's a ticket that came in. He completes the ticket. That sends a message back to the chef that the item is ready to pick up from the butcher. Simple. It's extremely simple. But we change the way butchers work because they are hesitant to touch any technology. But when you saw this, it's like, oh, his work is done. They have like stacks and stacks of paper. Now it's cutting down because everything is through the ticket. And the ticket is so simple. As well as if he has an extra stock, we can have a section called uncommitted. Say he tried to make 50 portions. He has some extra. 10 portions came extra. He just adds that. And it became added. So he has a stock. So next time the order comes in for more, he knows that, oh, in the freezer number three, I have already prepped this shrimp. So I can go and take it from there. And all that he does at the end of the day, he says the total actual usage. So this gives us all this information for us to process. As I said, we go back to the chef. And also the notification on the right side, we see that's coming up what happened on the butcher side and the chef side. We go back, Davis, we go back to the chef. And I just, I don't know if you recall that I said there is no edit button. Let's say the crown grill, it was, you can add another order for tomorrow. Say 100. Accidentally, I clicked 800. Right? So it created 800 orders. It's an accidental order. So now he has to remove it. There is no edit button. He has to click the plus sign again and say, oh, in fact, I wanted only 100. So remove 700. So he just says 700. Sorry. And remove. So it asks for a confirmation. It says, is it a return? Because I did not use that item in the galley for the evening. So I have an extra that has to go back to the butcher. Or is it trash that I dropped the plate or overcooked. So it's a trash that happened. Or is it actually a typo that I, in fact, I'm my orders extra. So this is how we track every single thing. And they can put a comment if there's a trash what happened. So this is streaming in so much data in real time. All this information they're clicking is also streamed back using couch-to-couch replication. So ShowSight is getting data streamed from, currently it's in four ships. All the data that's coming from every butcher, every chef is streaming in ShowSight and throwing like so much of good data they never had. One example to court, which we saw last week, the chef had ordered say 100 portions, which was supposed to be 100 kilogram of a specific meat. What we found was the butcher ordered 300 kilograms, three times more. And that was happening as usual as a regular thing. We did not know because they were using it for other purposes. The premium meat was being used, where they should have taken some other meat. They had a specific meat for this purpose, which the butcher did not know. But this kind of a race of flag, and it says over request for 200 kilograms, it's around 400 plus pounds for one voyage. So this is for one item and one ship, one voyage. That's a differential that we have. So it's bringing in so much standardization with the standard menus, printing all that we've talked about. Yeah, we'll have any questions? Is it too much? So it's table side. Let's see table side. How much time we have? 10 minutes? So table side is also built, where you see it's extremely simple, it's built with the waiters. So we've worked with them for a week, I believe. So every day morning we used to sit with them and we had a 60% done application. And what we did is we sat with them, made them use every day evening to like say two or three tables. And next day morning we had a debrief with them to say what worked for them, what did not work for them. And three of us were developing onboard the ship. And by evening we built a couple of features for them, what they asked in the morning. And then we test that in the evening. And this process continued for seven days. And this happened because we had a decouple environment, we could do it so fast. And by seventh day we had almost 90% of completed application. The good thing is we took it to the other ship, the waiters, like oh, this is easy, I can pick it up, because it was built, it was designed by the waiters, for them. So there is no other system, I believe, which is as simple and they get it so fast. Yeah, we go and live in the ship. Yeah, it's unfortunate because we work so much. It's mostly 16-hour days that we work, because we are in the kitchen, all we need is food. They'll be making good food for us. And we'll just sit and work. So you see there's sections in the restaurant and they see what tables are there, the color code, they can see it's kind of bright, that's why it's not picking it. They have tables and what is available is listed there. All they have to do is pick a section and a table. It's done. So all they have on the left side is how many guests are listed. The entire menu that we did in the beginning is the same menu as being used for table side. So what the customer is seeing on the digital sign or his Princess Etsy application is the same one the waiter is going to use for his table side order. So here it's so quick that they assign a gender lady or child. That's how they identify a big table, where they start and go around. And they can add and remove the number of guests if it is needed quickly. So let's say it's two guests and every click they can see what courses. So it's so easy to see the numbers in the bottom are courses. Course one, two, three. So there's a kid in the group and I say, okay, I want my dessert, ice cream. In the first round itself, it can be added. So that's how we have built. And the M is for main course. So it's like one, two, three for an M. That's how they understand how the system works because they designed it. So let's say the order is complete. What it does here is it shows course one, course two, course three. What are the different items? And if there's a mistake, they can go and edit the order. Edit, go back and resubmit it. Or if they want to move items between courses, they can do that too. So they want to move the scallop and the soup to the top. It says a guest one, guest two is a lady. And when they're done with their, say, the initial they started the drink, they're done with the drink, they want to fire the order. They click the fire order, so that we don't have a printer connector, that's where I show in the error. It's an actual system. So what it does is it sends an order to the galley. So the galley says on how many items are to be prepared. So we actually created a printer profile. So printer knows it was a waiter printer or a galley printer. The waiter printer will show the guest information, what guest is handling what. The galley will have a collective information of, in the table six, I need five steaks, three of them well done. So it's a collection of all the orders. So we did printer profiles on thermal print. So if you see fire order, he can do complete fire orders. It actually tracks the time. There's another request from the waiter, because we had so many waiters, if you see, they didn't want conflict between themselves. They didn't want to say that, oh, I ordered first. I ordered first. There's no time when they just printed. So they can compare the print and see, okay, who did the order first? And they get the first preference so that there's no conflict. Because this is a feature that came from them. They're so quick, simple things. We built it with them, so it kind of worked. So once the order is complete, let's say that a waiter does multiple tables. That's what they do, right? They have multiple tables. So they go back and take another table and do a quick order here, same way. So orders were so quick and submit order. See, there's also a dynamic navigation between the different tables they're looking at. So that's what we built. So if I'm looking at my table number eight, I also know what is in table number six. It's course two. So we know how much time before the course was started, how much time the table has been waiting. We also had all this information also streamed to the MaterD. So if you go to the MaterD view, you don't have to view, where the MaterD can see that all the tables from every restaurant tells you that just like in the table six here, it says in the restaurant crown grill, it is table number six is on course two for the last five minutes. That information is streamed to the restaurant managers and MaterD to see what is happening in each table. This is visible shore side. A ship which is in Japan, it's a table in Sabatini is waiting for the last 20 minutes. That information will be shown to the corporate office. So that is a little creepy but it happens. So they can see it because the thing is customers are very important. They don't want the customers to wait and have bad experience. So here we know we can have flags coming up saying that okay 15 minutes, nobody should wait for 15 minutes. So you could have flags set up for, and then a remedy election can be taken. Maybe the MaterD goes up to their table, apologizes and gives them a bottle of wine. Something like that can be done. It's delighting the customer. That's a goal. So this is the table side order. Oh, that's an order. What do we have next? So that's a demo they're going to show. And thanks to Benish, he's our team member who drew all these diagrams. Custom drew for us. I made him draw around 30 versions of it. Because there's no other way to show what the complexity of the problem is. So thanks to him. And thank you everyone for showing up. Thank you very much. Any questions, please come up and talk. Please allow questions. Okay, that was phenomenal. And you guys both deserve a cruise. But here's my question. This is mostly back end, but I'm curious about the digital signage on the front end. How much work went into that? And did you have to follow any standards for like contrast or accessibility or type size, or is there anything that you need to do with that? Very good question. We initially, so how would I put it? It's a no answer. It's a website that we have on the front end is an Angular application which has its own playlist and system that we have built. The accessibility part we are working on now because we have a strict deadline to complete that. But on the digital signage, we have not done the accessibility side of things. So that's an open answer for that. Yeah. I understand. We are working on that for the Princess Etsy application. So once that is complete, that's our primary goal. Once that is done, we'll go to other applications. And Princess Etsy is our customer facing the primary application which is what our Drupal system is. So we are getting there. We are getting there. Yes. Amazing, absolutely amazing. Thank you. So I'm sure like with your app, you're level tracking, same thing with the room. Do you do any of that in restaurant like where maybe it's a key card for the room or is there anything like that that allows you to track individual user? We could do it. But the objective was not to do it for the main restaurants. We actually did a demo of using this key card to identify the passenger. But we didn't want to collect unnecessary information if it's not needed. But for the room service, we know the room number so that's all we need. Which helps in our GDPR thing too because we never collect any information that is not necessarily from the beginning. There's no point collecting all the data for the future in case we don't do that. And we delete most of the user information within the second voyage. Whatever is not needed. There's no need to collect information for more than a voyage and we delete it. And all the messages that we have messaging is all encrypted end to end. That is not the goal for the application to track users. But process improvements through data. What for this dessert? And it's going to be featured in this restaurant tomorrow night. Absolutely. But we have not... We could do it, but we scale back first to focus on the entire platform. Now we can go back. We had a lot that we are coming in. The objective was initially to save money and revenue by standardization. And now it seems like it's much more broader than even what business initially expected. So it's getting much better now. So what you mentioned here is very much a possibility. Thank you. Good question. Yes. Your existing system is built on Drupal 7 but you're migrating to Drupal 8? Yes. Have you exposed Drupal with APIs to these decoupled systems? And that's directly to Couch TV or do you have APIs on the Drupal side? What's that connection there? Very good question. Nate was a good person to answer this but I can help. And we ran into all sorts of problems. In D8, we in fact started with custom APIs and in last Drupal Con and just after that we saw the API, JSON API. So we started re-architecting everything. So we grabbed everything that we did and then we started with JSON API and that's the method we are going forward. So with your decoupled systems I think you mentioned that if Drupal is down they just only connected Couch TV Do they talk to Drupal at all? Yes. Couch TV system is a vendor to Drupal so what it does is it takes information from Drupal and periodically it goes and checks for changes in Drupal and updates itself so that even if Drupal is down the Couch can independently work because we don't want the customer to lose an order. That's a bigger problem so we have to change that level to have a different copy in Couch Absolutely. Thank you everyone.