 The top that I'm going to give today is that our pick is called Pricing Models for Android and press applications. Even though I have some slides, mainly it's not going to be an open chat kind of thing. Where, of course, if you want, we can go through all the slides. It will take half an hour, but definitely only 10 minutes or so for course. So, that way, we can keep it either way. If you want the top to be less than question and answer to be more, it's free. We can stop me in between if you have a question or something, or we can move all the questions in the end. Whichever works out, we will just use that. So, what I'll do is I'll start with a small slide. I won't take too much of time. I'll talk quickly about our company. So, my company name is CRMID. As the names are just, we are into CRM implementation. So, that's our primary business and we have done more than 100 implementations across the globe. For various kinds of customers from brands to universities to pharma companies and so on. So, that's our main business. But what we started doing is the last couple of years, we started making CRM mobile applications. So, we have worked on Android as one of our primary platforms. But we also have apps in Blackberry and Dyson. But our focus is mainly on Android. And these are our websites CRMID.com and CRMCCRs.com and you can see where it goes through. So, that is just to give a quick background about who we are. Because our entire focus is on enterprise applications, I thought I'll talk about that. Especially how to price enterprise applications. This is something like that. We have tried, we have made some mistakes, we have learned. And probably we are still making some mistakes and then trying to learn. I thought I'll share all that with you. So, basically the conflict starts in fun versus productivity kind of a, that's a classic question. How much of the enterprise application has to be easy to use, has to be fun? People say, hey, after all, it's an enterprise application. It need not be fun. Just go ahead and design it whichever way you want with probably what I was saying, like PC-based enterprise apps with 20 buttons, probably some 100 plus menu options and so on. But in mobile world, probably that doesn't work. So, here are the challenges. How do we balance this? Productivity should be there. If the job is to be done, then it has to be, that feature has to be there. At the same time, the application has to be intuitive and it has to be fun. So, that's where the classic puzzle starts. And to make things more complex, the expectations from people are entirely different in these two aspects, fun and productivity. For example, when you look at BlackBerry, it is seen more like an enterprise form. So, people assume BlackBerry apps can be as dull as possible. That's the typical mindset. People won't mind. They won't even complain actually. You give them a really dull app, but it's okay after all, it's BlackBerry app. And it is supposed to look like that. Whereas iPhone, even if you give a super functional rich application, if it is not intuitive, if it is not using the iPhone image, then people start saying, hey, it's not good enough. So, that's a conflict. Fortunately, Android is probably a place where things are still not clear. Is Android a fun form? Is Android a business form? Is it something mixed? Is it possible? First of all, nobody has achieved that combination yet. So, can Android do it? That's a bigger question. Let's not get into that. But as app developers, the challenge we have is how our application should look like, how our application should behave, especially when you... If you are building a game, this question probably will not even come to you. It's very clear. It's entertainment. It's fun. You want to design it as per that. But when you're designing an enterprise app, that's where the balance comes into picture. So, that's the thing. One thing that we need to remember is just because these existing brand images are there, it doesn't mean enterprises are going to jump into conclusion. For example, you make a beautiful, fun-filled entertainment application. Somebody may just pay $1, $2, $5 and then just download it and use it for three days. If they don't like it, they will just throw it away. Whereas enterprise apps are not like that. They are typically not bought by one or two people. They are bought by a corporation for 100 to 100 people. So, it is like you're trying to convince the community about your app, not a single person that mindset has to be with you. So, that means today morning, I will give you an example of a session we had with one of our clients who is sitting in Taiwan. And it was a really funny situation because the entire development team was here. We have developed the app. We have an Android tablet here in which we are running the app. It's running beautifully. But our salesperson is sitting in Taiwan, sitting with a customer in their office. He's also having the same tablet. But what's happening is the experience that we see here, the experience that he sees there is not same. And he's in front of a committee. Some 10-12 people are sitting and then seeing it and saying, why it works this way? It is not supposed to work this way. But for us developers, it works everything, everything is working fine. So, finally we were forced to kind of get into an approach whereby we had a video, send it to them, play the video to them just to give them a feel of how the app feels like. And immediately they started giving things like, can this be done, can that be done kind of thing. The meeting transformed from originally those committee members there to see our app and say it's good or bad. But now what they started doing, they started asking, can you do this, can you do that kind of thing. And at the end of the day, it becomes like they give ideas when they look at the application. So that's a mistake we did. We should have probably shown them a dummy HTML prototype and shown it to them, got their comments and then developed everything as per their requirements and then present that to them in a totally different picture. Now, that's a learning for us. During our today's demo, we are disappointed. The committee didn't like our app. They said it still lacks all those things. And we were frustrated because you never told us these features are required. You are only telling now. So they're saying, I only thought about it now. Go and build. So that's a conflict here. Building for enterprise is a tough thing. Especially when you have a committee. If a single person is there, yes. You can please or you can sum up. So that's why we have to be very careful when you are building enterprise apps. These are the typical expectations that we have seen in other clients. Of course, you may have something more to add to this list. This is from our experience. So typically enterprises are asking for these. Number one, they want flexibility. So I'm not going to buy same phone for everybody. I'm not even going to buy same technology for everybody. They will say, hey, let's say 30% of my workforce already has blackmail. I don't want to throw it up. Probably another 10% is having iPhone. Only for the rest 60% I'm buying Android phones. Now build something which works on all three platforms. That is one expectation. People don't want to invest except those companies which are still not gone mobile and they're starting now. So they can take a call. Okay, I'll buy Android to everybody if I have a decision. But that is very rare. So first one is flexibility has to be there. Does that mean you develop for three platforms? 10 platforms. What are now today? Nokia and Microsoft have come up with a new OS. What are we going to do? Are we going to have a fourth version of our app? That's the first conflict. Second, security. When compared to all other apps, enterprise apps require maximum security in two aspects, communication and storage. Communication, typically these enterprises will have VPNs and firewalls and all sorts of things. Let's say your application should be able to take care of that communication. Storage. If somebody leaves the job, I should be able to wipe out everything in their phone or if somebody loses the phone, somebody steals the phone, it should be secure enough so that somebody else who is getting the phone is not getting all the business data. So that's the second major thing we ought to think of. Third, data ownership. When you're offline, you do a lot of things. When you are offline, somebody else has come online and they have done a lot of things here. So what happens now? Two people trying to edit the same kind of data from two different places. Or two people using offline Android devices have modified the same data. So what happens now? So that is very important. People want very clear. This is one of the primary causes people will ask when are you talking about offline apps? The moment you mention the word offline in your presentation or your speech or whatever, the first question they're going to have is tell me how you're going to handle your conflicts. What are the rules? Do I have flexibility to control them? So that's another challenge. Of course, offline capability is a must these days, especially in India. If you're developing apps for India, offline capability will be seen as one of the primary things. So we have observed that 90% of your application or probably 90% plus percentage of your application should work without data connection. This is the expectation. That's what enterprises have. They say do everything local, just one sync button, everything should go online. So that's it. More than 90% people expect things to happen offline. That is one of the reasons why people go for these kind of devices. Then confidential data is there, then protecting that data and preventing this to use all sorts of things. It's all the questions that enterprise people have when you go in front of them and reaching an application. Now how do we deal this? Yeah. Can I ask you for advice? What I want to most, I'm from a consumer app background. I really don't understand what CRM app is. Can you give an example of CRM apps? Actually, I'm not talking about CRM apps in this presentation, but to answer your question, I think I have a very next slide. Yeah, this slide. So you see a fixed setup for apps, office applications, CRM applications, supply chain management, ERP, enterprise micro-blogging, and so on. But typically, most of the people who would have seen time sheet apps, expense report, kind of apps, these two are very common. These days, office apps are no more enterprise apps. Even though they are called office, they are no more enterprise apps. They are seen more like a personal productivity tool, but they'll still say it's kind of an overlapping. So these are popular examples. These are probably more niche. Yeah. You talked about how some apps meant to move greater to the visibility and other apps to the functionality aspect. Right. So in these apps, can you give us an example of an enterprise app that needs to cater more to usability or where visibility comes into the focus? Okay, see, I can, I mean, I'm not a heavy user of other apps. I can talk about our apps, what we did. One app that I can talk about is this MSCM, SCM is Supplement Change Management. So this MSCM app is something that we have developed. There is a free version available in the market and there is a paid version which we are selling it at enterprises directly. So when you look at this app, this app is a very simple app. Sales rep on the field goes to shops. Let's say a pharma company. So I go to a really medicine shop. They say these are the 10 medicines I manufacture. I want this, I want this, I want this, I don't want this. In each one, I'm giving a quantity. I'm basically recording it. And at the end of the day, I come to office and synchronize everything with this. So very simple, dull, boring application. We did it and we showed it and then people liked it. They all liked it and then it was good. But the moment people started using it, they came up with ideas. One very simple thing that people wanted us, why can't I just take the signature of the person on the device itself so that I avoid one step of acknowledgement. Otherwise they have to print acknowledgement, they have to get the signature there, go back to office, file it and all those things. So it's a simple thing, very simple. I mean, in phone signing it's not a difficult deal at all. But for that application, it made a lot of sense. And second one that they wanted, they wanted simple things like, hey, this particular product is no more sold in this particular store. So there should be some way I tell the company that, hey, this guy is not buying this product anymore, remove it from his list. This is another example. Like what happened is people started coming up with their own ideas and it could be UI related ideas also. They say, why should I click every tab? Can't I swipe? When I swipe, it should go to the next tab. When I do the reverse swipe, it should go to the previous tab. That saves a lot of time and day time. Basically they stand in front of a pama guy and they keep entering. If the whole day time takes 10 minutes and because of some usability improvements, it becomes 8 minutes, that itself is a big number for them. So that's where the usability enhancements, probably they will not be able to visualize it. But the moment they start using it, they come up with ideas, is this possible, is that possible, kind of all sorts of things they will come up with. And then we introduce things like taking a photograph of the display. For example, you are in a pharma company and your products are displayed properly or somewhere else products are not displayed properly. In your area, your competitor product is there. So you want to take pictures of them and then send it to the headquarters so that the action is taken, all sorts of things. We started adding it to the application. So it always starts with a feature-rich application and then slowly we start adding the UI elements to it. Unless and until, the enterprise to whom you are talking to already has a UI engineer or UI team which already says, which already knows how to make their applications better. If that is there, then that's probably the good case. They will tell you what to do. Otherwise, you are forced to guess and then do it. So about some of the things we talked about in the previous slide about what the enterprise expects from people who are developing the app. For some reason, I find it more like you are talking about I mean, if it's more like you are going towards more like an HTML5 version of the app versus the native application. I mean, I was trying to relate in that sense because most of the things which you said wouldn't happen if it was HTML5. Most of the things would happen if it was a native app because you would have to provide support for each and every single thing. So what is your view on that? Actually, most enterprise applications, do they rely on HTML5? I mean, internally, they use HTML5. They just show up a UI which looks like an HTML UI but it's not a regular native UI because it's built up of HTML5. They do that on most enterprise applications and they build for each Android and iOS and drag-bearing and development. To answer your question, this India presentation was prepared based on our experience in building Android native apps. We do work on HTML5 but this presentation doesn't talk about that. This kind of technology is not important here. What I mean to say is, your point is some of these problems may be solved by technology. So now, what it means is, we are getting into a framework kind of a scenario where we build a framework and on top of the framework, anything that we build will take care of these things automatically. HTML5 is a framework. On top of it, we can build something which may be a native app which internally uses HTML5 or it may be a browser-based app. It may be anything. So the point here is, as long as irrespective of technology, you make sure that your app takes care of these things, I added this slide to move people from the normal development mindset to what you should expect when you're walking into pitching an enterprise. That was my point. I'm not saying you should go for HTML5 or you should not go for HTML5 or something like that. That's not the point at all. Here, these are the expectations from the enterprise, what do you say? Customers, to use that word. And as long as your technology takes care of them, it may be HTML5, it may be something else also. I think you're safe. Like I said, if you use HTML5, some of these things, in fact, a lot of these things can be taken care of automatically. So that may be your solution. I'm not talking about development at all here. I'm only talking about pricing. Just to look at the same organization. You mentioned price, right? Price. It comes down to that from your technology. There are some applications that you mentioned in another slide. Activations. Right. Typically, applications that are existing prior to mobile enable. Right. They are desktop-based applications or web-based applications, browser-based applications. And just because you want an additional additional channel, you're kind of bringing subset of that functionality onto the mobile network. So essentially, there will be a lot of new use concept. These things are already built up in this particular architecture that we use in most of it. Right. A optimal reuse of whatever comes out. So now, in that part of it, and that's where pricing comes in. Otherwise, you can start building from scratch the same way. In this particular case, maybe versus hybrid or web or whatever, these things will definitely come into discussion, right? Because you're talking about cost, price, effort, time, everything. Yes. Actually, your partner's right. For example, the MSCM that I'm talking about was developed from scratch. There was no other app. There was MCM. There was already an app that we built for a different purpose. We just enabled a mobile channel too. So that meant we were able to reuse some of the things, but only in the back end. So that's where it's like, when you're deciding the price, in fact, I'm going to come to the pricing, the real pricing part of it. But when you're deciding to build the application, you should plan as much reuse as possible in the back end. That is our observation. Front end, it is better to 100% redesign without even worrying about what's a PC design. Most of the times, when we try to bring PC design assets to mobile, it flops. It flops, that's our experience. In fact, it helps not to show your design as the PC application. Tell them this is the function and they go and design something really innovative. What is the overlap if you are talking about developing a pure media application? Let's say the application that you have or you have a customer base for the application is going to be there. So it has a full architecture. Are you talking about creating an Android video application or an iOS video application? What extent can you reuse those components to really be the deciding factor? See, it depends on the, like I rightly said, it depends on the architecture and to what level the original developers were honest and whatever, loyal to the architecture. So I would use that word. For example, MVC seems to be the solution to this problem. If MVC was followed rigidly in every app in the world, probably it's very easy for us to build just the view part for every mobile phone and then probably save a lot of effort, but it doesn't happen. So what we have observed is if you are able to use 40% of your effort, you're lucky. That's what we have observed. Can you say integration with your existing legacy applications in the enterprise model is a limitation? Yes, it is a limitation. In fact, it's a part of the next slide. So these are the continued, actually. It was not complete. More enterprise expectation. So your backend connectivity, SaaS connectivity, access control, for example, I have 30,000 employees, all of them are already there in IELTS app server. If your mobile app doesn't talk to the app server, I don't care what features you have. I'm not going to enter all those 30,000 people in your system and maintain two different authentication mechanisms. For me, it should talk to my assistant. So access control, authentication, backend connectivity, SaaS connectivity, these days most of the apps are moving to the cloud, the software access service model. So that they want, then reusing existing investments like he rightly pointed out. We want to reuse. We invested so much of money and energy into building this. I'm not going to buy something totally new. For example, one classic case is recently we paid the problem. We were trying to picture HR application to a company. They already have a timesheet application. So they clearly said, we don't want your timesheet module. Our timesheet module is already done. Everything is working fine. We will use all other pieces, but only if your app talks to me, I'm interested in buying your product. As far as they are concerned, their investment is to be protected. So that is something you have to be able to accommodate. If you say, no, my architecture is really great, I will not talk to any other system, then finally you are going to be probably having a very narrow set of customers. You will not be able to go to the entire breadth of options. Then protection against future technology changes, of course. It is very difficult, people expect you to justify. Today I am buying your app, let's say one year down the line something else comes up which totally makes your app irrelevant what answer you have. So that way, that's where they are expecting you. They are not expecting you to give a what do you say, crystal glass view kind of a thing of future. What they are saying is, how ready you are. Are you following the industry trends? Are you aware of what is happening in the industry and are you ready to take up that when it happens kind of a thing. So that is also important. And then between IT managers and the developers, sorry, IT managers and the users. So security versus usability like she rightly pointed out. So those kind of things, there are a lot of things I think that lights are available, you can go through that, you have time reasons, I am not going through every one of them but I just want to stress to the point that they are entirely different. It is like speaking two different languages. Even though Android is common, even though HTML5 may be common, you keep using the same technology but end of the day, developing a regular app is not same as developing enterprise app. You need a totally different mindset for it. It is like writing a newspaper article versus writing a research paper. I am not saying it is countless. I am just saying it is more a different environment and you need to remodel your thought process itself and that is important. So these are some of the advantages of Android and other voltages. I think most of these you are aware I am not going to stress on them. Now this will be in the minds of the enterprise customers to whom you are talking to. So remember that these courses will be there, definitely. So they will say, hey, there is fragmentation. What is your answer to that? What if one of my users has a really bad, bad cell phone and your app refuses to perform. What is your strategy for that? What if I don't have connectivity in some area? Can you do it through SMS? All sorts of questions come into picture. This is something which is constantly in the mind of enterprise buyers. Their jobs are on the line. They have made a wrong purchase. So what I will do is I will directly go to the pricing models. This also you would have seen elsewhere. The typical pricing models, these are the pricing models which are normally used for enterprise apps. On the paper download, it's a very simple model. Pay $5, $3, $1, whatever it is download and then start using it. It's as simple as that. No headache. Second one is subscription based model where we call it as it's a mobile app as a service. So you pay probably zero cost upfront. Then every month you pay $0.99 or something like that for using the services. There are advantages you can enable feature by feature. Pay $0.15 extra and I will give you this module extra kind of. So you have flexibility. So that's the second model. Third model is a premium model where you give a demo version and if they like it they can pay and then upgrade to a full version. Fourth one is ad funded model where you show the ads. Second one is in-app purchases or a combination of these. When you look at the enterprise scenario this is our observation. What works and what doesn't. The general apps and enterprise apps. One thing very clearly ad funded apps are not working for enterprise apps. This example I have one of my colleagues told me I don't know how true it is or he made up the story. Once he was showing ad funded app they moved to a customer and he showed their copy of the app. And they were kind of like from there the meeting went down. So it's like okay that's not the reason I'm saying. Approximately ad funded are more opt when you're going for a general. People are okay. I'll see ad now and then but still I get a great ad for free kind of thing. But if you look at it a combination works a lot. That's where I put a five star based on our rating. Use a combination of these two. Subscription model, paper download and premium. These three when you combine you are able to do a lot of justification. That's what I would say. That's what I would use. So this is our observation. Of course this may change. Android is yet to introduce some of these features. So as Android does that I think we will see a different trend probably one year down the line this will become more richer. But as of now this is our observation. I think I'll just go in with our recommendations because of time reasons I only have five more minutes. This is what we have observed which works for and price apps. Start with a free version or a line version. This is something which works in both general apps as well as short great apps. Start with a free app. Do it in such a way that give it away anybody can download and then play with it kind of a thing. Just short version. Limited features. Start there. Then make a lot of noise talk about it. Have a dedicated blog. That is something which is important. Keep talking about it. Some people use cases how people are using your application how people are finding it difficult what features they want they've asked for it there is a pipeline. Keep telling about it and then post all these things to your social media channels. That is something we have observed. That talking about the app is very important but at the same time it has to be very subtle way. It shouldn't be like all gaps showing. And another thing in your app always have a about us or premium page. Many developers don't they make this mistake. Great app. There is no about us page. There is no about app. How do I buy the full version of what is this guy develop other things I have to go to market and see. That is a wrong model. Your app should say more about you. Just add about us kind of a button on click of it talk about you give the link to your website and stuff like that is something which is a real real value item. If required you can also say first time when you are running app you have the register. That way you have everybody's mail ready so that you can push messages but at the same time you have to take care of all the constraints. And another thing this is all about sharing and having a website. This is another thing I want to stress translate. Enterprise apps are useful when you translate. So we have observed that even the tiniest application it may have just 3-4 pages and then doing some very simple stuff. The moment you translate it and then say hey I support 8 languages the way enterprises look at you is different because most of the companies these days have a global workforce and they all want whether they use it or not is a different story. Some of the companies have English as their global business communication language but still they say is it supported kind of a thing. So that is something we support. But be careful if you are using Google translate that is where we all start. So you will be using some translator tool to auto translate and do it. Be careful about some countries which are very specific about this especially Japan. We had a very bad experience we did a mission translation, did a Japanese app and then went and showed it to a client and they were literally laughing at us. They were saying what sort of language is this who wrote this. When we said it is mission translation they understood. Now they didn't really feel bad about us but they still felt bad about the whole situation. They said hey this is not the way Japanese has spoken or written. You guys have got everything wrong. So that way I think you have to be careful if the deal is better invest in a real translator who reads and then says yes this translation is good or bad. So if you want some samples just try any language translation in Google for one paragraph. Just one paragraph of text you will know how idiotic it is in some case. Yes it's a good start but it's not good enough for enterprise. So that is something which is important. And moving from three to three this is where it's very important. What typically happens is it's normally it's done on a case by case basis. It's not like same formula will work for everybody. Some companies will say hey I'll go per user per month model. Some companies will say I'll go per user model but I won't pay anything per month I'll pay up front cost. Some people will say depending on the modules I use I'll pay you. So normally for enterprise applications one price list does not work that's our observation. In fact every customer with whom we have worked on on the mobile space we have had a separate price list for it that's my observation. I don't have two customers who are asking for the same pricing model till now. So that's what happens in enterprise apps unlike general apps. In general apps it's very clear. You pay 499 dollars and that's it. Or you pay 0 and pay 99 cents every month it's very clear. It's kind of same price for everybody. But in enterprises it's different for different enterprises. That's what we have observed. I think just to summarize these are the three points that are kind of for a take away kind of thing. Pricing model as well as pricing process for enterprise apps is entirely different from a general app that is one point. Number two but these two have a common thing which is starting with a free version. Once the free version works then they will move to the we have observed that the feed rate is somewhere around 20 to 30 percent now. But it will improve depending on your app quality and talk a lot about your app until your customers start talking about it. So I think those are the three points and I think that completes my slides so we can take up course. Yeah. See typically what we do is we have a fixed price list. Okay. We invested this much money on building this application and I want to retrieve it in 18 months, 36 months 60 months whatever it is. That's a standard price. That's in a perfect world. It will work. Everybody will go and pay whatever price I'm saying and I'll recover that cost. Now once that is done now I take the client. The client comes and says hey if you give me this kind of pricing they are not bargaining. They are saying your per user per month model is not working for me. This is the model which is working for me. If you give me in this price then I can give you a guarantee of 5000 users in 36 months kind of a thing. So now you recalculate. Okay. If I go by my regular price list this is the benefit. If I go by this commitment that the customer is giving this is the benefit. Then I compare and then I take the cost. It is very difficult. There is no real mathematical formula here. It's more like how it works. At least in our case more happy customers are there. We are confident that the product will grow. So what we are doing is initial days when we release the product we are ready to make compromises. But slowly once the product is solid and everybody are using it and people can talk great things about it now it's not that we are increasing the price or something. We are a bit more rigid. These are the 4-5 options which we are open. All other options it's not working out for us kind of a thing. So basically we are at the back stage for this. Be more flexible in the initial days until your product is stabilized. After that you can come. Still it can't be a single price. At least you can have 2-3 models. You can stop there. That's too late. So the enterprise industry in paper download and suppose they have like 5,000 people. So how do we ask them to implement this? How do they rate download? Number one, typically these things don't go to the market. These things are typically posted in one of their intranet servers and we will say that anybody who wants to use it have to download it from there and we will put a counter there to check how many people are downloading. And we will disable the phone transfer and stuff like that just to avoid people doing one download and then multiple people using it. So typically the distribution is through outside market. Inside the intranet of the customer. Most likely your app will be very much customized to that customer. You will not be selling the same app to every customer. Definitely you will be making modifications to that customer. So it makes sense to put it inside their intranet. We have tools available. That's not a complex thing. In fact, that's probably the easiest thing. That is not a problem at all. The tough thing is getting a model which works for both you and the customer. When we're talking about pricing, when we're talking about pricing, we're talking about producer. Actually the requirements are like at a higher level. I got it. Actually How do you estimate and give more for the figure? Actually we are not experts in that to be frank. We are more like we built the application. We try to sell the application as such. But invariably customers come and ask for customizations on it. Which we can estimate easily because we have already built the app. We know how much extra effort we take to do it. But when you're starting from the scratch, let's say Indian government releases our developing mobile app. We are not experts. It's not that we can't do it. Probably somebody else will answer that question. Free on the market helps. Is your experience with enterprises users downloaded and tried? Very much. Everybody. In fact, everybody are asking for market you are. That's the first question they are asking. Where is the free app? Let me download and use it. We have observed that in some companies people go out of their way to buy an android phone, download the app, try it and then go to their manager and say yes, this is a good one. It's basically people are willing to make that thing because people are becoming more and more confident about the capability of android and on top of it your app adds value. So yes, it happens a lot. And in fact that is one of the strongest what is it? Promotions that you can have. People going to market, typing some words searching and finding your app is a real even in enterprise. In terms of the market strategy, what has been your experience in terms of approaching the enterprise as a consumer? We are partnering with telecom value chain players such as an operator or OEM who have a strong enterprise strategy and especially in emerging markets such as India. In two cases we have tried to go with a telecom partner but in both cases for some reason it didn't work. So what we have observed is there is very little value add that telecom provider can do in this case except in those cases where there is a very big account where the telecom provider has already a very huge market where the distribution support especially support. In that case they can do the real value add and they also get benefit let's say X percentage of the total revenue whatever it is. In such cases having a telecom provider really helps. Otherwise what happens is not interested. Maybe you are willing to work with them but for them it's a very small pipe. For them selling a general app to millions of people is much more making sense than investing in this. So that's what we have observed. For some reason they end up selling as silent partners. Okay I have a great network you want to come with me, you come with me. That's where they stop. They really don't do any value add to your actual selling process. And is it specific to emerging markets in both our cases because in India only. I am not able to compare it with outside India. Thank you for being here. Please give him a big round of applause.