Inductive Automation Blog

Lauren and Shay meet with the MES Product Manager from Sepasoft, Keith Adair, to discuss using MES to improve customers’ operations, increase production efficiency, and the best way to communicate all of the advantages of using MES to customers. Keith shares details on the modules that Sepasoft provides and how they work with Ignition. Keith also talks about using the modules enterprise-wide and Sepasoft’s Business Connector Suite. Learn about a flexible, all-in-one solution by combining Ignition and Sepasoft Modules, and best practices for presenting those MES solutions.

Lauren and Shay sit down with the Co-Inventor of MQTT, and CTO of Cirrus Link Solutions, Arlen Nipper to discuss selling MQTT. Arlen talks about how the addition of MQTT modules creates a more efficient SCADA system and how that solves current system issues and creates an infrastructure ready for digital transformation. Arlen discusses the partnership between Inductive Automation and Cirrus Link Solutions, the MQTT modules, the key selling points, the Sparkplug specification, and the guiding principles of utilizing Ignition and MQTT. And we get to see Arlen do a demo!

Lauren and Shay invite Co-Director of Sales Engineering Travis Cox to walk us through architecting an Ignition system, and to show how Ignition can be used anywhere from a local HMI client to a full enterprise solution and everything in between. Travis shares best practices for getting started, building a foundation, asking the right questions, and building out an architecture. Travis begins with the structure of a basic Ignition architecture and explains the process of when and how to build out from there. We cover adding new functionality, adding redundancy, store and forward, Ignition Edge, MQTT, scale-out, adding a load balancer, streaming data to the cloud, and having visibility across an enterprise.

Lauren and Shay are talking with Training Content Manager Paul Scott about how to identify the correct modules for specific customer needs and leveraging those modules for successful projects. Paul covers the correct time during a sales process to bring up these modules to educate a customer, not overwhelm them. Paul covers the level of knowledge you should have on the modules, what to understand about the customer’s project, and ultimately determining the best module by breaking up the solutions into categories: device connectivity, data logging, visualization, reporting, alarming, and enterprise solutions. Paul gives some examples of what modules might be the best solutions under certain circumstances.

Video Transcription:

00:08
Lauren: Welcome back to our Sales and Marketing Training Videos. I'm Lauren.

00:12
Shay: And I'm Shay. Today, we're talking about identifying the required modules for customer projects.

00:16
Lauren: We're sitting down with Paul Scott to talk about how to leverage the Ignition modules for success. Paul, thanks for being here.

00:23
Paul: Thanks for having me.

00:25
Lauren: So today we're talking about identifying the best modules for your customers and projects. When do you really start talking about that in the sales call process or in the sales process in general? 

00:37
Paul: So it's kind of tricky because you don't wanna lead with it. So if you've been following along with this video series, you know that understanding the solution, understanding the end goal, understanding the customer's needs is really the most important part. When you start talking about the modules, they're just naturally more complex, and they start leading towards a very technical area, where each module does what. So I generally find it's not too helpful to lead with them. I mean, you don't have to hide that modules exist. Ignition's the platform, and that's fine, but really maybe a little bit later down in the process, after you've already kind of figured out what the solution should be, or what your potential options are. Another way to think about it is that the modules are really the tools you're gonna use to build a solution, and you don't really need to get too focused on what the tools are initially. And it's something you really kind of examine later once you understand what the problem is. So really to answer your question, I guess, you can lead a little, but I would definitely maybe kinda push it back towards ... maybe the middle or towards the end of that whole discussion or the series of discussions.

01:39
Shay: Definitely. So it sounds like you kind of get a sense of discovery, figure out what problem they're trying to solve, and then once we kind of have an understanding of how Ignition works, then we can look at ‘How do we actually solve that? What tools are we going to use to do that?’ So with that, how do we avoid that complexity in the initial conversation or conversations with customers? 

02:00
Paul: Again, try to focus on the solutions or the big picture that you're here kinda heading towards. And again, you really need to understand what the modules do before you can really identify them. So you're gonna need to have at least some solid understanding of at least how they work, you're gonna wanna be familiar enough. Those details about how they work and stuff don't necessarily have to come up in the initial talks, but you really wanna have them in the back of your head, just to be able to piece this whole project, or what that whole project or series of projects will ultimately end up becoming.

02:31
Lauren: So once we've had those initial conversations, how do you determine the best module for someone's needs? Are you looking to solve a specific problem? How do you consider that? 

02:40
Paul: Sure, so yeah, it's definitely best to maybe abstract away the individual modules and kinda focus more on general categories of solutions. Common ones would be device connectivity, data logging, visualization, reporting, alarming, and then enterprise solutions.

02:57
Lauren: Quite a few. Well, why don't we start with device connectivity? 

03:00
Paul: Sure. Now, fortunately this one is relatively simple. You need to understand basically: What hardware does the customer have? What are they trying to connect to? Also, what do they have currently? A lot of the times, either we're replacing a system, or they're just adding on to an existing system, so they might wanna try to keep all their hardware in a particular family of devices or vendors. So first of all, do they have an OPC server or some sort of MQTT solution already that exists? So if they already have those, and they wanna keep those, we can connect to those easily, and you don't really need any modules except for the MQTT side, you might need some. If you're going to be using our OPC server, then you'll need our drivers, right? So it kind of depends at that point. You may need to look at incorporating our OPC-UA module as well as our device drivers, or maybe you can skip them entirely and just use what's already there. It really kind of depends what the customer's comfortable with using. So you don't necessarily have to throw away everything they have, they might wanna keep it around.

04:03
Shay: For example, if someone has some Allen-Bradley devices that they're wanting to connect up to, they can use our OPC server and then our Allen-Bradley driver suite. And then they're not gonna need any third-party driver or anything like that. Whereas if they were using something like Kepware, then maybe they would wanna take advantage of a third-party drivers suite with other devices.

04:21
Paul: Correct, yeah.

04:23
Shay: So we've connected up to our devices with our drivers, and now we wanna log the data. What options do we have for that? 

04:29
Paul: So for data logging, you really do have two main options here, and this is definitely where it gets a bit trickier. So we'll talk about both options, so the Tag Historian Module, this is basically the ‘set it and forget it’ sort of solution. The whole module is really designed to kind of take care of the whole database maintenance aspect of it, which is fantastic, because you can just install the module, you can go to your tags, you can turn on history, and then you can just start trending. And that's really it. You don't really have to do a lot of other things. You can start building, you can start putting charts down on screens, and you're good to go, and really, indefinitely. And again, it'll manage all the tables in the database for you. It's fantastic if you're doing any sort of time-based or time series charting solutions. It also does a lot with the actual charting approach, so the actual retrieval of the data in addition to sort of handling the retrieval portion itself. It does a lot of interpolation of the data.

05:26
Paul: So, if you technically have like millions of records, and you're trying to like push those out to a chart on something, client or something like that elsewhere, you don't have to worry about performance because we're go ahead and we're basically giving you accurate representations of what those datas are without the millions of data points. It does a lot for you so you don't have to. It is definitely the most, again, simplistic approach. Conversely, it's not a very friendly format if you wanna try to modify or make changes later. So what I mean by that is, is that whole module will try to manage the database tables itself. It has very specific expectations on what it wants, and if you're looking to modify those, you can, but then you go in this territory of what I tell most folks that you really need to understand what those tables do, and that's not something we really expect most folks to know. You can learn it's there, you can see what they're doing, but it kinda goes above and beyond what most folks probably want to do at that point. So it's definitely the easier solution and it's great for trending.

06:26
Paul: So to kind of transition, and then talk about SQL Bridge. So this is a little bit more complicated to set up, but when I say complicated, I mean it's in between getting out of the bed in the morning and going to the grocery store to shop. It's not like super complicated, there's just a couple of extra steps you need to do, it's a little more transparent. The transaction groups you create from this module, they can record based on intervals of time, just like the Tag History system can do, but it doesn't do a whole lot of magic in the database. It doesn't have a bunch of tables, it's putting stuff up, it keeps everything centralized in one. It's also nice because it's actually living as a project resource. A lot of folks kinda like that, they like to have a dedicated history and data collection project, which the Tag History system kinda just does silently in the background. So there's something nice about having that kind of visual element, you can kinda monitor and do things with. But where these really shine, these transaction groups, is event-based logging, so Tag History is doing this time-based recording every number of seconds or whatever, generally speaking.

07:31
Paul: But transaction groups can go into event-based logging, so if you have some bit you're monitoring, and every time that goes high, and it goes at high at odd intervals or under certain cases, the transaction groups can natively record that. The Tag Historian system, if you wanted to do that, you need a script. Which is a little bit trickier to do, obviously. So it's kind of nice because it takes care of all that, it has a built-in interface. It's a lot more elegant with the whole representation of what's going on with a recording system, and then you can kinda customize it too. This is also ideal if you did want to have some database interactions. So you're not just like recording stuff. The idea with the transaction groups is, yeah, you can record stuff with them, but then you can also very easily pull them back under, those records, back under certain conditions, and so on. That was a lot. So, how do we boil this down to some key points? Just to kind of like help solidify this.

08:28
Paul: So if you're talking to the customer, and you're talking about these data logging solutions here, if you hear things like "time series," or "trending," "ad hoc charting," Tag Historian is much easier to use, it's definitely more the ideal module to use in those cases. You can use SQL Bridge for it, but there's a lot of extra work you gotta put in, so that's why I prefer that in that case. For SQL Bridge things you wanna listen for, "event-based," "triggers," anything that kind of invokes an idea of a particular action or event occurring, not necessarily on a set schedule, but then you're gonna wanna do something. So if you're recording for particular events, I wouldn't say alarms because that goes into another topic. Also, what's great about the transaction groups, there's a lot of folks that like to create their own like recipe management system for a lot of things. Transaction groups are really easy to do that. That's actually really common use for a lot of our customers.

09:22
Shay: We actually do have two posts on our blog about 12 different ways to use this SQL Bridge Module. So if people wanna check out even more ways they can leverage it, they can look there as well.

09:31
Paul: Absolutely.

09:32
Shay: Yeah. And then moving on, we've got our data, we're logging it, we might wanna build some screens next, what do we have in terms of visualization? 

09:40
Paul: So you really have two main options, again. So you have Vision and you have Perspective. Vision has all of these kind of common HMI aspects and features and functionality that you would expect to have. And any sort of visualization product Perspective. It's the newer one. It's got a lot of the same toys. It's definitely a more modern approach, it's using a lot more modern tech, even just looking at it, it's more of a sleeker, web-based kinda look and presentation. And it's a fantastic solution for trying to build any sort of project that requires any sort of responsive design. So you're gonna be looking out on a big screen, you're gonna be looking on your phone or smaller screen, something like that. We also have dedicated apps for Perspective, which a lot of folks have always been kind of clamoring for. Let's talk about the keywords real quick. Because again, there's definitely a lot of overlap. When talking, if you hear things like "desktop" or "HMI," maybe "Vision."

10:38 Paul: HMI's a little vague because, technically, that could still be a Perspective application. A big part of that, is whether or not, at this point in time, if the customer's interested in, or at least okay with having a browser on these workstations. 'Cause right now, the main way on a desktop to view a Perspective session is in the browser. And then of course if you're trying to view something on your phone, on a tablet, something, maybe a little smaller device, Perspective is fantastic. I mean it was really built for that whole solution. Now, something that a lot of folks maybe won't realize right away, is that you can't have both, you really can't. So it's possible to create that sort of desktop solution in Vision, but aside from Vision, you're creating tags, you're creating alarms, you're creating a lot of these other resources in the project that aren't really owned by Vision. Perspective can also use those. So, when you're building for one, technically you already have a good foundation to kinda add something into Perspective.

11:34
Shay: Definitely. And one really awesome feature with Ignition is the ability to do on-screen reporting. And with on-screen reporting, we can be using our awesome charting features, taking advantage of the modules that we spoke about for logging data and history. But what are their options if they would like a PDF report, or something that they're emailing out to someone? 

11:56
Paul: So it's funny, you hit a really kind of funny aspect of reporting. 'Cause the term reporting is incredibly overloaded. Lots of things are a report, right? So yeah, even something you made with one of our visualization modules, that could be a report. That could be a real-time report or however you wanna call it. So, yeah, the Reporting Module as you kinda said, it's really ideal if you need to make a document. If your end goal is, "I need a PDF," or something like that, "I need an email," "I need something that doesn't necessarily live in one of your visualization applications," it's something that could be sent out or saved elsewhere entirely. It also has some built-in scheduling capability. Which is great because if you're trying to shoe-horn that functionality into the visualization modules, that gets tricky, you're doing a lot of scripting, it's not always gonna be ideal. Whereas the Reporting has this really nice interface, and it's super simple to kinda get started with. So yeah, definitely again, key terms, things to look for, to kinda decide if you should be using a Reporting Module here, "schedule," "printing," "print the report," "write," something like that, or we're creating a document, PDF, like I said, "email," stuff like that. But if you wanna listen to those terms, that gives you a good idea of maybe Reporting is useful to you.

13:20
Lauren: Awesome. And then moving on to alarming, what do we have to offer?

13:24
Paul: Sure. Now, this one trips up a lot of folks. You gotta remember, alarming is part of the core platform that is Ignition. So if you just wanna alarm some things, you don't need to talk modules. If you're trying to record events that happen to your alarms, we have the alarm journal which is also part of the platform. None of that requires any module at that point. So when we start thinking about modules and identifying modules, we're starting to also discuss alarms notification. That you wanna focus on the Notification. Our alarming solutions modules are all designed to send out some message or something, some signal outside of the products that people can respond to it. So the main modules in this case would be ... they're a little bit easier because they're all based off of different delivery mechanisms. So you can send emails, we can actually call someone, so we can have a robot to do a little text-to-speech thing, tell someone what's going on and actually call them, we can send text messages with the SMS module, and then we have the Twilio module which also sends texts, but with the Twilio service here.

14:31
Paul: So big thing to keep in mind when you're talking to customers about these modules, these also require some sort of delivery mechanism, some hardware like a modem, or an SMTP server, or we need to sign up with Twilio or something, depending on which one of those you're using. So, key terms for these, "alarms," yeah, maybe. Really, again, if you just want something on screen, that's the visualization option. You already have the alarms available, and we have components. So "notifications," you wanna listen for notifications. Oh, maybe we should consider some of these modules. "Acknowledgements," "remote acknowledgements," if someone's trying to do mobile acknowledgement, or "alarm checking," or something like that. Then maybe the Alarm Notification Module would be appropriate.

15:19
Shay: So we've gotten to work with a lot of really large customers, and to help out with these big, really big installations, we have what's called the Enterprise Administration Module. Can you speak a little bit about its capabilities and when we should be offering that to customers? 

15:34
Paul: Yeah, so you have multiple Ignition installations. Maybe some of them have similar resources and that's intentional. You have some sort of maybe corporate standard, or your customer has some corporate standard of screens and visualization options that they want, and you're trying to make sure all of those different installations have them. That can be kind of a nightmare. If you're trying to make sure everything's up-to-date, that's a lot of work that you have to put into it. So the Enterprise Administration Module, we just call it EAM. So EAM helps you by getting the gateways to do some of the work for you. So the general idea behind this is that, when you're using EAM, there are two types of gateways. There's a controller, and there's only ever one, and then there's any number of agents. So the controller can basically ask agents to run tasks to do very specific things, which then the agents will do.

16:26
Paul: You can set these on a schedule, you can do it on demand, and those tasks help you in a lot of different cases. You can run upgrades, you can apply licenses, you can share those resources, I was talking about there. You can collect backups, you can even restore an agent. So if you had some hardware failure on a server somewhere, well, the controller keeps a copy of all the configuration items, so once you get a new server in place, you just tell the controller, "Hey, new agent's over here." And you basically go, and activating your backup and running again.

16:54
Lauren: So was that module required if I have multiple gateways within my installation or set up? 

17:00
Shay: Well, no, actually. So it's helpful for these maintenance tasks. It's definitely useful there. And when you start using it really depends on how comfortable you are with how many gateways you have at that point in time. You could start using it when you have just two, but maybe two is pretty manageable. So it might make sense for you to maybe look at this a little bit later, maybe five, maybe 10. It depends on how active you're developing on this, how many people are working on it, is it a good communication between folks? 'Cause at some point, you might have some breaking point, where it makes sense to have this module or multiple instances on each gateway. Now, it's important to know that you don't necessarily need this if you're doing any sort of data connectivity or sharing between these different gateways. We have remote tag providers part of the platform. So you don't necessarily need EAM to share data like that. There's a little bit of myth about that that folks run into, and you don't need it. Again, those maintenance tasks, that's what EAM is for.

18:04
Lauren: So when talking to customers, what are the key terms they should look for? 

18:07
Paul: So, yeah, key terms, "enterprise," usually comes up a lot when we start heading in the direction of needing or being interested in this module. "Multiple installations," "managing installs," "maintenance," "change of management," actually. If you're interested in having a development server, and then you wanna take the changes on the development server, and then push them over to production, this is also another kind of key term or key scenario you wanna be aware of.

18:34
Shay: And you can do that manually. So you don't necessarily require this module to be moving things from a dev server to a production server? 

18:41
Paul: Correct. Yeah, you don't need it, but it does help a lot when you get to the point where when that whole dev server, production server ... When you start having a whole bunch of dev servers, it's nice. But yeah, you definitely don't need it. You can still do that manually.

18:55
Lauren: But when we're having a discussion with a customer, how do we explain how these modules plug into the platform and how they actually work? 

19:02
Paul: Sure. So fortunately, that's a really easy topic to discuss. The key or the core modules that most folks are actually interested in, come with the installation of Ignition. So there's not really any extra work you need. In the few rare cases where there are modules that you do need to add in, it's very easy to just add them onto any existing installations. You don't have to restart your entire gateway, or server, or anything like that. They're easy to plug in and start using, and they all work on a trial, as I'm sure we're all familiar with at this point here. So it's really easy to get a new module, start playing around with it, even without a license or anything with it. Put together a proof of concept showing what it does and how that particular module's functionality or core feature set can help us reach the goal of the solution we're trying to reach.

19:50
Lauren: So with this, at what point do we start talking about expansion beyond the modules that they initially requested or were looking for for a part of their first solution that they built with Ignition? 

20:00
Paul: So really, it's an ongoing process. As you're talking to your customer, you've better understanding what solutions may work for them, you may find out that different modules may actually be appropriate even if you didn't hear the key terms. So again, that's just continuing to discover and talk to the customer, and understand what it is they're actually trying to do.

20:21
Lauren: So Paul, we went through a lot of different topics today, and I know our integrators and viewers will want to continue their education on this topic. Do we have any resources available? 

20:31
Shay: Absolutely. Paired with this video, you'll find a document containing all the terms you can use as a cheat sheet in your conversations with customers.

20:39
Lauren: Awesome.

20:40
Shay: Well, Paul, thanks so much for sitting down with us today. It was great getting to learn so much about the offerings that we have, and when we should be presenting them to customers.

20:48
Paul: My pleasure. It was great to be here.

Lauren and Shay are sitting down with Co-Director of Sales Engineering Kevin McClusky about how and why we take the high road when selling Ignition. Kevin explains why a big piece of our values is not comparing ourselves to the competition and not speaking poorly of competitors. Kevin shares how you take the high road when a customer is insisting on a comparison. We learn how to remain truthful and positive, stay in an educational mindset, direct the conversation, and focus on the solutions that Ignition provides

Video Transcript:

00:08
Lauren: Welcome back to our sales and marketing training series. I'm Lauren.

00:12
Shay: And I'm Shay. Today's video is on taking the high road.

00:14
Lauren: We're talking with co-director of sales engineering, Kevin McClusky, about how and why we take the high road in our sales strategy. Kevin, thanks for being here.

00:24
Kevin: Thank you for having me.

00:25
Shay: So, you're a musician. We got to hear a little bit of your music at ICC 2019. And I heard that you play three instruments. So, what are they? 

00:35
Kevin: That's true, yeah, yeah. So, I play keys. I've actually played piano since I was five.

00:40
Shay: Oh, wow.

00:40
Kevin: And then, I play bass, and I play enough drums that I kind of consider myself a drummer. I sing, too.

00:47
Shay: Yeah, oh, wow.

00:47
Lauren: You're a full band.

00:49
Shay: Yeah, seriously, you could do it all by yourself.

00:51
Kevin: Well, that's all you need, so you don't need anybody else, then. Right? 

00:55
Shay: Yeah, no, that's true. Very independent.

00:57
Kevin: No, no, obviously I put the Kevin and the Ignition 8 band together back at ICC. So, yeah, other people are important.

01:04
Shay: Kevin and the Ignition 8, Kevin and the Ignition 8? 

01:06
Kevin: Well, depends on who you talk to.

01:09
Shay: Yeah, that's true.

01:09
Kevin: Somebody said, Kent and the Ignition, and there's...

01:11
Shay: I don't know where they got that idea from.

01:15
Kevin: Yeah, I know, yeah. It's ridiculous.

01:15
Lauren: It's so weird.

01:16
Lauren: Hot-button issue.

01:18
Shay: Here's the real question: So, you're really into music, it's a really big pastime of yours. So, how does that relate to your other big pastime, which is your career here? You're a co-director of sales engineering.

01:29
Kevin: Yeah, yeah, it's a really interesting question, because most people don't think of crossover between music and other fields. But in my position here, and really ever since I've been part of any sort of engineering team, it's always been a creative process. So, I started out in the integration business, I was working at a small integrator called Calmetrics, which Steve also owned, our founder/CEO.

01:55
Lauren: Yeah, sounds familiar.

01:56
Kevin: Right [chuckle]. And so, every integration job that I've ever done, or anybody I've ever helped, folks, helped projects with for those folks, they've always been creative endeavors. And so, some of that creativity in the music space, just sitting there, improvising, creating new things. I was really into jazz for quite a while. And so, you just sit there and you create whatever it is that you want to create. You're sitting down, you don't have a script for what you're doing. Engineering work is similar to that as well. So, you come in, you take a look at it, you say, ‘Oh, this would be great if we put this here. If we played a few notes here like this, it's gonna make the customer delighted,’ right? And so, there's the creativity and being able to run and kinda roll with the punches and adjust as things go along, I think really does cross over quite a bit between the two.

02:51
Lauren: Well, on to a slightly different subject, this video that we're doing today is on the high road, that's something we talk about a fair amount at Inductive Automation. And a big piece of our values around that is not comparing ourselves to the competition, and really not even talking about the competition. Why do we do that? 

03:11
Kevin: There are many facets to the answer here, and I'll try to cover all of those over the next few minutes, as we're sitting here talking. One of those important things is that as a company, as a product, as folks who create Ignition for ourselves, we really strive to make a product that stands on its own. A product that is complete, the product that has a whole set of features that are going to be different from other folks. And so, we like to approach things as, ‘This is Ignition, this is all you really need to talk about. We don't really need to talk about other folks, we need to talk about what we're offering to folks.’

04:00
Shay: And what can be the downfall, then, of going that negative route and maybe focusing on competitors? 

04:05
Kevin: Sure, sure, yeah, that's a good question. So, I like to think of it, liken it kind of to a political campaign, right? So, if you've got political ads that are out there, and yeah, every election cycle, right, you see all these smear campaigns, you see all these things that political rivals are talking negatively about each other. And even in this industry, we see it from a lot of companies, where they're saying, ‘Our software is better than X, our hardware is better than X. And this is why, and this is why, and this is why. They don't do these things, they don't do these things. We do 'em better.’

04:35
Kevin: I know that everybody probably has a visceral reaction when you think about these smear campaigns from political rivals, because it's never a positive thing, you don't walk away from those feeling like, ‘This is someone you want to engage with.’ You say, ‘Okay, maybe I'll vote for the other guy because this guy is so bad.’ We don't want that from our customers, right? We want them to vote for us, and to vote with their money or decide that Ignition is the right solution for them based on its own merit. And we've done a lot of work with the feature set, we've done a lot of work with the company to make our company a company that's as useful and as engaging and as supportive as possible for our customers.

05:18
Kevin: So, we really want folks to use the best solution, and 90% to 95% to 99% of the time, when folks are looking for a solution that's inside this space, Ignition is going to be that best solution, right? So, having an honest message about what we have and leading with the things that Ignition is really good at, and talking about those things means we don't need to go into that negative space.

05:44
Lauren: I know we'll be talking about the four pillars in other videos, but this feels like it really falls under that ethical pillar as well.

05:51
Kevin: Yeah, absolutely, absolutely. So, we've got the four pillars, we are going to have that inside the other videos. And for folks who are watching at home, right, go ahead and click over to those other videos, you'll see that. But one of those pillars, that's really important for our company, is that ethical pillar. And that ethical pillar says, ‘We're not going to compete with integrators, we're going to try to do things that are the right way with folks. We are going to respect the relationships that we have, we're going to try to do our business in as ethical a way as possible,’ and that's certainly part of it, right? You don't talk negatively about folks, all you do is you present what you have in as positive a way as it can honestly be presented, right? And then, they're going to make their own decision, they're going to self-select into what's best for them. We really want people to be successful in the long run, that's the overall goal. It's like, bring the things, show them. And we're really in the education business, so we wanna educate folks.

07:02
Lauren: What do you mean by that? What do you mean we're in the education business? 

07:05
Kevin: We have a saying inside the sales engineering department, inside the sales department, inside the company overall as well, which is that the software sells itself. We're not here to convince folks to do something that they don't wanna do. We're here to show folks what Ignition does, how it does it, what features we've developed in the software, what our support structure is like, what our tech support looks like, what our Inductive University looks like; all these amazing things that we've created around Ignition. And let folks decide for themselves, is this what they need? Is this what they want? So, the idea is that education is going to bring folks around to help them to understand the feature set, understand how it lines up with their engineering needs. And then, they can decide, ‘Is this the best offer for me or not?’ And 90%, 95%, 99% of the time, they're going to go with Ignition, because we've put so many powerful features inside it, we have a price point that is amazing inside this industry. We have the unlimited licensing model. I could go on, right? 

08:17
Shay: Yeah, I'd agree. So, with all of these things considered, then we're talking about taking the high road application-wise or putting these things into practice, how do you do that? How do you take the high road? 

08:29
Kevin: Sure. So, I think the first thing for some folks, is to take a look at their own approach. So, I know that a number of folks who've come on with our organization, and with other organizations, too, might be in a mindset that, ‘You've gotta get out there and you've gotta sell, sell, sell.’ Right? That's not really the right mindset to be in. The right mindset to be in is, ‘Educate, educate, educate.’ Show people what the software can do, be honest about what it can do. If there are certain things that they're looking for that it doesn't do, be honest about that, as well. And talk about an overall solution, as Ignition is here, maybe there are some other pieces to it or maybe Ignition does everything.

09:11
Kevin: But talk about the solution space, talk about what Ignition is going to bring to the table. And if you're coming in from that positive mindset of, ‘I'm showing off something that is amazing, and I'm coming in with something…’ Because it's true, right? You don't have to fake that, right? If you're coming in from that perspective, you're not coming in from a perspective of, ‘I want to compare Ignition to this other thing. I wanna compare it to this. Ignition's better because this thing isn't as good as Ignition because Software X has this limitation and Ignition doesn't.’ You're instead, coming in from a perspective of, ‘Ignition has all these features and completely stands on its own. So, these are the things that are great about Ignition, this is the whole feature set.’ And then, customers can compare as much as they want to, to other things as well.

10:08
Kevin: It's also useful sometimes to talk about some of the big differentiating factors. So, if folks are asking about, ‘How does Ignition compare to Software X?’ You don't have to go into a negative space, right? But you can say, ‘Well, we're not experts on Software X,’ that's definitely true for Inductive Automation. We're not experts on all these other softwares, we can't really talk about exactly what they do. We've heard plenty of stories from integrators and other folks who've given us reports on certain things, but that doesn't make us experts. We just have some anecdotes here and there.

10:41
Kevin: So, it's not really our place to talk with authority about these other softwares, but we can say just in general terms, ‘Compared to the number of other things that are out there, these are the big differentiating factors with Ignition. We've got the unlimited licensing model, which is different than almost every other software out there. We're built on one platform, we have all these different modules that add to the functionality, we run as a single service, we're cross-platform, where we're running on Windows and Linux and Mac OS. We have full, true mobile-responsive options inside Ignition with the Perspective Module,’ and you could go on and on and on, right? 

11:18
Shay: Literally.

11:20
Kevin: I think there's a specific video that we're doing on this as well, where you'll be interviewing Vannessa.

11:27
Lauren: Yes, exactly.

11:27
Shay: Yes, talking about differentiating factors, yeah.

11:28
Kevin: Yeah, yeah. So, that'll probably go through a whole slew of these, right? But you can focus on those and you don't have to compare it to another specific software product. We do have a comparison sheet that sometimes we'll send out that says, ‘Here's Ignition, here's all the boxes that Ignition checks.’ And then, you, if you're comparing it, you can go ahead and fill out the boxes for Software X. Fill in the name, up at the top, and fill in the boxes there, and come to your own conclusions about that. Of course, we're highlighting the things in Ignition that are the biggest differentiating factors in Ignition. Most of the things that are going to be common across softwares are certainly still worth mentioning on a phone call, but they're not gonna be highlighted in that document. And we often also talk about the Inductive Automation organization. So, that can be a really big differentiating factor for folks, too.

12:22
Kevin: We mentioned the four pillars earlier. We're a company that, in my experience, is extremely different from just about every other company out there. I started with the company about 10 years ago. And at the time, it was a very small group of folks. We've grown like crazy since then. But as the director and as someone who's grown with the company during that time, and is in charge, along with Travis Cox, the other co-director of sales engineering, is in charge of the sales engineering department, one of my jobs and one of the things that I've taken very seriously, is attempting to keep that small company feel as we get larger, and attempting to keep the agileness, attempting to keep the ability to work with customers and delight customers and have those one-on-one relationships. And that's one of our values inside the company, the delighting of customers, right? 

13:18
Kevin: And so, as an organization, we have a lot of things that make us different than other folks. Sales engineering's talking directly to development on a regular basis, or (the) sales department is right next to other folks. We have direct lines from tech support to development, and we have a lot of interdepartmental communication that helps keep things smooth, helps folks get quick resolutions to different things, we have nightly builds for Ignition. There's just so much that makes us, as a company, a very different type of company to work with, versus a lot of the other folks that are out there. So, that's one that I like talking about as well, and also one that folks will find if they're comparing what their interactions might be with other companies, versus what ours is. We can't say exactly what their interactions with other companies might be, but we can tell them what we'll do, how we try to delight the customer, how we're very focused on trying to be responsive to what folks need, how a lot of our development is built on customer requests.

14:25
Lauren: Inevitably, when we're taking the high road, we most likely are going to eventually run into a customer who really wants to get into the nitty-gritty, and they say, ‘No, really?’ And they keep digging, and they want that comparison, and they want you to even speak poorly of a different company. How do you approach interactions like that? 

14:44
Kevin: That's a really good question. So, I've been in the conversation with folks many times, where they say, ‘No, we're using Software X, we're using Software Y.’ What we really need to do is compare Ignition over to this software. ‘Can you give me a line-by-line comparison, can you tell me what is better about Ignition than these things?’ And they're really looking for information where we're going to provide this, and we're going to say, ‘Ignition's better in this way, in this way, in this way.’ And they most likely are going to get that list from a competitor, right? So, if they're talking to the competitor, we've seen many lists over the years that the competitor has said, ‘This is what Ignition does, and this is what we do, and this is why we're better than Ignition.’

15:29
Kevin: So, they're not gonna get that list from us, and the reason is everything that we just said. But to your question, ‘What is your response?’ One thing that's important is to have a response ready. So, have something prepared as you're talking to a customer, and they say, ‘Hey, we really want to compare you to Software X.’ One of the things that's really important for us in that response, is that we're not an expert when it comes to that other software. So, I mentioned it earlier, but we're not an expert. We don't know Software X. We may have some training, we may have some engineers who've gone through, we may even have some folks on our design team who've done some implementations inside this other product, but that still doesn't make us an expert on this other product.

16:16
Kevin: We know a few things, but there could be new versions that have been released, there could be additional things that have been added to the platform since we worked with it, they may have changed their architecture, their infrastructure, or we may just have an understanding of the software that's completely wrong. So, our engineers worked with this one section of it and not the whole software platform, and maybe there are certain things over here that do things in a different way. So, it goes along with taking the high road, but it's important that we're completely honest with folks, right? And so, when we talk about these things, we might respond in a way that says, ‘We're not an expert with the software, we can't claim to be an expert with the software. If we claimed that, we would be doing a disservice to you, because we would be giving you a comparison chart that you don't really know is true,’ right. And we're not going to be dishonest in the way that we express ourselves in the response that we give to them.

17:14
Kevin: So, ‘We can't give you that, but what we can give you, is this comparison chart that I mentioned earlier. And we can give you information about the differentiating factors of what Ignition, how it generally compares to other softwares in this space, the things that generally are going to be winners on the Ignition side.’ And I mentioned some of those earlier, and you can watch the other interview that you're doing around the differentiating factors specifically, right? But we'll go through that, and we'll have a response there. And I think it's really important that when someone is answering that question, that that response is something that is easy to pull out, easy to talk about and easy to express to folks.

18:04
Kevin: And I'll just give you an example of why this is really important, is because, I mentioned earlier that a number of our competitors do this comparison, side-to-side. Every single one that we've ever seen is wrong. So, we have never seen one that is factually accurate about what Ignition can do. Some folks say, ‘It can't do this, it can't do this, it can't do this. We do these things better.’ And then, when those comparisons come back to us, it's very easy for us to go through and say, ‘This is wrong, this is wrong, this is inaccurate. This company is giving you bad information about this, because Ignition does do this, it does it this way, these are the modules that you use, this is how you do it.’ And immediately, the other company loses credibility because they've expressed something that is just wrong. And part of our ethical pillar, and part of our expression of our software, and part of our core values is being honest about all these things, and being able to talk about what Ignition does, what Ignition doesn't do, and letting folks make that decision. So, if we started giving out comparison charts, then we would be in the same boat as some of the folks who ... we want to stay differentiated, right? We wanna stay honest, we wanna stay ethical, as a company, and it's really important that we maintain those lines.

19:23
Lauren: So, Kevin, as a company, Inductive Automation has taken the high road since the beginning, and you've been there for much of that, you've seen how that's panned out for us. How would you say that that's panned out for us as a company? 

19:37
Kevin: Yeah, yeah, good question. So, we haven't always, full disclosure, been perfect about it, right? And so, there's some coaching that goes into the process when we bring new sales folks on board and new sales engineers. But overall, it's been really valuable for us as a company, and it's been a really cool thing to see. Because we don't have to trick people into things, we don't have to give people comparisons to other softwares that we think is probably right, but we're not 100% sure, we don't have to go the route of going into negative smear campaigns. We're able to be in the education business. Talk to folks about Ignition, talk to folks about Inductive Automation, talk about what an amazing thing it is that we're doing here and what an amazing company that we have and let 'em choose for themselves.

20:32
Kevin: And we've seen that rewarded over and over and over again, as folks start to understand where we're coming from, what we offer, who we are, how we're going to support them going into the future, and the organization that's really behind them as a customer when they purchase Ignition. So, it's been a really cool thing to see, it's been a really cool thing to be part of, and I'm looking forward to continuing being part of this far into the future.

21:00
Lauren: Well, excellent. So are we [chuckle].

21:01
Shay: Yeah, I was gonna say the same thing. Thanks so much for being here today.

21:04
Kevin: Absolutely. Yeah, thanks for having me.

21:08
Lauren: Thank you.

Lauren and Shay welcome back Senior Account Executive Vannessa Garcia about what separates Ignition and Inductive Automation from the competition. Vannessa shares her experience working with a competitor and selling Ignition today. She discusses the importance of educating customers who already have software systems in place, and understanding their needs. Vannessa talks about the pain points that come up over and over during conversations and ways to resolve those with the workability, time, and money solutions that Ignition provides. She also goes through IA’s software comparison chart.

Lauren and Shay are having a chat with Senior Sales Executive Jim Meisler about smart strategies for selling Ignition like a pro. Jim discusses asking the right questions, the value of honesty, and key things to keep in mind as you answer questions for managers, operators, IT, and more. Jim also shares good times for integrators to share Ignition as a solution and the importance of having the right mindset. We learn about educating customers on the unlimited nature and modularity of Ignition, getting buy-in from customers and ultimately getting Ignition into their hands.

Lauren and Shay have invited Director of Sales Melanie Hottman to discuss handling objections from customers when selling Ignition. Melanie says to view objections as an opportunity to connect with the customer, understand their frustrations, and ultimately find a solution for them. Melanie covers the common concerns that come up during a sales call including budget issues and timelines. Melanie shares ways to resolve technical concerns, get the customer motivated, and build trust. Hear her recommendations for customers requesting a proof of concept or real-world validation. Learn to do your homework on a customer, use your best judgement, and make them remember you.

Lauren and Shay welcome back Sales Engineering Manager Kent Melville to show us the power of launching the Ignition Designer, creating a new project, and showcasing the functionality of a unified design environment live to a customer during a sales presentation. Kent highlights templates, configuring a Perspective screen, the ease and speed of adding and editing tags, adding components, modifying screens, charting, alarming, the mobile-responsiveness, and provides tips for giving a flawless presentation.

Lauren and Shay welcome Sales Engineering Manager Kent Melville to show us the power of installing Ignition live to a customer during a sales presentation. Kent shares why doing a live install is so valuable, who we do them for, when it’s appropriate, and how long it should typically take. Kent demos database and device connections in the Ignition Gateway while providing best practices for overcoming problems during the install, important points to bring up during the demo, and launching the Ignition Designer.