Erik: James, good afternoon. Nice to meet you. Thanks for joining us on the podcast today.

James: Absolutely. Thanks for having me.

Erik: James, I always love talking to entrepreneurs that are in very vertical or very, let's say, use case-based companies. Because it's always extremely clear what you do, as opposed to sometimes I'm talking to people that are these horizontal, we can work with anybody in the world — which could be great businesses but, for me, as a host, a little bit more challenging. So, I'm looking forward to understanding the problem space here.

James: That's funny. That may have come out of my co-founder and I have a history in freelance development. Maybe the years of punishing having to work on a wide variety of projects when we went out to solve a problem, we wanted it to be fairly specific.

Erik: Yeah, right. So, that was with — you have BeneShip and Beneflix. I guess, would it be BeneShip that is the freelance DevOps company?

James: That's right. Yeah, that was where the company name for all the freelance work we did for shipping technology companies.

Erik: Okay, interesting. Basically, they would come to you with a problem and say we need a solution for X, and you would help them to develop the MVP, or maybe even the live, the full product.

James: Yeah, it was a mix. 2009 is when we, Pat and I, took our first contract job for a shipping software provider. Like most people in the supply chain or supply chain tech, once you do one, you're just going to get sucked into this space. And so, it was a mix. We did a lot of freelance weird integration projects that nobody else wanted to touch. Towards the end, we got commissioned to build a fully-fledged web-based shipping system. So, we were kind of all over the place.

Erik: Then I guess, was it through that process where you were just continuously encountering ideas and eventually you came upon one? It's always interesting to understand the logic behind starting a company. Because you have, to some extent, infinite options ahead of you and then you have to choose one. So, how do you make that choice what to focus on?

James: Well, a whole bunch of different things converged. One was our getting burnt out on putting out other people's fires and just wanting to own something, frankly, just wanting to have our own IP that we could have. At that same time, FedEx and UPS started penalizing poor packing. And so, we had developed all these relationships over the years with e-commerce companies and other shippers and said, "Wait a second. I'm getting absolutely hammered now on my carrier invoices. I'm trying to see if my existing software can help me figure out how to pack things efficiently. It's not working." And so, I wouldn't say we looked around a whole lot. We just listened to the common refrain which was about this problem. And so, we set out to fix it.

Erik: I'd love to learn a little bit more about that. So, what was the policy change? Was it just a pricing model change that they enacted?

James: Kind of. Historically, the carriers — FedEx, UPS, but also a lot of the regional and up-and-comer carriers — they charge just based on weight. Back before e-commerce was so crazy, so huge, you would more often just get these big boxes with a tiny thing rattling around in it. Because there was no financial repercussions for packing in a haphazard way.

The idea of penalizing for poor packing, the way the carriers look at it was, instead of just saying, "We'll charge based on density," they said, "We'll come up with a new definition of weight, and we'll call it dimensional weight." And so now, every package, when you order something online, the company that shipped it to you is charged something called dimensional weight, which basically just takes how much air is in the box into account when they get charged for it.

Erik: Okay. Interesting. So, it's kind of a function of the physical weight and then the dimensions of the box, and they have some equation that spits out a number there.

James: Exactly.

Erik: Okay. Got it. Then everybody found themselves starting to pay more for shipping large boxes and not having a solution. What was the status quo? You mentioned they already had a software that was helping with the packaging process. What was the status quo for the process at the time?

James: Yeah, some companies had a software for it. But that software required knowing the dimensions of the products that they were actually shipping, which not many companies actually did. So, it was this low tech, just relying on tribal knowledge. I think one of the first companies we talked to when we set out to build this, they literally just had posted notes on the warehouse wall next to the pack stations of like, "Make sure you don't put this product in this box." Some fairly low-tech stuff. As time went on, these shippers started looking at the simple algorithmic approach, where if I'm shipping this phone, the math would say, okay, what's the total cubic volume of this? Is it less than the total cubic volume of the box? Then it would give the person at the pack station that, hey, okay.

That's pretty basic. It's not acknowledging three-dimensional space. It's almost treating objects like a liquid. That was creating a lot of problems for people. Because if you imagine — an extreme example is a shovel may have a lower total cubic volume than a box. It doesn't mean it's not going to put a hole right through it. It doesn't account for fragility or items being able to stack, nest, roll, all these things. Pretty, pretty low tech. And so, this is really what a lot of the shippers that we had done work for and worked on projects with, where they're just having to put too many custom guardrails around this math that came baked into their warehouse software.

My co-founder, Pat, is a brilliant engineer who's worked on other AI projects for med tech and all these things. And so, we basically created an engine that plays 3D Tetris automatically. Every time a shipment comes to the pack station, our algorithm runs and then spits out a picture and instructions for which boxes to pick, but also how those items should go in the box.

Erik: I'm curious if there were any — I mean, you mentioned e-commerce already. But just if we think about the dynamics in the market, I'm imagining, on the one hand, companies are shifting from the — maybe this is already 20 years ago. But we produce a lot of a few things towards we produce a lot of things. So, diversity of skews. Also, I don't know if this was already happening in 2018, but now you seem to have these almost — for lack of a better word — migrant workforces. Like, okay, we need to hire three times as many people for two months to push through. When you talk about that tribal knowledge, that's just not going to exist when you're in that type of workforce. Are those new trends, or were those already 20 years ago? Was it the same dynamic there?

James: Definitely, new in terms of how common it is. Actually, our first customer is a company called Lionel Trains. I don't know if you've ever played with model trains as a kid. They're an amazing company. They're like 100 years old ton of history but very forward-thinking when it comes to technology. As you might imagine, they're not shipping a lot or as many model trains in the summer. It's a Christmas gift thing, so the entire workforce is — it was pretty seasonal. It was just too heavy of a lift to have to retrain these folks every single time. So, we came together. Now we put up packing instructions. Their packers also don't have to worry about making a mistake because the instructions are right there.

Erik: Great. Well, let's talk a little bit about the business side here of Paccurate. Lionel Trains, obviously, is a B2C, shipping direct to consumer. Is that kind of your sweet spot? Do you also do B2B environments, shipping components and so forth? What's the customer group look like?

James: Yeah, kind of everything. A lot of our B2B customers are auto parts companies. As long as there is some complexity, that's usually when we can provide some value. Definitely, the vast majority of our customers are e-commerce shippers because there's a speed in which they need to fulfill, where mistakes are more likely to happen. And so, if we can help put some controls around that and bring down the average cost of their shipping, we can help with their margins. That's usually what our customer looks like.

Say, home goods, it’s a pretty popular vertical for us. One of our first large customers was Crate and Barrel. As you might imagine, they have a good degree of complexity. They don't just have one definition of 'fragile'. They have a lot of different concepts of what fragile means, so that their goods arrive intact. And so, that was really when the first time that our engine got put through its paces. We had to make sure it was production-ready and can handle all of that.

Erik: Oh, that's interesting. Because then, it's not just the product dimension but it's the product plus the packaging. The packaging might end up being three times as significant as the product.

James: Right. Yeah, the fill material, can this be stacked, can it not when it's with a certain other item? You can really go down the rabbit hole in terms of what the constraints are for an actual — one thing tribal knowledge is good at is, it's not really great at eyeballing three-dimensional space, but it's really good at understanding what is appropriate. That's what humans are good at judging: what's appropriate. If you're standing in a pack station, you can intuit that you shouldn't put a bowling ball with a China cup. But you may have a hard time. Just being a human being with a brain that works the way that we do, you may have a hard time when you're under the pressure to move product that this is the right box for the shipment. It's pretty difficult to eyeball.

Erik: I'd love to get into how you build the algorithms for the customers. I guess, it is going to be a combination of mathematics and then tribal knowledge, right? But before we go into that, just a bit more on the value proposition. Cost reduction, obviously, a big thing here. I'm curious about sustainability. I mean, this is a topic that we've started seeing people talk about a lot more. It's always a bit of a question, situation by situation of, is this something that we talked about but it's priority number seven? Or is this really driving decisions around how we operate? What does it look like here? Because there's obviously an implication, but I'm actually not sure to what extent people are really making decisions based on this.

James: Well, packing really the cartons, in an e-commerce business specifically, is the atomic level of your supply chain. But what makes it a special area to do any kind of optimization on is that, basically, everything related to the material, to the actual shipping, you're paying to pollute effectively. Anything you can do to shrink the box, reduce the material, the cost savings and emissions reduction tend to scale one to one. So, if we're able to reduce your total average size of your packages by 14%, you're going to need 14% fewer trucks leaving your DC on average over time. That's really what myself and my team get excited about. We don't really care what the reason is that the customer has for wanting to solve this problem. It's kind of irrelevant. Because if you're trying to cut costs by looking at this area, you're also going to make things greener.

But to answer your question, we see a mix. We see some companies are really driven now by sustainability. Surprisingly, this may sound cynical, but surprisingly authentic way. A lot of these folks, like Crate and Barrel was like this. They didn't give any sign that they were looking for a marketing win. They saw a problem, and they were extremely excited by the numbers that we were showing them about what they could achieve in terms of waste reduction. On the other side, sometimes our champion at a prospect company, they will reveal that their hidden motive is sustainability. But they need help selling it up the chain and putting it in terms of cost savings.

Erik: Got you. That makes sense. Yeah, at the end of the day, there's going to be a number of different stakeholders involved in the decision. They might have different priorities. So, it's good to be able to address that from a couple angles. Well, let's get into the solution here. You were mentioning tribal knowledge. Then obviously, there's a lot of mathematics involved here. How does the solution work? How does it cap? Basically, because every company is going to have unique priorities in terms of cost reduction, in terms of quality assurance, et cetera. And so, I imagine you're going to have to be customizing this or allow them to customize it. What does that process look like?

James: Actually, our engine is accessed via a stateless API. It's got all the features that all of our customers use in the API schema. So, there's really no custom — I mean, very little custom development per customer. Usually, we'll sit with them and try to understand their requirements, their tribal knowledge requirements. How do you translate those into terms that our API would understand?

The Crate and Barrel example, we don't have a fragile feature because that's too vague. So, we work with them to define those things in a way that can be translated into the API. So, it's really simple. It's a single stateless API endpoint. There's no configuration on our side because we don't want to save anything, because we want to return a result in milliseconds. Everything about every shipment, you have to put in every request. We do the math, and then we send back the answer.

Erik: Got you. 100% cloud-based solution, is that right?

James: That's right. We have a couple on-premise, but it's definitely the exception.

Erik: Okay. Clear. Just on understanding this, you have your APIs that the customer is interacting with. You have your decision engine that's sitting in the cloud. Then if we think about the implementation process, I guess there could be some circumstances where it's so clear that somebody a day in can basically be using the solution. I do imagine that there's other situations where companies need to figure out how to, to some extent, customize the software. So, what would that implementation process look like?

James: There's a couple of different popular use cases. One is in WMS software, the warehouse management system, or a separate packing station software. Usually, in a pack station where there's a human being assembling these shipments, there's a screen. They have to scan the items, so the system can say, "Yep, you got the right items for that order." That's usually where our customers put the packing instructions that we return.

But the other use case that, all of a sudden, this year has become quite a bit more common is calling the API from the online shopping cart. This is another weird thing that has remained low tech. That is shipping estimates. They've historically been just totally basic math, like based on the number of items but generally divorced from what the actual cost of shipping is. We've seen quite a few e-comm shippers come in and say, "Let's make this shipping quote accurate based on how this thing is actually going to be packed." That's been an interesting development.

Then beyond that, as we get more into integrating with automation machinery, we have one company called Hunter Douglas that uses our API to drive their box-making machines. I don't know if you've heard of that company, but they make custom shades and blinds. Previously, they had to have an operator come over, measure the blinds that they were shipping and then type it into the machine to make the custom shipping boxes for it. But today, now Paccurate just automatically drives those things to the right boxes or spit out at the right moment.

Erik: Okay. So, they're uploading a CAD design file or something, and you're making decisions based on that. What's the input data?

James: Yeah, the input data. At a minimum, we need item dimensions. If they're not using a machine, box dimensions, what cartons do you have available? Then beyond that, there's item rules and business rules. Then our big differentiator, the reason why we exist actually is because of our methodology, which is, we found that the size of packages was an okay stand-in for lowest costs. It stands to reason. If you make a box smaller, it's going to cost less. But we found it's not perfect. And so, the way that we wrote our algorithm is to optimize for cost directly.

That means we're not just looking at trying to make stuff smaller in a three-dimensional space. We're looking at labor costs. What is the labor implication of opening a second box, even if the carrier rate tables seem to incentivize opening that second box? What's the packaging material or emission's implication of opening more than one or two boxes? All those things are being reconciled at the same time. I would say that's an advanced down the rabbit hole use case. That's why a lot of the larger companies come to us at the moment.

Erik: I think we've covered retailers, 3PLs. You also have forward carriers here, a different customer group entirely. But how would they be using this software?

James: They're more referral partners. Because it turns out, even if we're reducing their revenue on a per shipment basis, they end up becoming more profitable because they can fit more packages into a single trailer. Because each of those shipments has a base cost, they come out ahead. There's a reason why carriers are incentivizing packing more efficiently. It's not just because they want to collect when you screw it up. It's because there's actually a financial reason why it's better for them if you're packing more efficiently.

Erik: Got you. I'm imagining it. Because I'm aware of innovations going on right now in the industry around packing solutions, especially around the topic of sustainability and how to reduce material usage. Creating packing materials that have a lot of volume with a small amount of material, for example. I'm curious. Are you involved in that process of helping companies to decide not just from protecting the product and then obviously managing the size of the box, but also if you use packing material X, that might give you a lower sustainability impact while still providing the protection you need, and so forth? Do you have these kinds of recommendation engine around also the packing material into the algorithm?

James: Yes and no. We don't do anything related to packaging engineering. So, we're either working with the packaging engineers at these companies or bringing in a friendly packaging engineering firm to help us, if that's part of the project. But besides the API, the other half of what we do is analysis. We just recently released a new product we call PacSimulate, which we actually built on top of our existing engine. But it turns it into a big data analysis app.

A shipper can come in, upload historical shipping data. In the background, the engine is running through millions of iterations of those shipments. Then at the end, it'll spit out an answer to a certain question. The most common of which is, "which carton sizes should I keep in stock," which is a fairly simple question. But if this was another case of, every time we would go into a medium to a large-size customer and they would say, "Okay. Fine. We get it. We believe you this is going to save some money. We'll use the API. But how do we know if we have the right cartons," it's another case of building out something that people are asking for.

Erik: Yeah, I got it. It's interesting, because I can imagine how this solution would interface with different business systems. Because you are talking about inventory management here. You already mentioned upfront order entry. Maybe you have data going into the CRM, or you have data going into the order documentation. You get into inventory. Maybe there, you're talking about the ERP system and planning. You obviously have the WMS in the picking system and then the TMS in packing. So, you have these different systems that you're interfacing with. I guess, that's all through API. What does the interface look like? Then, I guess, in terms of the system integration, imagine if you're using APIs that's all built-in. But what does that process look like typically from a customer's perspective?

James: The first step is what I mentioned, where we sit down with them and understand, help them write the configurations so that they can do the rest of it themselves. Depending on what system they want to call the API from, it's not a heavy lift. I mean, it's just the JSON API. Most developers are fairly comfortable figuring out how to call one of those. And so, the average time to integrate, I think, is two weeks the last time I checked, even for the larger shippers. So, it's pretty simple. We provide this endpoint, and we consult on how it should be set up.

We definitely have plenty of customers that we've never actually talked to. Because all our documentation is public, and they don't respond to my emails. They just put in their credit card, and they appear to be using it. That has been a blessing and a curse. Because we're a startup, we're so happy that people are signing up. But we wouldn't like that kind of relationship. So, we got to understand how to get better in real time.

Erik: Yeah, I'd love to hear one or two of the more complex case studies, but maybe quickly on the pricing. I mean, it is remarkably economic, right? All the way from $99 a month for a startup, $249 a month for professional which is 5,000 parcel requests per month, 25 pallets. That's like a medium-sized business and then, obviously, the enterprise.

What does that look like today in terms of your customer segments? Are you working a lot? You've already mentioned a few of the larger enterprises you're working with. But do you have a large volume of small business, medium-sized business customers as well?

James: I think we're like probably every other business where it's the 80-20 rule, where 80% of the revenue comes from 20% of the customers. Most of the plans that you just read off, the public ones, mostly, small shippers just getting started. But it was important to us to make that available. Because the savings that you can get there, the same percent or higher for smaller shippers. As long as their use case is simple enough, we want as many, many companies reducing their carbon footprint as possible. But on the high end, the companies that are coming in now are not doing 5,000 shipments a month. They're doing 400,000 shipments a day. So, quite a bit different scale there.

Erik: Let's walk through one of the more complex cases. If we can start from your first conversations with the customer, you’re understanding their needs, and then all the way through implementation towards day-to-day operations.

James: Sure. A typical use case will be somebody — either a packaging engineer or a procurement people or somebody on the ops side in fulfillment — will have a hunch about something, having to do with the way that they pack, the way that they're controlling packing, or the way that they're figuring out which cartons they should keep in stock at their pack station. And so, we will always start. The first step in our sales process is always to do an analysis, because it's pretty easy. As long as they have the data of what their item dimensions are, what these historical shipments were — we get samples of anything from 5,000 shipments all the way up to 2 million shipments — we have tools where we can upload that. Then it'll spit out a report of how Paccurate would have packed those things. They can drill down to see that we're not fudging the numbers by looking at individual shipments and see the instructions that we generated for those.

After that, it depends on how large the organization is. Sometimes we need to help build the business case for rolling this out across all their locations. If we're not able to do that effectively, usually, what happens is we get a pilot. Or they're saying, "Okay, fine. Just put it in this location, see how it does." We try to avoid that if we can. But that's how the way it goes sometimes. The other way that people come in is if they say — maybe they're a group of data analytics people or packaging engineers, and they say some variation on the phrase, "Our shipping volume is up, but our profits are down. We suspect it has something to do with the way with how much cubic utilization we have."

We'd like to hear that, because that's pretty three steps ahead of a cold conversation about these problems. That's how they tend to come in. Then after that, they schedule the implementation. With our new offering, PacSimulate, it's great because we don't have to wait for integration. The WMS team, they don't have to put us on their schedule to do that. We just have to upload order data, and it'll tell them which cartons the procurement people should go get. It still has a pretty profound impact on their costs.

Erik: Got you. Okay. So, within two weeks, they're basically operating. What ROI are you looking at? I don't know if you're able to break that down in terms of what percentage is due to shipping rates, what percentage is due to labor efficiency, et cetera. But how do you calculate ROI, and what do you tend to aim for?

James: Labor is something that we actually hear the most about from happy customers. But we haven't figured out a way to make it generalized enough to claim anything. It's easiest for us to focus on transportation costs and material costs. I think the average savings is somewhere in the realm of 50% to 60% more savings than prior solutions on transportation. In terms of corrugate, we see an average reduction of one square foot of cardboard per carton just by, on average, choosing smaller ones. Those are the kinds of things we tend to key in on because they're the most simple to explain.

3PLs care more about labor. They're more likely — when we first talked to them, they're more likely even to know off the top of their head what the labor cost is of allowing a packer to open a second box. We love that because we can plug that in to the analysis, and see what happens when we start messing with some of the values.

Erik: Yeah, got it. Do you have any time to pay back figures from prior cases?

James: Most of our customers pay on a metered basis per use. As long as you're doing 1,000 shipments a month, it should be instantaneous. PacSimulate is a little different, because you're using it for various analysis projects. It's extremely computationally intensive. Depending on what you're doing an analysis on, that can maybe take a few months or up to a year depending on what you're doing. But the APIs, it's right away. Because we're just plugging in and immediately changing the way that they operate.

Erik: You mentioned that you prefer not to run with pilots first. I'm curious. The pilot is always an interesting beast. Because it's like, how representative of normal operations is it? But it's the natural step for a risk averse decision-maker to take. Why is it that you prefer not just to say, "Let's run a pilot for three months," and then decide how you want to scale?

James: It's mostly practical. If we have to do a pilot, we want to work with our champion to make it short, make it very clear what we're trying to prove here, and make it no longer than three months. We need to prove something beyond the initial analysis and the numbers that we deliver. That's absolutely understandable. But let's keep this succinct and have a clear objective so we can move on.

I think, just from a practical standpoint, priorities change in an organization. Trying to make sure that we're seizing on that excitement, that we stay focused. A lot of our customers have anywhere between 5 and 20 different distribution centers around the country. We don't want to stall out because there was a change in management six months later or something happened. So, that's why. It's more of a practicality thing of getting this done. Usually, if our champions are fairly passionate about this is because of the sustainability implications. And so, they're pretty supportive of this approach as well.

Erik: Yeah, that's a good point. Momentum is very important in any kind of business decision. Well, James, let's talk a bit about the future here. I know you raised — at least, CrunchBase is telling me that you raised 2.2 million in May as a seed round. I guess, that's allowing you to now be a bit more ambitious with the product roadmap. If you look over the next, let's say, 12 to 24 months, what does it look like? Is it rolling out a lot of new functionality? Is it moving into new customer segments? Is it geographic expansion? What are the priorities for you?

James: Yeah, well, it's a few things. Well, I'll start with this. Our next round, which will probably be somewhere towards the end of this year, will be focused on funding integration. Because right now, we've got this stateless API. We're like, use it or don't. Here it is. Enjoy. But we found especially like mid-sized customers don't have the resources to do their own integration or can't prioritize it. Having some out-of-the-box integrations with e-comm software, shipping software, all these things, that's stuff that we're setting up now. But we'll actually build it out next year.

In the nearer term, with PacSimulate — I won't speak for the whole team, but I think they are too — we're certainly fascinated with this idea that the physical packaging could be so reactive to the complexity of fulfillment, where if you change your carrier — this is what we're finding in real time as new shippers use the platform. If you change your carrier or you change your product slightly, your mix of cartons you have at your pack stations should change as well. There has never really been that agility — to use an overused word, agility — before when it comes to packaging. So, I'm finding that extremely exciting. And so, I think the platform will move towards making it easier to acquire those cartons directly in the platform.

Erik: Yeah, I'm wondering. It's a dead inventory, is always a topic. If you just have a bunch of packages sitting somewhere in a warehouse and nobody has used them, but you haven't turned them away because maybe you'll have to use them. I imagine this is one of those areas from a warehouse management or inventory management perspective that you can just go, "Nope, nobody really makes a decision." Because how do you make a decision? There's a little bit too much uncertainty there.

James: Absolutely. I would say most shippers, most large household name brand shippers, have not even done the older school method of this, which is hiring a packaging consultant to come in and do some high-level analysis and tell you which boxes you should swap out. A lot of these companies haven't changed their cartons in 10 years, which is pretty crazy to me. Especially because, they're watching these boxes go out the door with 1000 air pillows in them. Part of it is, there's been turnover at every level of the company. They may think of changing their cartons. But then, they're like, "Well, wait a second. This was really important to buy this weird-sized carton for some reason, at some point. I don't know why it's here. I'm afraid to get rid of it." It's an interesting — cartonization is not new. But this carton optimization, carton mix optimization is new. So, it's interesting seeing how people have tried to deal with it previously.

Erik: Yeah, I can imagine that, especially for the medium-sized businesses. At some point in the future, if you have almost an e-commerce model of saying, "We can help you to. Like a shopping cart, we can help you choose the right packaging." Because big businesses are going to hire consultants, or they're going to have a dedicated team that will do this. But small businesses, it's like, "We found this package. It seems to do the trick. But maybe there's something that's more robust, that's 30% cheaper. We just don't know about it." I can imagine that that would be a useful, at least, decision to help people with at some point in the future. Geographically, are you guys 100% focused on the US right now?

James: Most of our customers are here, but not really. We've had more and more new prospects coming in from Latin America and in Europe, Canada. That's been the extent of it so far. But we haven't really done any marketing outside of those areas either.

Erik: Got you. When you start to look into other geographies, do you have to consider regulation? Are there different taxes that start to impact decisions and so forth, or is that not a factor?

James: Yeah, I wouldn't say they have a whole lot to do with any decisions about which regions. It's more, where does our current balance of expertise lie? We can create the most value right now for companies that are shipping using American carriers or American-centric carriers. But on the other hand, look at some of the legislation that's coming down the pipe in the EU and in other places where they're actually targeting the cubic utilization of boxes. They're saying all e-commerce shipments must be at least 60% full? Well, that's another kind of like, "Well, what? I've never had to worry about this before."

And so, I think there's a lot of opportunities for us to help shippers that are struggling with a lot of legislation, especially around scope 3 emissions related to shipping. That feels like it's coming out of left field a little bit, I think, for shippers that are barely just getting a handle on their existing operations. So, we're going to just follow where the need is.

Erik: Good. It makes sense. Well, James, thanks for the conversation today. It looks like you're building a great business. I always love these very focused businesses. I think, in 40 minutes, we were able to really cover a lot of topics. Anything that we didn't touch on that's important for folks to know?

James: I don't think so. I think if you're a consumer, if you get a badly-packed box, let us know and we will politely poke the company that shipped it to you. But on another note, in your e-commerce shipping, if it's not something you need urgently, consider picking a slower shipping option because that will result in less pollution in general. That's my tip for those environmentally-minded consumers out there.

Erik: Great. For folks that want to follow up, the website is paccurate.io. So, paccurate.io. James, thanks for taking the time today.

James: Thanks so much, Erik. This is fun.