AcumatiCares
Challenges
DiamondBack Truck Covers makes and sells hard-shell pickup truck bed covers direct to
customers. The hard covers help truck owners of various models protect and lock items in the
truck bed. The company also sells a heavy-duty cover that can hold some 1,600 pounds.
Co-founder Matt Chverchko designed the company’s first cover when he and Ethan Wendle
were Penn State engineering students as part of a class project. Realizing the size of the
potential market, the duo launched the company in 2003 in Philipsburg, PA.
Truck owners loved the product, and soon, the bootstrapped company took off. For the past
five years, DiamondBack Covers posted double-digit growth and now boasts more than $35
million in annual sales. That growth helped the company land on Inc.’s 5000 fastest growing
companies list annually. DiamondBack now employs 140 at its 40,000-square-foot, state-of-the-art manufacturing facility, a fulfillment center located a mile away from manufacturing, and a marketing and sales office located two hours away in Harrisburg, PA.
The company is a major employer in the small town of less than 3,000 people.
Initially, the company sold its truck bed covers and accessories through automotive dealer
distributors, a sale that required customers to visit a dealer physically. In 2010, they abandoned that
strategy and began selling direct to consumers, a sale made by calling DiamondBack and ordering
over the phone. Seven years later, the company launched a commerce website using Shopify.
“Dealing directly with a manufacturer at that time was really unheard of,” says Kirk Davis,
Director of Operations. “It really set us apart and allowed us to take better care of our
customers and enhance the quality of our products.”
DiamondBack Truck Covers ran on QuickBooks and used Shopify, Freightview, Salesforce,
and Shoptech E2, a job shop management system for its manufacturing operations. None of
the applications were reliably connected, which caused multiple issues and a lot of wasted
time coordinating and transferring data.
“As a startup 20 years ago, we created systems based on what was available on a costeffective basis at the time,” says Davis. “We ended up having lots of different systems that
were bolted together. That worked for a while, but didn’t serve us very well.” The patchwork of
systems was slow, clunky, and hard to navigate, he says. In addition, they had to add positions
to handle data manually as transaction volume grew.
“We had three different systems trying to feed into QuickBooks related to our unearned
revenue and prepayments,” says Lori Murawski, Director of Accounting. “A lot of information
was coming from Shopify, Salesforce, and our E2 system for returns. It took at least two hours
a day for an employee to process all the orders that came in.”
Assembling and consolidating data to close out a month meant keeping the books open for
at least 30 days after month’s end to ensure freight data and credit card information were
included. Both systems were standalone. It took even more time to gather data to update
executives. “We were struggling with getting reporting done in 20 days,” Murawski says.
Other operations also suffered from the lack of application integration, says Scott Stilson,
Manager of Information Systems. “It was really beginning to slow us down a lot,” he says.
E2 operated on an on-premises SQL database that may have been built in the late 1980s,
he estimates. “It was very clunky, and three parts of our quote-to-cash workflow were very
manual, which we had to throw manpower at to manage.”
Babysitting the E2 Import
One of those manual jobs was getting sales orders into E2. “It was someone’s entire
job to babysit the import because it would sometimes throw error messages – that often
were inconsequential – but the import wouldn’t continue unless you clicked OK,” he says.
Unfortunately, the task fell to the shipping manager who was responsible for feeding
production. Stilson estimates babysitting the system took about 80 percent of her time, leaving
only a sliver of time for managing shipping, leading to frequent bottlenecks.
The E2 import often crashed. “It was harrowing and we’d lose a whole days’ worth of
accounting because it would often lead to corruption in QuickBooks. It was just terrible, and
went on for almost a year. Everyone was always on edge about whether the information would
make its way from E2 to QuickBooks.”
Manual Shipping Processes
DiamondBack had to hire more people to handle manual shipping processes as it grew. “The
problem was there wasn’t anything passing the tracking number, the carrier, or the carrier cost
back into QuickBooks or other systems from Freightview,” Stilson says. “They were manually
copying and pasting the tracking number, the carrier’s name, and costs into Salesforce, which
we used for sales order clearing.”
Customer service then had to log into Salesforce if a customer called looking for information.
The shipping information in Salesforce “was also serving as a reference point for the
accounting team when they needed to match freight bills against what we recorded,” Stilson
adds. “So, again, when the volume went up, we literally would hire more people.”
Payment Matching Game
Once order and shipping information was transferred to Salesforce, it needed to be imported
back into E2, so that it could be included in another sync with QuickBooks. Most importantly,
these imports synced customer information, but QuickBooks would create new customer
accounts if something didn’t match exactly, Stilson says.
“Meanwhile we used Authorize.net as our payment processor, and their sync is writing stuff
to QuickBooks also, and this sync has fragility problems as well. Part one of what we called
the payment matching game was to take the customer identified in Authorize.net and match it
with the payment record in QuickBooks. That information then needed to be matched with the
invoice, which doesn’t show up until the product is shipped, and appears in the E2 sync.”
But the invoice isn’t automatically married to any customer record, he explains; it just hangs
out. “So, the second part of the payment matching game is to match the customer and
payment to the invoice, and this was basically all that our AR specialist did because that’s all
she had time for.”
Inefficient Production Processes
DiamondBack didn’t trust E2 data for making purchasing decisions because of the timing of
when material was allocated to production orders didn’t serve their just-in-time purchasing
strategy. Instead, they relied on physical reorder systems and Kanban cards to know when
to reorder a component. In addition, that lack of trust resulted in large inventory reserves
reconciled during the annual physical inventory count.
“We’ve grown by an average of over 20 percent per year, which is pretty big for a
manufacturing company like us,” Davis says. “When we would have a big backlog, we’d have
lots of units sold but not shipped. All of that data would be in the system and it would be a
stinking mess. The more data was in the system, the slower it ran. It was just so painful.”
The combination of all the disparate systems, the time-consuming data shuffles, and the
distrust in the numbers “just made us really rigid,” Davis says. “We felt like we were in the
stone ages of being able to serve our customers. We have lots of SKUs and have to be able to
pivot quickly to serve our customers. The previous system just didn’t provide for that.”
