Visitor Monitoring Keynote Tech Talks: Watching SaaS Apps with Keynote | Keynote
Webcast

Keynote Tech Talks: Watching SaaS Apps with Keynote

About the Webcast

SaaS has transformed your business. The numbers say you’re running at least 4 apps today (we know Keynote is at least one of them!), powering everything from Sales to Operations to IT. SaaS delivers agility.

So why would you need to monitor Salesforce.com, NetSuite, Marketo, or Office365? The more you run on SaaS, the more your business resiliency is dependent on actionable performance insight.

The webcast features Aaron Rudger, Senior Product Marketing Manager at Keynote and Gene Morris, Lead Solutions Consultant. Watch to find out:

  • The limitations of vendor SLAs and system status transparency
  • What you can do to manage service disruptions
  • How to use Keynote Web Monitoring to monitor SaaS applications
  • Learn how Keynote can provide the data you need to get proactive and get the most from your SaaS solutions.

Learn more at Web Monitoring for SaaS Applications.

Webcast Transcription

Aaron:

We’re going to be talking today about a subject that is not necessarily imminently core to everyone who is a Keynote customer today, but really is, in fact, part of the day-to-day lives and business responsibilities that we all enjoy in our working relationships. And that is how we get the most out of our software as a service application. And so we’re going to be talking about ways in which you can really leverage that investment that you’re making today in your software as a service or your SaaS apps, to be more productive, and to be more responsive so you can get the most out of your business agility.

Let’s get into a quick overview of what we’re going to be discussing here today. And as I mentioned, we’re going to be learning about basically SaaS applications, their role, and their opportunity within an organization and an enterprise, how they’re changing the way we do business today, and what that means in terms of taking advantage of that service and how it’s delivered by the service provider.

And really, when you look at how it’s delivered by that service provider, understanding what their service level commitment or service level agreement, or SLA is, is a very important thing. But then more important, you need to understand how you can take a proactive approach to managing that service level, and how Keynote web monitoring solutions can help you in that exercise. We will do a live Q&A session at the end of the prepared demonstration today, which includes a live demonstration from my colleague, Gene Morris, who is a lead consultant here at Keynote Systems. 

It’s interesting, as I mentioned at the top, everybody pretty much is familiar with SaaS because we’re using it today, right? SaaS applications are really extending more and more into the various aspects of the way in which, from a business process standpoint, enterprises are facilitating how they go to market, how they interact with their employees, and the logos that you see here are just a small subset of the total universe of applications that you can now basically interact with through this new service model, including Keynote, which we’re happy that you’re a customer of today, of course.

But the question really is, if you’re now delivering these applications as a service, how are you really managing that service? And where typically or traditionally in the past, where we were managing on-premise software implementations and backing them up with an entire IT organization that had very real commitments, that were very really accessible, and held accountable to the delivery against those commitments, SaaS is a different dynamic. Let’s drill into this a little bit more deeply. Today, according to Forester, more than 50 percent of enterprises worldwide have adopted SaaS applications into their business processes.

And so they are, as I said, managing both external-facing as well as internal-facing business processes. And on average, the number of applications adopted by these enterprises is around four. But the growth rate continues to accelerate. Where SaaS began and was introduced maybe in the mid-2000s, it began to really get traction by the end of the decade. Now the acceleration has really hit full speed, and we’re going to see basically a doubling every year. So the average will lift to about eight applications. And the reason why people do this, of course, is because of the great agility that it offers to you as a business organization.

You have the ability to customize the application. You have the ability to flexibly adopt it in the context of your usages as an enterprise. As your enterprises scale, you can add more subscriptions. As perhaps your user community begins to contract or constrict, you can remove user seats, right? And that gives a lot of flexibility to an organization that’s trying to be nimble and trying to be agile, and agility is a really important dynamic in today’s business climate. So the question that I would ask you is what about your company, right? So I’m going to go ahead and bring out a poll here, and just ask you guys if you can – if everybody participating on the webcast can go ahead and answer the question in this poll – and I’ll just advance here to this slide.

The question is, how many SaaS applications is your company using today? And if you could answer that, we’d appreciate it. We’ll give you a few minutes here. And while everybody is answering the poll question, I want to bring Gene into the conversation. So Gene, good morning or good afternoon. I know you’re on the east coast. Welcome to the webcast today. How are you doing?

Gene:

Thank you. I’m good. Good, how are you?

Aaron:

Great. So just out of curiosity, Gene, today’s fun fact, if you will, I’m going to put you on the spot. Do you know how many SaaS applications Keynote uses today?

Gene:

Let me think about that. I know we use JIRA, Salesforce, I would say four maybe.

Aaron:

Hold that thought. And let’s get the number of results from our poll, and we’ll broadcast these results. OK, so everybody can see the results now. It looks like we’re somewhere in the – kind of the 5 to 10, maybe a dozen – that’s a pretty high adoption rate, right? So that already suggests that the audience here is a little bit more forward-leaning than what the global trend is at around four applications. Right? So Gene, fun fact, Keynote uses 10 SaaS applications.

Gene:

Wow.

Aaron:

Yeah. So definitely a prevalent part of our lives here. And it looks like definitely a prevalent part of the way that our audience is also managing their business. I just want to talk a little bit about the downside to using SaaS applications. And it used to be, when we were, I think, still fairly immature in the delivery of software as a service, as a community, and when I say “we,” Keynote is also a SaaS provider. I’m including us in this as well. The notion of a service outage was something that absolutely caught a lot of attention. And there were some very famous outages that occurred over the course of the past five years or so.

And these have put a bit of a black eye on the SaaS community, but at the same time, those outages and big events that used to occur – I don’t want to say with frequency – certainly have diminished. And as a community, the SaaS provider community has gotten much better at maintaining very stable and continuous delivery of their services. The question that I want to pose to you is, what about those outages or those disruptions – and they don’t even have to be outages, right? Global outages that affect a huge population.

But what about those more minor disruptions that don’t make the headlines? And how does that impact your business? Seed that thought for a minute before we talk about some other aspects here, about your SaaS applications. I just want to pose another question to the audience here at this juncture, which is about when those disruptions occur, if you’ve ever experienced them, and presumably you have – because no IT system is prone to 100 percent reliability. We’re talking about technology that’s written by humans, and because of that and the need for change, disruptions will definitely occur.

But when they occur, when you personally have experienced that, who did you call? Who was the resource that you went to? Did you go to that SaaS provider’s help site? Maybe enter in a query in some kind of customer support page, or go to a help page. Or did you call your IT department and ask them if they could fix the problem? Was there somebody else that you went to? So from the audience standpoint, where have you gone for help inside your organization, or outside your organization? I think we can probably close the poll and share the results with everybody.

It looks like most folks have actually used the vendor support system. That is a great resource for a lot of companies, and for a lot of people to go and get support. And of course, that’s what the vendor would like as well, right? But there’s still yet a significant number of respondents who actually turn to their internal IT help desk for support. Let’s explore a little bit about what that means. When SaaS is adopted across your organization, it’s usually fulfilling some major business process, right? There’s a line of business that’s sponsoring that business process and is using the application and the flexibility and agility of that application to deliver that business process.

But the reality is, it’s a shared experience, and we work in large organizations, or maybe even small organizations, but organizations that have an IT department. And when problems occur, and when minor disruptions occur, and the calls get placed into that IT organization, that leaves the IT organization in a bit of a quandary. There’s a potential for a little bit of exposure and risk there because the IT department doesn’t control that application. It’s running outside your environment. It’s running outside your control. They may have been involved in the contract negotiation, but fundamentally, they’re not in charge of managing the day-to-day service level commitment.

That can create some disruption inside an organization, and that’s an important dynamic to understand. Let’s talk about that service level commitment. Most SaaS providers today do provide a contractual service level commitment, an SLA. The reality is that there are planned outages and there are unplanned outages or disruptions, and they do occur, again because we’re talking about software. It’s important to understand what exactly your service level commitment is. The guarantee of 99.9 percent uptime is the typical, that’s kind of the standard delivery or commitment that we find in the marketplace.

But it’s really important to understand exactly how does your SaaS provider define that uptime? Is 99.9 percent of uptime defined in terms of the amount of time you have, that the portal is going to be accessible by your end user? Is it defined by the number of transactions that a critical application is facilitating? Let’s say you’re using an application like Zuora to facilitate online subscriptions and payment processing. Is your commitment defined by your access to the application? Or the application’s ability to actually process those transactions? You’ve paid for that service to actually do something.

Is your commitment to the delivery of that business process, or some other IT artifact? And other aspects of your commitment may also be covered that relate to security. They may relate to the portability of your data, when you decide perhaps to discontinue your subscription. They may relate to the timeframe that your provider may acknowledge a service request. You know, going back to that previous poll, where we asked the question about who you call. You know, do you have a service level commitment to the responsiveness of that customer service interface?

And of course you also want to be thinking about the failover and recovery capability of your application provider. Do they also commit to a specific and measurable delivery with regard to recovery against some kind of outage event or catastrophic failure? A lot of times, SaaS providers will also make some of this information available in a publicly acceptable online forum, like a trust page. Typically, these trust pages provide information about the general health of the system, whether or not the system is currently up or down. And if there is some kind of disruption, they may also include information about that disruption.

What occurred, when it occurred, what was the duration of that disruption? In the example that I screenshotted here, this is actually a clip of the Marketo marketing application trust page. And I’ve highlighted a little event notification that you see there. This is actually something that hit home to us in the marketing organization, where we’re a Marketo customer. We use Marketo. We love it. It’s a great service. And we were actually having a group meeting, and during the group meeting, the Marketo service went down. It went down, and at that moment in time, what that meant to us as an organization is that all of our lead forms that we used to capture interest in Keynote services became unavailable for our users.

Obviously, that impacts our business. When we went to the Marketo trust site, at that moment, the system status was green, and everything was good. Now subsequently, hours later, Marketo did update the fact that a disruption occurred, and they provided full transparency to the fact that that outage occurred and why, and when it was – how long it lasted, and what are some of the reasons why it happened. And that’s great. As a customer, we appreciate that transparency. But that doesn’t really help us in the moment of the event, when the downtime is actually occurring and impacting us.

All right, so let’s look into – just kind of peel the onion a little bit deeper around what 99.9 percent availability means. It’s actually a calculation. It’s a simple calculation, and what it boils out to is essentially 43 minutes of downtime per month. That’s an important number to have in the back of your mind. Because as you are looking at what your exposure is, as a customer and a business, in terms of trusting your business processes to this application, you need to understand the fact that that 43 minutes may happen, and it may have an impact on your business.

So it’s a good idea to start looking down the road at how that 43 minutes could impact you from an investment standpoint, from a risk standpoint. How are you exposed? Is it on the basis of disruption to employees, and the potential for them to create service requests inside of your IT organization that you may not be able to respond to very well? Is it, as it was for us, in the case of that Marketo outage, the loss of some leads, at a cost to us? Or perhaps some other monetary conversion that would be of greater value than just a lead.

It’s important as a business for you to understand that, because then you can make a good decision about how you manage that application, how you manage the vendor, but also how you manage expectations internally, and how you look at your business processes as a whole. And the reason why it’s important to do that is because not all downtime is created equal. Downtime at the end of a quarter, if you’re running on some kind of financial application and you’re trying to do end-of-quarter close, is much more meaningful than downtime in the middle of the quarter.

The reality is that when you’re thinking about creating your SaaS application relationship, and that relationship with your vendor, you do really need to think about, “is your business process able to gracefully degrade?” Because again, outages will happen. You need to understand how long and for how intense those outages are going to occur, and what you can do about it. With regard to disruptions, you might set up some kind of decision tree or understanding around your outage and what you can do about it when it happens, what it might mean to you. It might look something like this.

This is just something that we put together to help us understand for some of the application scenarios that you might actually have in your organization, what those might mean to you and how you might be able to impact or influence them. Fundamentally, we believe that the key to understanding what your potential exposure is and what you can do about it, is having the right information at the right time. Because that allows you to trust your application provider, build and foster a greater relationship with them, and get proactive in that process as well.

So if you have information, you have data in a timely fashion about disruptions, performance degradations, we believe that gives you a lot of power in proactively managing your relationship. And we’re not talking about holding your vendor accountable for the purpose of exacting a credit against your subscription to them. Feel free to do that, if there is a pretty catastrophic failure, and you can obviously use data to back up objectively any claim that you might want to make. But more importantly, having that information in a proactive fashion allows you to take action to do something else.

For example, with that Marketo outage that we experienced, if we knew exactly when it was happening, we could have taken action to change our marketing that was pointing to all of our lead form pages to maybe point to our Facebook page or our LinkedIn page. And then we’re not losing people to a completely unavailable experience, but rather an experience that is, as we suggested, gracefully degraded. You could think of other scenarios.

Perhaps knowing that you’ve done a change recently in your network, and that has suddenly resulted in a WAN configuration issue that left your branch offices or your call centers in remote locations unavailable to connect properly to the internet and get access to the service. Again, having information that allows you to isolate those potential root causes, gives you the information you need to take corrective action and fix the issue.

Enough about this general stuff around SaaS and what it means to you and what you can do about it. Let’s start talking about what we think Keynote can do to help you in managing this, to help you get that proactive data that you need to actively manage your relationship with your SaaS provider. At this juncture, I want to bring in Gene, and Gene’s going to demonstrate to you what the Keynote web monitoring service is doing today for us here at Keynote, to help us manage some of our SaaS relationships. So Gene, I will hand it over to you.

Gene:

Great. Thanks, Aaron. You can see my screen says Login to Concur, Concur Solutions.

Gene:

As our example today, we’re running a bunch of scripts against various SaaS services that we use. Apparently, not nearly all the SaaS services that we use. I underestimated in that. But right now I’m taking a look at Concur. And we’re simply logging in and logging out. I thought, let’s have a look at yesterday, and see what things look like. So this top part of the chart – and we’re running that script, by the way, that measurement script on 10 major U.S. cities all around the country, hourly, from each of those ten locations.

So we’re amassing quite a good amount of data and getting good insight into what’s going on. And so we see here this top graph shows for the successful completions of that measurement script, what the average time has been to complete that. And we can see that towards the latter part of the day, it definitely slowed down. And we also see below that, the availability. That’s the percentage success rate. Out of the total tries, how many were successfully completed? You see that, it was not 100 percent the entire day. There were a couple of dips. Let’s dig in a little bit deeper. I’m going to take a look at a scatter plot.

Each dot here represents a time that the measurement script ran, and if you’ve been a Keynote customer and using us for monitoring, this is probably going to look very familiar. And the color scheme, of course, is green is good, successful measurements. And red is bad. We notice, first of all, that there is a preponderance of green, and that’s good. But there are a couple of failures here. And let’s just click into one of these. For example, this one I’m hovering over from the 13th at about 9:20 in the morning Pacific Time. If I click into that, I see we failed. That E is not for excellent, but for error. We failed on the very first page.

Before I even drill into this and do anything further, notice here on the right, we capture a screenshot when there’s an error, of what was actually presented at the time, and we also have a reference screenshot from one of the successful times that we ran to compare with. We should see something like this for the first page. But sadly, we saw this. This Concur Service is currently unavailable. First of all, we can see right away that there’s an issue, and that the issue would seem to be on the Concur side, since that’s an error message put out by Concur. If we need further information, I could click in here to view the headers, and it’ll show me the actual request and response headers.

I can also click into the bar here to see a waterfall graph of what happened and when, each of the calls in order. But in this case I think what we really wanted to know was summed up by the screenshot and error where it said that the Concur site was unavailable. Let’s take a look at a successful data point that’s slow. Because it may not be that the site’s unavailable, but if the site is slowing down to a painful crawl, that can have a deleterious effect on your business and the user’s experience, etc. So let’s click into – let’s pick this guy here. Let’s see where the slowdown was. So here are the three steps.

And that first page was very speedy. The second page, likewise, fairly speedy. And I think we can see here that the logout was very slow. Before I drill into that though – actually let’s go ahead and drill into that. But what we see is that it successfully completed, and the slowdown did not stop us from logging out. Now the fact is, if I look over here, this first call to logged out ask, took 27.6 seconds, of which almost all of that was just first by download time. So just to get the first packet of data, which typically does point to an issue back on the Concur side, rather than a slowdown along the internet.

But in this case, I might not necessarily worry about it because a slowdown occurred on the page when we were logging out, and realistically, your users of a SaaS service, if they’re at the point where they’re logging out and it’s taking a while to log out, they’re not going to sit there and wait until they’re completely logged out. They’re just going to go on and do something else. As opposed to, if they’re waiting to log in, and trying to do something in the service, then that would certainly be a much, much bigger problem.

Aaron:

So Gene – I think that’s a really important concept here to make sure that everybody understands, is that we’ve actually, in this scenario, set up a script where we’re monitoring the user’s journey of going through the login and then entering into the application, and then logging out.

Gene:

That’s right. And just to further comment on that, what we don’t recommend is writing a monitoring script that’s going to cover every possible aspect that a user might take in a journey through the website. That would be absurd, and very difficult to maintain, and it would not be especially informative. At the very least, what you want to do is to go to log in and log out because if you are unable to log in, or even reach the site, that is certainly a huge problem.

But if there are certain key tasks that you want to follow, you certainly could have a script that logs in and then maybe loads up something in Concur, and this would presumably be a dummy account that you set up for test purposes anyway – you could set up some kind of test information and look for that and have that as a step in your script. But at the very least, we recommend doing what we’re doing here, which is logging in and logging out.

Aaron:

And you know what else is interesting about that, Gene, and you can attest to this, is that as a user of our Salesforce application, oftentimes, companies tend to integrate multiple SaaS applications. For example, we have our NetSuite application integrated into our Salesforce application so that we can look at some of the entitlements and other financial information associated with a customer account. That might be of interest perhaps to companies that are looking to guarantee that, OK, I’ve got one application here, but it’s actually in some way dependent on another application, and so maybe I need to drill in a little deeper to validate that the entire chain, so to speak, is working together.

Gene:

That’s right. That’s a great point, Aaron. You could have a script that goes to Salesforce, logs in, and then goes into that application that’s within Salesforce, that another party has integrated into Salesforce. And the beauty of using something like Keynote is that you’re able to get the end-user perspective. This is the same thing that a real person would do. This is what we’re doing with synthetic monitoring, with robotic measurements, if you will.

Aaron:

We had one question in real time here from the audience. You had very quickly shown how you can drill into a page header, and there was just a request to see that again, if you could.

Gene:

Sure, sure. So we grabbed the headers when we had a failure. Let me just find the fail data point here that I had drilled into. I drilled into a failed data point in the scatter plot, and then you see below the error screenshot, there’s a link that says View Headers. And I clicked on that. That took me to the actual request and response headers. So here’s my very first request. It’s a get for www.concursolutions.com. And note if you will, by the way, I can see user agent string, and Keynote always inserts within the user agent string. This isn’t really so much of a SaaS thing, but it’s just a good general Keynote knowledge thing.

We put in a unique identifier that will say this is Keynote. In this case, it’s TTXN saying it’s the Keynote transaction perspective, a real browser service. And then further identifiers telling us what we call the time or the number of seconds since January 1, 1970, an agent identifier, a script identifier, etc., so that if we wanted to follow this through our server logs on our side, we could then search for this specific string and find those hits within our system. But that’s a little bit of an aside. You’ll notice that here we got back at 3:02, and we can see that response. And then the next request header, the next response header, etc.

That kind of covers what I was going to show here. So I don’t know what else you’d like to go into here.

Aaron:

Thank you, Gene. That’s great. I think that’s a very practical way for people to get a sense of how you can use the service, our web monitoring service, to do some really healthy and proactive validation and management of your SaaS application. In this case, that’s very useful information for us, relative to how we’re managing our relationship with Concur. If our internal IT organization had access to that data, which they do, then they can really quickly have information at their fingertips that can be useful in managing potentially employee requests or inquiries that come to them, with regard to accessing the Concur application.

We can provide that information to be useful back to Concur as well, which is nice. Let’s just talk a little bit more about what Gene showed you. He showed you in real time, live, what the Keynote web monitoring service can do, in the context of monitoring SaaS applications. What I thought I would share with you is a quick overview of what that looks like – and what we’ve done here for customers, to make it easy for you to get additional value from your Keynote subscription today, specifically for this application, for this use case.

The Keynote web monitoring for SaaS applications package for you is a pretty straightforward offer. We’ve created predefined scripts that go through that very simple transaction or user journey that Gene shared with you, of going to a login page, entering in the credentials, opening up the application, and then logging out. It’s a three-step process, and that three-step process is really, we think, the best practice for helping you understand your application availability and performance.

We’ve defined these scripts for four applications currently today: Salesforce, Office 365, NetSuite, and Marketo. And of course, as Gene showed you, feel free to add additional applications beyond the scope of these four. But these are the ones that, out of the box right now, we have ready to go and are prepared to help you with.

You can basically stand up measurements from the Keynote cloud of public monitoring agents, and specifically, we’ve got a special kind of deal where if you stand up for the three-step transaction on five of our agents – we have both international agents that you can choose from, or domestic North American agents – and you monitor at a frequency of around every 30 minutes, that’s a very simple and easily consumable price for you of $229 per month per application. We also give you the flexibility to implement our cloud perspective monitoring agents.

Just for everybody’s reference – because we’ve talked about them in the past, but the cloud perspective offering allows you to, in the form of a software agent, install the same monitoring technology that we use on our network, inside your local environment. So if you have, for example, a call center that’s located in the Philippines, and you want that end-user perspective from that location, we give you a very simple package that you can easily install on a device inside your environment there, and give it some very simple instructions, and it’s all administered, again, as a service, through our online portal.

We’ll begin giving you back measurements through the online portal and through our service, just as it would from a Keynote public monitoring agent location. Hopefully that’s really interesting for you guys. We’ve had some success with some of the early exposure. We provided this to some of our customers, and we think that this is a great opportunity to add value.

And so with that, I think we will start taking some of our questions here. As a reminder, I know that a lot of people have been submitting questions using the Q&A panel at the bottom of your Adobe Connect screen. If you’ve been in full-screen mode at this point, we do ask you to come out of that so that you can actively use your Q&A panel. We’ll take as many live questions as we can in the time we have before the top of the hour. As you see, we’ve made additional information available to you. The slides in this presentation are available for you to download by clicking on the download presentation panel. We also have another panel on here that allows you to get more information, and it takes you to a little web link that we think might be useful.

We’ll answer some of these questions here. So Gene, I’ll ask you the first question: If I’d like to monitor a SaaS application that’s not listed on the previous slide, is that OK?

Gene:

Absolutely, yeah. And it’s very easy to do. Honestly, it was not difficult to set up the scripts that we were using in today’s example. If you’re familiar with KITE, which is the GUI with which you record and play back Keynote measurement scripts, it’s a simple matter of, if you haven’t downloaded KITE and installed it yet, go to kite.keynote.com and download it and install it. And then you just hit the Record button, entering your starting URL, and type in your credentials, and then you log out. And something that you may want to consider is, depending on the app that you’re going to be monitoring, you may need to whitelist the IP addresses of the Keynote measurement agents that you’re monitoring from.

I know that that’s a concern with some apps like Salesforce or Marketo. And of course, the account that you use to log in to that app and your monitoring script, it really should be a special account that you’ve set up for monitoring purposes only. You shouldn’t use somebody’s actual account, but something that’s set up specifically for that. And that way, bypass any potential security restrictions. But in terms of just monitoring something that’s outside what we mentioned today, if it’s a SaaS app, it should not be a problem to monitor it. It should be pretty simple to set up.

Aaron:

So a follow-on question to that: do I need to write the KITE scripts in order to start running tests? Do I need to do that, or can you guys help us with that?

Gene:

If it’s any of the four that you mentioned, four apps that you mentioned today, we have script templates available that we can provide to those interested, and then it’s just a matter of taking the script and putting in the login ID and password that your script needs to use to get into the app, and you should be good to go.

Aaron:

Good deal.

Gene:

Otherwise, it’s just what I said before. You just record a new script.

Aaron:

Yeah, it should be pretty point-and-click, right?

Gene:

Mm-hm, yup.

Aaron:

Excellent. So, this is an interesting question: how do SaaS providers feel about having all of their customers running monitors against their services? And I’ve got a thought on this, but Gene, maybe you have a thought?

Gene:

Well, of course you’re going to be holding their feet to the fire in terms of if there’s a problem, you’re going to be bringing it to their attention right away. Maybe a little more quickly than they may feel comfortable with. But the other side of the question, I feel, is maybe a question of load. This should not be placing significant loads. If you use the measurements we went through today as an example, the Concur measurement, for example, that’s running – just going to the site, logging in and logging out, running that once an hour from each of 10 measurement agents –that’s 10 hits in an hour, that should not be anywhere near causing a problem for Concur.

If something like that is going to cause a problem, then you have to have some questions about the robustness of the SaaS provider that you’re using.

Aaron:

Yeah, certainly. And I think another dynamic of that question too, that’s something that we would absolutely not shy from talking about, which is, you know, as a SaaS provider ourselves, right, how do we think about monitoring and providing monitoring of our service? I would suggest to everybody that Keynote is probably the most heavily monitored SaaS provider in the world. We are extremely heavily instrumented across our network. We have all of our agents not only monitoring our customers’ services, our customers’ website, but they’re actually also monitoring each other.

We’ve got a lot of not only internal monitoring, as you would expect of your service provider, who’s delivering an IT service, but also a lot of external monitoring of our service from our agent network. Rest assured that we definitely drink our own champagne here at Keynote.

Gene, I’d like to thank you for your time and providing a wonderful demonstration. It was great to have you here.

Gene:                          

It was my pleasure. Thanks for having me.

Aaron:

And I’d like to thank everybody in the audience as well. We thank you for your attention and your patronage of Keynote and your interest in the subject, and again, if there’s anything that we can follow up with you on offline, outside of this presentation, feel free to connect with us at either info@keynote.com or events@keynote.com, and we’ll be sure to respond to your request in a very timely fashion.

Duration: 48 Minutes

Back to Top