What if I told you Zendesk can do more than even Zendesk thinks it can? That’s Cory LaPlante’s view. He’s been running LaPlante Management since the start of the pandemic and proving to companies everywhere that Zendesk isn’t just an app, it’s an engine. Clients frequently come to him saying, “Zendesk help articles told me this wasn’t possible” and he always replies, “Let’s see.” Often, he finds a way. Now, Zendesk sends him most of his business. 

I asked Cory about the founding insight that led him to launch his consultancy, and if he’d share a few stories of when thinking outside the lines helped him and his clients do things nobody thought was possible—including Zendesk’s own support team.

The following interview has been lightly edited for brevity.

Yoni Argaman: How’d you get into this business? 

Cory LaPlante: I was an accountant my whole life before becoming a Zendesk consultant. The month Covid-19 hit, my boss at the CPA firm said, “Cory, you have six more months and during that time, I’d like you to train your replacement in the Philippines. We’d then like you to transition to being a Zendesk consultant contractor and we’ll be your first client.” 

My reaction was, “I don’t know if I’m real happy with you right now. Can we go back to the part where I don’t have a job in six months?” But in the end, it was the best thing they could have ever done for me. 

These were two of my very good friends—my boss and the guy who ran the firm. We’d started a small side company together, the three of us, helping CPA firms adopt more technology with Zendesk as the core offering. I had taken on doing more and more of the technology aspect, asking, “Can we connect different softwares together to make this even better?” They were asking me to switch to running that firm full time.

Within a few weeks of that conversation, I had my second client. Then another. And then I started getting U.S.-based clients and thought, “Okay, there’s something here.” 

‍

‍

Why was the Zendesk work interesting? 

I love to solve problems and from day one, we had people coming in saying, “We want to do this thing but Zendesk says it’s impossible.” And I’d say, “Let’s try. Let’s see what we can figure out.” I am not a developer and didn’t have any prior computer science experience. I may know the first thing about programming, but not the second. But through this, I realized all you needed to solve problems with these systems is curiosity. Perhaps it even helped that I didn’t know better—I didn’t know the risks or downsides. 

‍

‍

And why was Zendesk saying things were impossible? 

It’s not that all of Zendesk was saying something was impossible—it was their support team who, understandably, didn’t want companies creating bigger problems for themselves. But for my clients, these changes were the difference in getting value from Zendesk or not. Clients would hear, “That’s impossible” and it just wasn’t true because Zendesk is a lot more flexible than that.

The trick is, Zendesk often needs some kind of middleware to make it do magic it can’t otherwise do. If you’re willing to think outside the box, even with something pre-built like Zapier or Power Automate, you can go way beyond its advertised functionality. Maybe Zendesk can’t talk to your other system directly, but it can always execute sequences with multiple steps. If middleware provides those triggers so it can communicate with the outside world, there’s a lot you can do. Zendesk becomes the engine. Like, can we interact with these three other softwares all at once? Could we create invoices in QuickBooks even though there’s no integration? Sure. Let’s try it. 

‍

That’s a fun perspective. What projects has that led to?

There was a company that sold copper cooking range hoods that wanted to automate their entire customer journey from form-fill to delivery. It sounds like a simple Zendesk use case but it’s actually quite complicated. This company has an extraordinarily long lead time and needs to keep people engaged that whole time. They have to generate and send computer-aided design (CAD) drawings, send a blueprint, seek approvals, get paid at milestones, and all that could take nine months. 

Here’s how we did it: We set up campaigns in Zendesk where one automation feeds another automation. The customer hears from them every two weeks. But along the way, Zendesk pings QuickBooks to create a new customer there, generate an invoice, and send it. And at some stages, Zendesk would wait for that deposit to be marked “paid” to generate the shipping order for the product. 

Approaching a project where different forms feed different fields across many phases can sound overwhelming. But if you break it down into all those pieces, it’s doable. You just have to know how to ping an outside application. 

‍

Love that. What about an even more complicated one? 

There was another one where a client needed the form in their help center to look different depending on who was visiting. They sold electronic components and their customers needed to have very specific content depending on the five types of product they’d purchased. Simply, VIP customers could ask more questions. And normal customers would be upset if they knew VIP customers could do that.

Not only that, the actual content in the knowledge base needed to change based on who was signed in. If you weren’t a VIP, you could see the three categories. But if you were a VIP, you could see a fourth one, which the client didn’t want anyone else knowing existed until they upgraded. 

We ended up involving QuickBooks and their website and another specific form-builder they wanted to use. Zendesk would take a bunch of automated steps in different places—it’d ping QuickBooks saying, "Here is the information in the ticket fields, and also here is a comment on the ticket that has that information for the customer." And it all just works with no human beings involved at any point.

‍

And you’re sure you don’t know how to code?

Haha well I do know some now, but it’s pretty basic. My advice is, don’t fear Zendesk’s APIs. That was the unlock for me. APIs are magic and anybody can do anything even without being a programmer. They seem intimidating. But you have to be willing to go and test stuff in the API management tool Postman. Because once you realize, “Oh, I just need to know the endpoint and someone else will provide the payload?” you unlock everything. 

‍

‍

This isn’t true of all API documentation, but Zendesk’s will give you 98% of what you need. It’s built by humans with other humans in mind. If you get to understanding that a “GET” call is just reading data, you’re safe. It’s safe to try in any platform. “POST” or “PUT” are riskier, but you work your way there. And once you realize you can repeat things elsewhere with the exact same logic, it’s a game changer. We’re all developers. Even those with accounting degrees.

‍

Let’s say a non-technical reader wants to get started. What do you advise? 

Start with the API management tool Postman. It simplifies the code-building aspect of creating an API call and makes it accessible to anyone. 

Make a simple GET call where you can view the information on a single ticket. Just the act of successfully making a call is a huge first step and helps you see how attainable this is. Now that you have this data, decide what to do with it. Do you want to use it as a placeholder for another automated step further down the line? Add it to a spreadsheet? Send to another software to trigger an action? Your imagination is the limit. 

‍

Any more advice? 

Just be willing to learn and to screw it up. Of course, don’t lie to people. You can always answer, “Let me look into that and get back to you” and find a trial instance and mess with it. What I am capable of today is way beyond what I was capable of when this company started and it’s all just curiosity and telling your client or your boss, “Let’s see.”