How to Avoid Communication Breakdowns with Third-Party Ecommerce Integrations

In ecommerce, the possibilities are virtually endless. Technology is ever-evolving, and it can help to solve long-standing retail problems and boost company profits. As merchants build their ecommerce site and backend operations, they have countless options for third-party solutions. These solutions include apps and extensions, as well as more complex systems like an ERP (enterprise resource planning) or warehouse fulfillment software.

But remember: third-party additions do not integrate themselves. On the contrary, every new feature introduces a new variable to an ecommerce site. Third-party integrations need to be supported through strong project management and communication. At Command C, we’re dedicated to solving these issues. Plus retailers can take certain steps to ensure that problems do not start at all.

In this episode of Recommerce, Command C’s founder, Sara, talks with Amanda, our Lead Project Manager, about what retailers should watch for regarding third-party integrations and how to navigate the process as smoothly as possible. You’ll learn:

• The value of a communication plan when coordinating multiple teams, often based around the world
• How the technical discovery process can help you uncover potential third-party glitches before implementation
• Why it’s critical to add your tech team as contacts with all third-parties
• The importance of knowing what kind of support you can expect from third-party partners

Full Episode Transcript

Sara:

Hey everyone. Welcome back to another episode of Recommerce. I’m Sara, the founder of Command C, and today I am here with Amanda, our Lead Project Manager. Hey Amanda.

Amanda: Hey everyone. Hey Sara.

Sara:

Hey. So today, we are going to be talking about common pitfalls that we experience when working with third parties. Just to explain a little bit about what I mean by that: we work on big, complex projects with tons of integrations. So, while oftentimes the core of the project is the ecommerce build, we’re often not only integrating with apps and extensions but also larger systems like ERPs or warehouse management systems. And there can be many different organizations that are coming to the table in a big build. So that’s who we’re referring to when we’re talking about third parties in this case.

Amanda:

Yeah. So, through the evolution of the web, the bigger the project is, the more integrations there have been. And the web right now is dependent on more integrations across the board than it ever has been before. And it’s really exciting because it means we can do a lot more, but it also means that a lot more work goes into making all these pieces play nicely together. So there’s the technical side of that.

And then there’s the project management side of that, when you’re building something out, when you are working with all these teams and what that entails. Because two teams working together is one thing and that’s a relationship that you’re invested in. But seven teams is also a relationship you have to account for it and it’s a different thing than it used to be. So we do a lot of planning around that.

Sara:

Yeah. Yeah. I’m excited for this topic because I feel like it’s one that we talk about internally quite a bit but haven’t really had the chance to delve into it on a more kind of external level. And it’s a big deal. There’s a lot to account for there.

Amanda:

It’s a big deal. And if you’ve never been involved in a build like this, you’re probably not necessarily aware of all the intricacies and all the different parties involved …

Sara: Or planning.

Amanda: … And all the planning that goes in. Exactly. So there are some pain points that come with integrating all of these teams together. And we’re going to talk about those today, but we’re also going to talk about strategies that we can use to alleviate some of the issues and make everything run smoothly together.

Sara: Awesome.

Amanda:

So the first thing we think about from a project management side, when we take a look at all the teams that are going to be involved in something, or not even necessarily teams, it could be a piece of software. There’s a team behind that, but we don’t necessarily work with that team. But there are a lot of different ways that third parties can kind of represent in the org chart of a project.

Communication is massively important. The more people who are involved in a project, the more you have to plan out how the communication is going to happen.

Communication is massively important. And the more people who are involved in a project, the more you have to plan out how the communication is going to happen. And just the more strategy that goes into nothing falling through the cracks. You can, like I said earlier, you develop a relationship with one person or the point person at a company, but suddenly there are two other companies that we’re working with. We’re all on an email chain, potentially. There could be 15 people on it. It just takes a lot of management to make sure that we’re paying attention to make sure nobody falls off the thread and to make sure that the communication, the conversation moves forward in effective ways, not just spinning the wheels.

Sara:

Yeah, and then also, I mean something that happens a lot is someone, on one of the teams, leaves the organization. So that could be your main contact at a company and then all of a sudden you’re like, “Oh, I have no one else to communicate with here.” Or there just isn’t a plan for ramping up whoever is coming in to fill their shoes on the project. That can delay the whole project timeline, potentially.

Amanda:

Yeah, for sure. I mean you would hope that a new team member, as part of them being onboarded into their own organization, them becoming fully abreast of what we’ve been talking about is part of it. But it’s just not always. Sometimes it requires doubling back and repeating information or having the same conversation again that we had before. So that can be tricky. But it’s trickier to assume that they know something that they don’t and to just move forward without that understanding.

Sara:

Yeah, definitely. And I think just even if communication is awesome and all teams are playing nicely, communicating well, there’s just more communication that happens. Each team that you’re working with exponentially increases the number of emails that you’re sending, the number of phone calls that you’re having. So just accounting for that, really thinking that through up front is really imperative to keeping the project on track.

Each team that you’re working with exponentially increases the number of emails that you’re sending and the number of phone calls that you’re having.

Amanda:

Definitely. We have a project right now where we talk to one or two third parties every single day as part of our day. It’s scheduled into our day. And that’s not something we were necessarily aware of the outset of our relationship. But as the relationship grew, with everybody, it became evident that that was part of it. That that was going to be the most effective way to work together. So that’s something we do.

Sara:

I think that’s a good segue into talking about some of the ways that we can strategize around this issue of communication to make it more seamless. And what you just mentioned refers to one of them, which is building in some flexibility or some contingency to the project upfront.

Amanda:

Yeah. I mean with every project you have to be flexible. You have to be more flexible if there are additional teams involved. So what you really want to do when you have different teams involved on a communication basis, you want to make sure that there is a lead for a particular issue, somebody who sort of, whether or not they can answer all the questions or reply to everything, somebody who’s taking charge of actually ushering that issue through to completion. That can be really important because otherwise you can just keep talking to each other and nothing gets resolved. And also always pay attention to who you’re replying to in email. That’s a really basic thing, but everybody’s made the mistake of not hitting reply all. And when one person misses a key piece of information, it can derail you more than you realize. It’s a really small thing to be aware of.

Sara:

Yeah. One other suggestion I have, and this is for the main project manager who’s leading the project, the person typically from the client organization, is create a communication plan. So an outline of all the third parties you’re working with and who that main point of contact is and their contact information. And I think that this topic segues nicely into the next kind of common pain point that we see, which is around scheduling and language barriers.

Create a communication plan that includes the name of every third party on your project, the main point of contact, and that person’s contact info, including their time zone.

Amanda:

Yeah, definitely. So we’re a distributed team at Command C, as are lots of other organizations and a lot of our clients. So this goes across the board, but especially when working with additional teams that we don’t necessarily know at the outset, is we have to make sure we know where they are. Because time zones, there are many of them. We work with folks in all different time zones across the world. Especially developers can be in different regions. And unless we know the time zone that they’re in, it’s really hard to plan meetings or know when you can expect a response to an email. And it’s just a good thing to know because sometimes we expect a response in one day, and they’re already closed for the day. So things take a whole day, or two days, rather than being a quick thing. It’s just something to be aware of so you can plan.

Sara: It’s another good thing to stick into the communication plan is what time zone everyone’s in.

Amanda:

Yeah. Yeah, for sure. I mean, ideally, I’ll ask at the beginning of the engagement what time zone folks are in, and what hours they work, potentially. And then we plan for that accordingly. If the cadence is set by folks being on different sides of the world, then that’s fine. We just need to know that and we buffer accordingly for our deadlines.

Sara:

Yeah. Buffering can’t be understated. So building in that kind of extra flexibility time at each milestone is crucial.

Amanda:

Yeah. I mean at a higher level. Too, and this isn’t just about time zones, but we at Command C, we have certain standards by which we communicate. We like to reply quickly and all these things and keep things moving. But we really have no control over other teams that we’re working with and nor should we. So we just have to have some flexibility around how they work. They may not work in the same exact way that we do and we can’t control their communication cadence.

It’s crucial to build extra flexibility into the project schedule around each milestone.

Sara:

Let’s talk about all of the services involved in a website build. And this is sort of similar to the issue around communication and managing different people. But beyond managing different people, there’s the managing of all the different services that are integrated with your site.

So literally sometimes we’re working with 10 to 20 external app providers or extension providers. We see all sorts of challenges come up around just billing for these things. Losing track of who had the login, who entered the credit card, and what credit card was entered. Some credit cards change and the person who initiated the account is no longer at the organization. So the organization never got notified that the subscription is no longer paid for and then it gets turned off. So I want to look at the idea of managing services as a common pain point.

Amanda:

Yeah, definitely. I mean you have to be really organized. One thing that tends to work for people is to have one email address that’s responsible for managing a lot of these different services. It’s a notification address so that if somebody leaves the agency or the company, all that information and those renewal notices don’t go with them. We had a case recently where this was an issue. Had a client that the person who was in charge of one of their site’s hosting had left, and they had been notified that the hosting was going to close down and that email address had been turned off. So nobody received that notification and the site went down. It would’ve been pretty easy to prevent that from happening if you just used a general email address at the company that’s always monitored by whoever is still present.

Designate one email address for updates about all your site subscription services. Make sure that key staff can access it, regardless of who comes and goes at your company.

Interlude: You’re listening to Recommerce, a podcast for ecommerce wearable brands, navigating technical complexity and change, brought to you by Command C. We are a development team that saves ecommerce retailers from outdated tech and ineffective operations with a strong focus on Magento and Shopify Plus. You can learn more about how we help at Commandc.com.

Amanda:

So, from a technical perspective, third parties can conflict with one another, and that’s not a management issue necessarily, that’s a technical issue. Where one plugin or app may conflict with another app. And it may not conflict with the host platform, the main platform, but these two things when installed together don’t really play nicely together. So these are things we can’t necessarily foresee up front, but it’s just something to be aware of that can happen.

Sara:

So the more apps or extensions or plugins that you’re using, the more variables you’re introducing to your platform. And it’s not always self-evident what is causing the issue. One way that we can do whatever we can do preemptively is a little bit of discovery work upfront to map out the roadmap of the plan. And we’ve been doing this for so long that oftentimes we know certain apps or extensions that are troublemakers, so to speak, from that perspective. But not always. It’s not always predictable, but a little bit of upfront discovery can mitigate it. And also just being prepared for there to be some debugging that has to happen when a conflict arises.

The more apps, extensions, or plugins that you’re using, the more variables you’re introducing into your ecommerce platform.

Amanda:

Yeah, definitely. I mean upfront discovery is super important. It can help mitigate. Doesn’t necessarily solve the problem right off the bat, but it gives a good landscape of what’s controlling what. So that if two things conflict, you have an idea of where to look and try to identify where the problem is without having to debug too much. I mean all these things are like nodes on a network, right? So the more things there are, the more ways that things can happen, things can potentially go wrong if there’s an issue.

So you just want to be really discerning about what you’re building into the theme, what you’re using an app for. In a lot of cases, we build custom apps, which can be a good way to prevent conflicts since we know the code inside those apps really well since we built it. There’s a variety of different ways to go about it and it’s really important to be able to use apps on sites. We don’t want to reinvent the wheel every time. But it introduces complexity. So it’s just something to make sure that you’re planning for upfront.

Sara:

Yeah, and an offshoot of that is that sometimes services go down. And again, kind of this pulls in the discovery/debugging piece in that setting the expectation that there, if an issue happens with your site, there’s going to be some investigation required to figure out the source of the issue. Different issue when a service goes down rather than code conflicting. But this is a very real thing that we see pretty frequently.

Amanda:

Yeah, definitely. I mean even really big services go down. And the bigger the service, the more likely you’re dependent on it at some level. Like if Amazon goes down, AWS (Amazon Web Services), a lot of the web will go down. It’s just how it is. So yeah, I mean there are a couple of different ways to deal with that. Having emergency support in place is good because then you can just hit us up and say, “Hey, my site’s down.” And we probably already know, we’re probably already aware of it, and are working on it if we can. But if it’s AWS or some other big platform or provider, then we know.

Something else that we do frequently and that clients do is just look at Twitter to see. It sounds so simple, but rather than raising a big red flag, just sort of like checking out out there in the ether. Like, “Oh, is there something major going on? Okay, yes. So maybe I’ll just wait a few more minutes before I check my site again.” But these things do go down.

Sara : Especially with major providers.

Amanda:

Yeah, exactly. For sure. And smaller, major providers, too, on which we’re not quite as dependent. Like things like shipping services, UPS, the USPS or whatever.

Sara :

Yeah. Well sometimes bringing down your shipping options prevents someone from being able to check out.

Amanda:

Exactly, especially if you only have one or two. And you know the one goes down. That can definitely happen.

Sara :

Another thing that I think is helpful in this regard is to make sure that your tech team is added to your accounts as technical contacts so that when an emergency happens we can go right to the source rather than having to deal with being added at that point. So we’ve seen that come up a few times. And be really helpful in helping us to get to the bottom of an issue sooner rather than later.

Make sure that your tech team is added to your accounts as technical contacts. Then, in the event of an emergency, we can go right to the source.

Amanda:

Yeah, that’s important especially because even if you give us, for example, your login for something, quite frequently people are using two-factor authentication and we can’t get in anyway. So being added as a contact is really important.

Sara: I think that segues nicely into our next challenge, which is around support.

Amanda:

Yeah. Support is a big nut to crack. Support with us. Folks that we work with have support from us, of course, but we can’t support extensions that we didn’t build. We can’t support apps, right? They have their own support.

Sara: Or Amazon.

Amanda:

Yeah, exactly. I mean there’s only so much we can do really. So one of the things that we look at when we’re adding an extension to a site, for example, is we look at its track record of support. Is it frequently updated? Is the team responsive? If we have a question and we reach out, do they actually respond? It’s just important to look at that history because if you have something that hasn’t been touched in two or three years, and folks have posted questions and they haven’t replied or whatever in the forums, then you got to be a little careful. Think if something happened, maybe we won’t be able to figure it out.

When we’re adding an extension to a site, we look at its track record of support.

Sara:

Yeah, we use that a lot in our early discovery process where we’re reaching out to a couple of vendors. I mean the way that they respond to us initially is very telling for the kind of service provider that they’re going to be. And oftentimes that’s the deciding factor for us in which solution we choose.

Amanda:

Definitely. I mean a solution could look perfect, but if you have an issue implementing it, it never gets off the ground. It’s only, I mean, it doesn’t really work for you.

Sara:

I think being aware of the size of the team behind the particular third party that you’re talking about is also important. I mean these things range from one developer to huge organizations, and just kind of being prepared for what you’re aligning yourself with is important in terms of support.

That brings us to our last point, which is nuanced, but I think an important and worthwhile point to talk about. Which is that product organizations are very different in how they operate from service-based organizations. And this is a nuanced point that we’ve really learned by trial and error.

But just to kind of lay it out, high-level, product organizations are building around this one product that they’re improving and making decisions about based on how to serve the majority of their customers, right? Whereas a service company, like us, we’re doing a lot of very specific customizations to accommodate very specific client needs. So the friction that we can see with a product organization is that oftentimes they can make customizations or they do improve their product. But the timeline for that can vary widely. And also you can’t hang your hat on a certain customization that you need being made, necessarily.

When you need customizations from a third-party, the timeline for can vary widely.

Amanda:

Right. So what we’ve seen happen in the past is a client of ours needs some sort of addition or customization to a product that’s been shipped by somebody else, and they put it out there to that team that they’d like this change. And that team will say one of two things. Well, one of three things, really. A: No, we can’t do that. B: Yes, it’s on our roadmap, and we are never clear really about when that’ll be delivered. Or C: Sure, we can make that customization for you at the following cost. And it’s usually a very hefty addition to their product because it’s only for you.

So that’s sort of how it can go down. And that’s not typical. Typically we’ll hear B. Sure, yes, we plan on doing that in the future. Look back for our next version update and check in with us in two months, or whatever, or six months. But I have seen it be the case where a customization is offered, but it’s typically quite expensive.

If it’s super important to have custom functionality, it may behoove you to build a custom solution, rather than work with a third-party.

Sara:

Yeah, so the thing to consider here when trying to mitigate this issue is, if you have a piece of very, very, very important functionality, it may behoove you to build that as a custom solution. Not always. I mean we want to leverage what work has already been done where possible, but again, if you have this requirement that has a lot of nuance and a lot of very specific functionality, rather than trying to tweak an existing app or extension, it may be a better idea to consider building that piece custom. I think the bottom line to consider is that if a product doesn’t serve the majority of your needs, or if it did at one time, but your needs have shifted, that that might be a good moment to start looking towards a different solution.

Amanda:

Yeah. These folks, products that ship to as many people as possible. It’s just, they’re not going to have your particular needs in mind necessarily.

Sara:

Well, I think we kind of dug into the core issues that we see when collaborating with third parties and hopefully offered some helpful suggestions around how to mitigate for those. And I’ll talk to you soon.

Amanda: Thanks, Sara.