In StoneTalk Episode 36, Patrick speaks with Scott Edwards and Marty Medina of Data Bridge Integrations.

Listen to this episode to discover:

• Some of the problems that JobTracker doesn’t solve that partners like Data Bridge do
• The types of customers who use Data Bridge’s tools
• What it’s like using the JobTracker API

Be sure to subscribe to the podcast in iTunes… and please let us know what you think! You can leave comments for this show on the StoneTalk Facebook page or on this site.

If you have stories or insights that you’d like to share with other fabricators, please reach out to Patrick.

Download mp3 directly

Transcript

Patrick: Welcome to StoneTalk, the podcast for countertop fabricators, brought to you by Moraware, makers of JobTracker scheduling software and CounterGo estimating software for countertop fabricators. I’m your host Patrick Foley. Today I’m speaking with Scott Edwards and Marty Medina from DataBridge Integrations, formerly VPN Systems. Let’s give him a call.

Scott: Hi, this is Scott.

Marty: Marty Medina here.

Patrick: All right, great success. Well, let’s jump in. Scott, Marty thanks for joining us. Tell us, just give us an overview of DataBridge. How did they come to be, what happened with the name change, what was that about?

Scott: Sure. Well, Patrick, when we were the VPN Company and as VPN, we were a larger systems integrators specialized in wireless mobility and barcode data collections for an employ management. And we did that across a variety of industries, we are much broader focused. And as we started to work with Moraware and the countertop fabrication industry, we gained some real good market acceptance and we saw that there was truly a need in that area for what we were doing. And at that point, we felt it was important to really focus our resources there.

We worked with the industry to understand that we are serious about this business and that we are in it for the long haul. So we created DataBridge and we had subsequently focused all of our attention and resources on Moraware and the countertop fabrications industry.

Patrick: Nice, so it was to paraphrase your…it was a decision to focus very specifically on this industry, instead of across multiple industries. Now you’re focused on Countertop’s and coincidentally typically building on top of JobTracker as well.

Scott: That’s correct.

Patrick: Well, first of all let me just say thank you for that because I love the people in this industry and we have a lot of customers. A lot of people who ask for functionality that makes a lot of sense and that’s needed but we can’t build everything on our own. It’s very helpful that other people in the industry are doing things and filling in the gaps, where we can’t do something. Thank you for that.

Scott: You’re welcome. We feel that it’s a real value we add for both the customers and hopefully for Moraware as well.

Patrick: Let’s talk more about your customers. Is it typically just large customers or do you have customers of all sizes in this industry?

Scott: We have a variety of customers from fairly small fabricators, to some of the largest in the nation. What’s common among them is their desire to do more with less people, to improve business processes and to reduce cycle pan.

Patrick: And again, my introduction to your company was probably around inventory. I’ve recommended people to you multiple times, particularly when they have questions about things like labels and printers. We don’t have the in the field experience that you have with label printing, label scanners, all those kinds of details. So one of the first things that I was aware of was your system that went on top of…that built on our inventory and added a few things. Let’s dive into that. Why don’t you tell me about the Moraware Inventory Reconciliation System. I believe you shorten that to MIRS, right?

Scott: MIRS, that’s correct, Patrick. And first I’d like to thank you for those referrals. We really appreciate those. MIRS is a product that we first built, we had a customer search for this in New York and more customer come to us quite a while back and say, “The Moraware Inventory system is great but we have a challenge in keeping it accurate enough today. Manual physical inventory is a laborious process, takes people and a lot of time. When we get done it’s not very accurate anyway. Can you help us? We know you know quite a bit about inventory management and bar coding.”

And again Marty, developed the first version of MIRS for this customer and that was when we really saw value in what we were doing because this customer went from taking several people, two, three, four days to get through the shop doing the manual physical inventory down to less than a day because they were able to go out and scan the barcodes, in which each location barcodes will need to describe amendments. And very quickly now, we did a physical inventory but because of the immigration that we created with JobTracker, we are not able to see inventory discrepancies. Missing slab’s, slab’s that have been allocated to jobs that weren’t used, when other slab’s was used, and ways that they could help them really improve the overall accuracy, of the JobTracker inventory module.

Patrick: And did you ever consider…has anyone asked about building an inventory system like this outside of JobTracker? The reason I ask is once in a while we get a potential customer who calls where their main concern is inventory. “Well, our inventory system is built on top of our scheduling system and if you don’t have a scheduling problem it’s not going to be worth using our software just for an inventory problem.” Have you ever had anyone ask you about building just an inventory system that was completely separate from Moraware and have you considered that? Is a just not enough interest, yet?

Scott: Well, at least…

[crosstalk]

Patrick: Sure, go Marty.

Marty: Sure, I just wanna mention before we continue with your question, talking about MIRS and the efficiency just to give you an idea of a number, we have one client who successfully reconciles their inventory 6,000 products… 6,000 serial numbers and suppose they do in a matter of eight hours across two locations.

Patrick: Wow. That’s not bad.

Marty: Probably one of our heaviest users. That’s why I wanna fill that before you talk about the inventory.

Patrick: How often do they do that because that’s one of the little variation pieces there. Some people never reconcile, which is probably an issue over time. Some people maybe once a quarter, once a month, once a week. Do you happen to know how often they do that reconciliation and what do you typically recommend as the best interval for doing a reconciliation?

Marty: They reconcile every week and plus on the month end, whenever the month ends. As far as frequency, Scott, from your experience with inventory what would you think is the adequate frequency?

Scott: Many of our customers are doing it monthly. Some of them weren’t doing any kind of physical inventories before they started with us and realized that they could do it more frequently. Like, “I wasn’t doing it at all, I have to do something.” Others were doing it quarterly, bi-annually or annually and because of the efficiency of being able to scan and make it very quick and neatly, now they’re able to reconcile on a monthly basis without a great deal of overhead.

Patrick: Cool and changing the locations, I assume really helps as well because my understanding is if I scan it…when I scan, I kind of know I’m scanning for rack A. If the serial number was found but the system Moraware thinks it’s in rack C, you’re gonna change that to rack A, right?

Scott: That’s correct. We will change the location. It will come.

Patrick: And we’ll come back to my question in a second but actually let’s go in the other direction with inventory requiring more software. We also sometimes get questions about Slabsmith. And Slabsmith is a very important piece of software in our industry. Solves a very different problem, also has inventory as part of its software but cares about inventory and in a fairly different way from the way we think about it. Our inventory is all about helping you order and receive the inventory and answer the question which slabs go with which jobs. Slabsmith has more of a visual view of inventory.

It has other aspects as well but it’s very important to Slabsmith that you have pictures of each slab in your inventory, so you can lay it out in Slabsmith. So they have a little bit more detail and remnants there, that virtual remnant concept etc. Before you even can cut it you can know that a remnant is gonna be coming. We used to have customers ask about integrating our inventory with their inventory and the last time we spoke, I know that you were just coming out with this integration.

Well, now it’s been in the market for a while. What can you tell me about the JobTracker Slabsmith integration and how that’s been going? What kind of results that’s had for customers?

Scott: Sure Patrick, that’s called a JSIP product JobTracker Slabsmith integration platform. And we now have about a half dozen customers installed with Slabsmith integration platform. And the way that works is it uses JobTracker predominantly as the master, and Slabsmith is slave. In other words JobTracker is still aware…

Patrick: Let me step back a little bit. That’s computer science term. Standard computer science term, master-slave relationship. Little bit offensive, if you think about it but just so people know, that is a standard computer science term that one is the master and one is the slave in this relationship. Continue.

Scott: Use whatever term you want, still JobTracker is the boss. But the point being that their POs are going to be created in JobTracker and that’s where the inventory is ordered and when it comes in it’s gonna be labeled from JobTracker the way it is today, it require it’s serial numbers for each slab from JobTracker. Now what happens then is our integration runs as frequently as necessary, could be every 10 or 15 minutes. While I’m here, let’s listen to JobTracker database. And it says, “What serial number exists in JobTracker that don’t exist in Slabsmith currently?” And it then moves those serial numbers into Slabsmith along with all of the pertinent data that Slabsmith needs.

So what that does eliminate all the redundant data entry that’s required by Slabsmith. When the slab is now taken to the photo booth for Slabsmith, the serial number is already existing in Slabsmith along with all of its data. They take your photograph, they can do their layout design and they can create a virtual remnant. When the integration runs again, we can then also take the remnants that have been created in Slabsmith and move them back into JobTracker and still maintain the parent-child or the chain of custody relationship between the remnants and the original slab.

That eliminates the additional step of having to go back into JobTracker and you create new remnant, you create a new serial number. Additionally, we put some of the other things such as, once we know that Slabsmith has consumed that slab in their system that will automatically set the flag to completed fabrication, equals complete JobTracker. What we try to do is really streamline that whole process between JobTracker and Slabsmith and eliminate all additional data entry and then now that those serial numbers for remnants are back into JobTracker from Slabsmith and that second step has been eliminated.

Because they have serial numbers that are in JobTracker, we can now monitor and track them with the nearest bar coding product. And we can know exactly where that slab is, what location is it existing, where it’s to move to etc.

Patrick: Very nice and so a big goal of both of these is avoiding double entry that you’d have to do or at least dig all off. The Slabsmith integration is avoiding double entry and then with MIRS, you’re just reducing the manual effort of reconciliation as well.

Scott: That’s correct.

Patrick: How many of those half dozen JSIP customers are also using MIRS?

Scott: Most of them actually. I think we only have maybe one customer that’s not using MIRS integration to JSIP.

Patrick: Nice. Let’s move on to JMAIL. What is JMAIL about?

Scott: JMAIL in an automated email system that allows customers to create, if you will, automated form letters. Emails that are basically form letters that are customized and personalized with the customer’s detail. And these emails are sent out automatically based on certain activities or status changes or that’s within JobTracker. For instance, some of the key email templates that our customers are sending out automatically would include new order acknowledgement.

New orders created in JobTracker and seeing that new order is created, an email goes out to that customer saying, “You Mr. Foley, thank you for your order. Or you’ve ordered inventory of a black two centimeter for your kitchen, we appreciate your business.” And it’s much like your acknowledgment like e-custom change when you order something from amazon.com. And another trigger would be a key firm template date for instance. Once the customer service individual has confirmed the template date with the customer and they put that date in the field in JobTracker that automatically sends out an mail saying, “Mr. Foley we’ve scheduled your template measure date for the 17th, your window of arrival will be from 2 to 4 PM. Please see the attachment for instructions on being ready for our people to measure your countertop.”

And another would be for an install date. Another is often a post installation, invoice customer email. Some of our customer have even or added the surveys for those post install email saying, “Please fill out our customer satisfaction survey.” We can trigger an email based on any status change or activity within JobTracker. Those emails can be all outward-bound to customers but sometimes there also internal emails. They might go to job scheduler or a planner. You’d say, “Hey this are the new jobs, you’ve been answered today.”

There’s a lot we can do there but definitely that’s what it’s about. It’s about creating customized but automated emails and that reduces all the additional data entry that customer service person would have to do.

Patrick: Now, I’ve spoken with more than one customer who wants this functionality but would prefer it to be text messages instead of email. Have any of your existing customers asked for text messages and is that on your roadmap? Is that something you plan to look at in the future.

Scott: Yes and yes. We have had a number of customers ask us about text messaging. That hasn’t prevented them from going forward with the email system and we are looking at that and we’re hoping that in the first quarter of 2017 to be able to provide that functionality.

Patrick: Excellent. Are you looking at a service like Twilio to handle the actual text messaging?

Scott: Marty?

Marty: Yes, yes, we are. The challenge right now that we are trying to figure out is to have the data in JobTracker. Kind of people put phone numbers but they don’t indicate if they’re cell numbers or if they are land lines. We need to figure out a good way for that information to be easily entered by the data entry people.

Patrick: Interesting you could give automated calls or those are more cheesy and less handy than text. There is a place in a Moraware contacts. We don’t have much flexibility there but they…If people were willing to be crisp about what kind of phone number it is. If they put it in Mobile you could do a text and if it weren’t there you could do phone or you could even be more brute force about it and require for your purposes, “Enter the text number. Enter the number that you want to receive text.” It’s very clear to customers, “Hey here’s gonna be where you get the text when it happens.”

Marty: Okay, very good. Thank you.

Patrick: Just a thought. We’ll talk more about the API in a little bit because in API for anyone listening who hasn’t heard that term before it stands for application programming interface. It is a way that one piece of software like Moraware exposes a mechanism to other programmers like Marty at DataBridge to be able to interact with it. So we have an API, it is powerful in some ways but it’s very limited in other ways. And so I know, I’ve done a little sample of something similar to the goal of what JMAIL does and it is not easy.

We don’t give you a lot of the things you need to do what you’re trying to do with JMAIL. So Kudos to you two for avoiding the pitfalls of our API and focusing on what the customer is trying to accomplish and get it done because that is not any easy.

Scott: Well thanks, Patrick.

Marty: Thank you. Thank you for that.

Patrick: I sometimes describe it as programming with mittens on that you can’t really…you’re programming but it just doesn’t feel like you’re really have the access to the keyboard that you really want. Okay one last piece of software of yours that I want to talk about is the JTIconX. The tool for integrating with Home Depot again that was…I know that was something we pursued internally at one point in time and there was just too much variability. It just wasn’t something that seemed reasonable for us to be working on ourselves.

And we kind of throw up our hands and say, “This isn’t a good fit for us.” You plowed through and made a solution there. Can you give me an overview of that integration? Who’s it for? Who uses it, that sort of thing?

Scott: Sure. Well first kudos to my partner Marty for having figured that out because it wasn’t a challenge at first. The way Home Depot works is they will pick regional service providers that for sure are on countertop or else they come to the Home Depot. And so the Home Depot traditionally will send out paper or PDF copies of purchase orders or change orders and the Countertop Fabricators that serve Home Depot have the staff or the data entry people, in some cases as many as four in one of our customers case is.

And those people spend all day answering new orders and then contacting customers to set up install dates and template dates and what have you. And then turn around and manually enter that data about the template, date installed, date material allocated back into the Home Depot system. Home Depot also has an electronic version of that and the way our integration works is we’ve mapped the fields from the electronic system that are required to set up a new order or changes from an existing order.

And Marty’s integration will go into JobTracker, like you said, either create a new order or change the order based on what’s coming from Home Depot and that eliminates all of that up-front data entry. And then when customer service person contacts the customer and schedules a template date or install date instead of having to manually go back in the Home Depot system and enter that information our integration will pick up that data from JobTracker and send it back into the Home Depot IconX electronic system.

We’ve been able to really eliminate a lot of data entry for customers. One customer told us that they took two full time people out of the mix and were able to put them on higher valued tasks such as contacting customers about installs and measured dates and making sure that the more substantial tasks are getting done rather than just that data entry.

Patrick: That’s nice.

Marty: And Scott and I’d like to add something in. One of our clients who’s using IconX also uses JMAIL. What happens is fully automated is the order will be taken up on people, it will then go into JobTracker and then JMAIL…and it will become a job on JobTracker then JMAIL picks it up and sends a thank you letter email to the person who made the purchase. All Way from Home Depot to JobTracker and there is an email out saying, “Thank you for your purchase.” Fully automated.

Patrick: That’s just great, and obviously that’s the way it should be. It’s just people don’t understand how we put up these little obstacles between systems all the time that make it really hard to bridge systems like these. Ten, twenty years from now we’ll look back and say, “Remember when we had to do this in order to automate that little part of the program?” Hopefully we’re not still doing it exactly the same way but you never know but it’s just really hard for disparate systems like that to speak to each other. Again that’s great that you got over the obstacles there.

Scott: Well, thanks Patrick and it’s true that the integration between systems provide a lot of business value. It really does streamline workflows. It really does eliminate a lot of data entry and countless person hours of redundant data entry. We think that that’s very positive and valuable and I can tell you to your original statement about some of the challenges involved that with each customer on the front end we have to spend quality little time with them…working with them fully IconX integration.

Because everyone uses JobTracker slightly differently. We may have custom forms, custom fields and in certain ways in which they’ve at least figured JobTracker will work. So on the front end of these engagements, we spend a good bit of time with the customer up front understanding how they’ve setup JobTracker. What custom forms or fields they may have created and how they want the process to work. There is a bit of listening on the front end. What’s really transferable from one customer to another is our know how of how to get the job done and how to do it in your API and some of the code.

But the rest is really specific and tailored to each customer’s requirements and how they want that work, full process to work. I think that’s one of our value add-inns. Well, that we’re not asking people to take a product that we have and make it work in their environment as is. We typically are tailoring each of our products, except for MIRS, we’re tailoring each of the products to really fit the customer the way they need it to work for them.

Patrick: That’s actually a very different business model from ours, which as I said why some of these things don’t work are our flagship product JobTracker has as one of its primary characteristics that’s so flexible, that it’s very difficult to go past those little points of flexibility because everyone system is completely different. You have to have a different business model that involves some of that customization. Now what about if I…let’s say I was a customer who had something that I want to accomplish with JobTracker and some other system that JobTracker I wanted to integrate with. Would you do custom work or do you only wanna work on things that are…might result in a product or that explicitly result in a product?

Scott: We do custom work Patrick. We’ve done several custom jobs and we’re very open to that. What’s different when we’re able to productize the integrations is that we’re able to make them more affordable to everyone else. Because now we’ve got something that’s built out, that is fully proven, the heavy lifting up front has been done. Yes, absolutely we do custom work. We will entertain any custom work that someone might require. We’ve been asked to and we have quoted and done some other custom systems that include integrations with other electronic or systems, hospitals have one called Center.

And we have done modifications to our products that are outside of what we would normally do because that doesn’t have a broad appeal to the rest of the community. We by all means we will do custom work for customers.

Patrick: If I came to you with an idea that seemed relevant for other fabricators then you would come back and say, “Hey why don’t…instead of paying all the costs and taking all the risk for this why don’t we productize it and you be my first customer.” Is that the approach you would take?

Scott: That is the approach we take in that. What that does is that it gives our first set of customers the benefit of not having to pay what a full custom product would be because we plan to share that across the community. And so, yeah, we do work to productize those custom jobs that we do where we believe there’s broader appeal in the industry.

Patrick: Great. So any new things on the horizon that you can or can’t tell us about or is it just so far you’ve got these four products and you’ll take other opportunities as they come?

Scott: Well, I think it’s that but we are looking at…we are evaluating and looking at a couple of things. One of the questions we get quite frequently is, “Do you integrate with financial packages? Moraware doesn’t have integrated financials. Can you integrate Moraware with financials?” And we’re looking at that we’re working towards that. There are some limitations of the APIs in terms of its lack of no time capability that make it a little more challenging and…but we are seriously looking at that possibility of integrating with financials.

We’re hoping that some customers come to us and say, “Hey we really like to do it.” And we can approach it the way we have our other products. The other thing that has come up fairly recently is the idea of automating the reporting from the synchronous flow process. Those customers using synchronous flow manufacturing have a fair amount of manual data entry they need to do to populate their reports. We’ve talked to Ed Hill at Synchronous Solutions a bit. Initial discussions about how we might add value to that process by automating some of that reporting. But we’re not there with that yet, we’re just looking at that.

Patrick: That would be great. I’m a big fan of Synchronous Flow and Throughput Accounting as well. I definitely hope to see more there. Well let’s talk about the API a little bit and some of its limitations. I think in both of the cases you just mentioned integrating with financial systems and automating some of the synchronous flow aspects you come across one of the main limitations which is there’s no way to see coding information with the API. It just hasn’t got there yet. Simple as that. Obviously, is something we hope to add at some point in the future but we have limited resources ourselves and there’s other more important projects in front of it.

I hope to get there someday but that is the big kicker is that right now. You just can’t get at that financial information without doing something really brutal and hawkish to get at it.

Scott: Right.

Patrick: What other things would you like to see in the APIs? And Marty let me ask you since I do know the real time aspects are something. I have an opinion of one way we could implement that. But you as one of our biggest consumers of the API how would you…what broad… broadly speaking what functions would you want to see to implement real-time aspects of the API if you could have it? Wave your magic wand, what would it look like?

Marty: Well, first let me say that what the API does really well is putting information into JobTracker. We can put remnants and then tie into their parents, we can create jobs and they get template and populate forms on the jobs. Add API put information into JobTracker really well. Getting information out of JobTracker to the API, it’s bit more challenging. As far as like a real time scenario, I guess it wouldn’t be real time but when we go to JobTracker to get information using API it would be really convenient to be able to just say, “Give me every active job and these are field that I want from the job.

Or, “Give me every install activity and its status.” Right now those are challenges because you have to pick an account and then look jobs belong to that account and within that job where the activities. If something like that was available then the real time could be accomplished on our end because we can just get that information every five minutes…

Patrick: It’s a real enough time whereas it’s right now…

Marty: Real enough time, yes.

Patrick: Right now you can only get to a job if you already know what job you want to get to. In effect that’s more of a batch process where you have to loop through all the accounts and ask each account, “What are all your jobs?” Go through all those jobs, find out if they have any activities that haven’t been done etc It’s awful. I agree. And so the way I always think about it and it’s interesting that you didn’t even need to go as far as that I always want to ask, “Give me everything that’s changed since the last time I asked you what has changed.”

Tell me if you’re pulling it every five minutes it would be nice to say, “Tell me what happened in the last five minutes.” And just give you here, even if it were just, here are the jobs that have been touched in the last five minutes.” Then you could know that you have to do something with those.

Marty: Yes that would be that would be fantastic. And I know that you track that because every piece of information has a wonderful log of events behind it. Daytimes, chances things have happened and that would be a great option.

Patrick: That would be one possible mechanism is to expose the change log itself and then you could say instead of even…then you could say, “Just read me the change log for the last five minutes.” Record the timestamp and then five minutes later, “Read me the change log for last five minutes again.” In that way you know what changed but you could use whatever interval you wanted and you could just decide to do something or ignore each individual change log message.

Maybe you could even say, “Give me only job messages on the change log.” There’s a little issue that gets…starts getting a little difficult because of like the depth of an object doesn’t…When we put something in the change log that foreign activity. Do we also identify the job in the user interface if we expose that as an API. I think there’s something there but it’s not as simple as it sounds once you start digging into it.

Marty: Definitely, I think we are on the same page as to what needs…which needs to be most beneficial.

Patrick: It almost sounds like what you are asking though, “Just give me the active jobs.” You’ll notice in the accounts you can say, “Give me all the accounts for a specific view?” You can’t do that in the jobs if you could have a view of the jobs and say, “Give me this job view.” That would give you what you’re talking about. So maybe that too. I wish we had that magic wand. Anything else? What else? What other things. Obviously, there’s quotes. There’s those few little places in the inventory where…where you have to do that ridiculous amount of work to get what seems like a simple answer from the UI. I know about…What other things in the API? Anything else I wish was better?

Scott: Nothing else comes to mind. We become very familiar with it. It’s working well for us.

Patrick: That’s great, that’s great. Again, you’re probably the number one consumer in terms of…Other than myself, making examples for people. You’re probably the number one people to do things there. The general concept there is partnership. One of the things that has changed since I started working for Moraware about three years ago…three years ago we reasonably asked the question, “Well, why should we put in the energy into the API? Nobody is using it.”

At the time that was true. Hardly anybody had even touched it and then a couple people started to. And then you guys started doing some things and then you started building a company around this etc and at some point we had to acknowledge, “Wow, we have some concept of an ecosystem of companies like DataBridge whose success depends on the success of our company.” And all of a sudden we have Moraware.com/partners, where you’re a partner there.

And we’ve built this little kind of set of partner relationships that just sprang out of nowhere. So in addition to the API there’s…which is obviously, is very technical, there’s the idea of working with us as partners. And right now, there’s no formal relationship other than putting you on that partner page and interviewing you once in a while. What other things do you need from us to succeed from a business perspective. What other things should we do…not necessarily just for DataBridge but with the idea of supporting an ecosystem of partners for this industry. Is there anything else that we could be doing there?

Marty: Well, Scott can answer a better business it let me just…as long as on the topic, something very critical is that we would like to know any time that you’re going to deploy any changes? And as long as we have enough lead time we should be good. So that’s some technical. As far as business partnerships…

Patrick: I can answer that one right away. It’s we’re deploying something almost every day. So yeah we make changes almost every day and so we try hard not to change assumptions and certainly that’s where the difference between the API being officially supported versus once in a while we know that you have to do a brutal hack where you’re scraping the webpage to get information because the API just doesn’t support it. That isn’t officially supported but if you do it we don’t want to just randomly break things.

We don’t want to change things that can cause problems for you but at the same time there’s…Let me draw a bright line there. Anything on the API, if you find something that worked yesterday and didn’t work today that’s broken and we treat that as a bug and we tend to respond to those kinds of bugs the same day. For the other stuff, where if we just…if we changed our HTML on the page in an innocuous way, like you and I have seen an extra space that doesn’t make any difference in the user interface but it could mess up the way you’re parsing it, that we can’t treat as a bug and we in…Unfortunately as you’re asking me, “What else can we do for you.”

I’m saying “That one we can’t communicate effectively. Anything those nonsupportive changes in the UI because that would just… that would slow us down so much.” I mean even in support I don’t see those kinds of changes. They just happen.

Marty: So far we haven’t been affected natively by those kinds of things. I think that we are in a good shape from that perspective.

Patrick: What I will tell you is that we are working on some things that are going to make an impact at some point where…we’re not going to flip the switch and have people say, “Oh! My goodness what is this?” Namely we’re working on…our biggest project right now and some of it has been biggest project for the last year is updating things and making some new things to work better on mobile devices, phone and tablet. Big project, we’re nowhere near being able to show anybody including you but we have talked internally.

We do know that those kinds of things would greatly impact you. It’s not just an extra space in HTML, it would be different HTML and when we get to the point where we can show that to any customers…any beta customers, I’ll make sure that we’ve already discussed internally that we want to make sure any of our partners get a look at that and understand the implications. Because yes, that would just flat break what you’re doing. If we know something is gonna break what you’re doing we will let you know.

Scott: That’s great, Patrick thank you. And you know to just get some commentary on your question about partnership I’d like that we are very grateful the way you’ve embraced us as a partner and the referrals you made on our behalf and what you put on your website and I do believe having been in the industry for a long time in the software development and technology industry for a long time that the ecosystem that you build around your software add to great deal of value to your customer base.

What we hope to do is not only provide a return on investment for the products that we’re offering, the software extensions we are offering to customers but we believe that it actually extends the return on investment Moraware is for. Because we’re able to get more out of your software, more out of Slabsmith. The goal is really to do that in a thoughtful way where they are getting a return on investment not only from what we’re providing but from Moraware. And so those partnerships, those that ecosystem, really add to great deal of value to customer base, I believe in, which you will be part of it.

Patrick: Thank you and it reminded me of my old boss, Larry Gregory, at Microsoft. I used to work for Microsoft and I was actually in a partner program, I worked with partners. And Larry used to have the expression, the puffer fish effect, that puffer fish blow themselves up to appear bigger than they are instead when you’re working effectively with partners all your products have the puffer fish effect where you appear bigger than you are to the customer. You appear more effective to the customer than you would be without partnering.

I was just liked the expression puffer fish effect and the Slabsmith one is a great example where…I remember speaking to customers where this was the most important thing in their business was making this work better and the nature of our business…our business model is very much doing the best we can that’s gonna impact the most people. We have about 1,200 customers. We’re trying to do things that will impact as many of those 1,200 customers as possible.

And it is a relatively small number of people compared to 1,200 for whom Slabsmith integrating with Moraware is important but for those people it is super important. When you build that integration you solve the problem. And now when people ask us about that I don’t have to apologize and say, “Well, hey not only do we not have that I don’t see us being able to do that any time soon.” I can just point to you and say, “Yep the solution to that is right over there. Give Scott a call he will hook you up.”

That gives me the puffer fish effect which makes…it makes my day better. I don’t like saying no to people. I don’t like saying, “Rats, we don’t have a solution for that, maybe someday.” Which is the true answer many times? When you build something that we didn’t or can’t again it makes my life better because I’m able to tell a customer, “Yes.” Instead of, “No.” Nobody likes to tell a customer “No.”

Scott: Yes, so that is the point and we do see there is a need and still a very sizeable market to be served and we wanted the community know the we started DataBridge with very laser-focused on the current crop industry. We know that it’s a very tight community and we want them to know we’re serious and rearing to go the long haul.

Patrick: That’s great. It amazes me that an industry where my peers in software are surprised at what a niche it is. It’s amazing that there’s so many different parts of it. There’s us, there’s Slabsmith, there’s the software from the Sawmakers, there’s the Templating People, Laser Products and others. There’s you guys, there’s competitors to you guys. There’s so many different companies solving problems in the industry. It’s not a big enough industry that we can respond to things overnight but as long as people are telling us their needs and telling us what business problems they are having over time, we’ll get them all solved across all of us somehow and I’m encouraged by that.

All right, any other parting thoughts?

Scott: Just that we wanna say again Patrick, thank you very much. We really appreciate the opportunity to podcast and the partnership that we developed with Moraware.

Patrick: And I’ll have one little parting shot as well. If you’re listening to this podcast and you’re shaking your head wondering, “Why haven’t you guys built this.” Send us an email. To send an email to support@moraware.com saying, “You know what I would really like…” If it’s a feature that seems like it should belong in our software we’ll add it to the wish list. Maybe it’ll get built someday. If it’s something that seems like it should be built by a partner, I’ll send it down to Marty and the folks and if enough people want the same thing it’ll probably get solved.

Marty: Absolutely.

Patrick: Awesome. Thanks Marty, thanks Scott.

Scott: Thank you.

Marty: Thank you Patrick.

Patrick: Thanks for listening to StoneTalk. The podcast for countertop fabricators. If you liked this episode be sure to visit stonetalk.org or subscribe to StoneTalk at iTunes for more. Visit the StoneTalk show Facebook page to join in the conversation and follow @stonetalkshowtalk on Twitter. StoneTalk is brought to you by Moraware, makers of JobTracker scheduling software and CounterGo estimating software for countertop fabricators. I’m your host Patrick Foley and I look forward to spending time with you again on the next episode of StoneTalk.