When most people think about a CEO, they picture someone focused on strategy, growth, or board meetings – not database implementations. At Cross Country Computer (CCC), it’s a little different. Our CEO personally leads many of the company’s more complex marketing database implementations because the decisions made during those early stages determine how valuable the database will be for years to come. We sat down to discuss what separates successful database projects from the ones that struggle.

Why is the implementation phase of database development so important?

TB: A marketing database is much more than a place to store customer information. It’s the foundation for customer segmentation, reporting, analytics, attribution, and smarter marketing decisions. If that foundation isn’t built correctly, every report and campaign that follows becomes harder to trust.

Implementation isn’t just about moving data; it’s about building a system that helps the business answer the questions it wants to ask today and in the future.

One thing people often overlook is that database design starts long before anyone begins writing code. It starts by understanding how the business actually operates. What questions do you want to answer? How will marketers use the data? What decisions will executives expect the database to support? Those conversations shape everything that comes next.

Where do companies make their biggest mistakes?

TB: Most implementation challenges aren’t technical, they’re business challenges.

Companies either try to build a database that does everything or they focus too narrowly on today’s needs. The first conversation shouldn’t be about tables and fields. It should be about how the business intends to use the database. Will it support customer segmentation? Retention? Attribution? Executive reporting? Marketing extracts? Customer profiling?

Those answers drive every design decision that follows. I’ve also seen organizations invest heavily in enormous data warehouses that contain virtually everything imaginable, yet they still struggle to answer basic marketing questions consistently. More data isn’t automatically better. A marketing database should solve real business problems while leaving room to grow – not become so complicated that no one fully understands it.

What’s the first thing you look at?

TB: Before we write a single line of code, we spend time understanding the data.

Many organizations don’t have a current data dictionary, or the documentation no longer reflects reality. Sometimes documentation exists, but years of system changes have made it inaccurate. That means we often have to reverse engineer the data before implementation even begins.

One of the first things we request is sample data. For smaller projects, we often prefer reviewing the complete history instead of a subset because it can be harder to find the data anomalies that lead to the need for business rules surrounding the data aggregation steps.

We profile the data, validate values, and look for inconsistencies long before implementation begins.

A simple field like Sales Channel might contain values such as Web, Internet and I or POS, Store, and Retail – multiple values that describe the same thing. A purchase type field might contain purchases, returns, exchanges, cancellations, and partial reversals. Until those values are understood and standardized, reporting will never be completely reliable.

That’s the classic “garbage in, garbage out” problem. If you don’t fully understand what’s entering the database, you can’t expect meaningful insights to come out.

What kinds of issues do you typically uncover?

TB: Every company has hidden data quirks.

We regularly find $0 orders, negative transactions, unusually large quantity orders, placeholder email addresses, inconsistent discount calculations, employee purchases mixed with customer orders, wholesale transactions that shouldn’t be included in consumer reporting, and records that technically look valid but shouldn’t be analyzed the same way as everything else. None of those are necessarily wrong. The key is understanding why they exist before deciding how they should be handled. We’re not just validating data. We’re validating business rules.

That usually leads to a lot of conversations with the client. Why is this order negative? Why doesn’t the math reconcile? Are discounts applied at the order level or the line-item level? Should shipping be included? Which totals should we trust when they don’t match? Sometimes the answers are obvious. More often, they aren’t.

Can you give an example?

TB: A customer who purchases the same item three times might appear to be a loyal repeat buyer.

But after investigating, we may discover they exchanged sizes twice. The transaction history looks almost identical. The customer behavior is completely different. We’ve also seen high-volume purchasers who initially look like great customers until we discover they’re actually wholesale accounts that should be analyzed separately. Context changes everything. At this stage, I often feel less like an implementation manager and more like a detective.

The best marketing databases aren’t the ones with the most bells & whistles. They’re the ones that get used.

Tom Berger, CEO

Where do implementations typically fail?

TB: Rarely because of one major issue. It’s usually dozens of small ones. An undocumented export change. A new transaction code. A field where the values quietly changed over time or midway through the dataset. A valid value that nobody realized had been introduced six months earlier. Each issue seems minor on its own, but together they slowly erode confidence in the database. That’s why testing and documentation are so important. We don’t randomly select orders for testing. We intentionally choose transactions that contain unusual conditions because those are the records most likely to expose hidden assumptions.

Many times, those conversations uncover issues the client didn’t even realize existed in their own source systems.

How important is documentation?

TB: It’s one of the most overlooked parts of implementation.

Throughout every project, we maintain a working document that becomes the source of truth for the implementation. It captures business rules, field mappings, assumptions, exclusions, anomalies, and the reasoning behind important decisions. The goal isn’t simply to finish the implementation.

It’s to make sure someone joining the project two years later doesn’t have to rediscover everything we already learned. Good documentation preserves knowledge just as much as it documents the database.

What role does reporting play?

TB: Reporting shouldn’t overwhelm people with dozens of dashboards. It should create a continuous feedback loop that helps marketers understand customer behavior, measure performance, and make better decisions.

I always encourage clients to resist the temptation to measure everything simply because they can. Information overload eventually causes people to ignore the reports altogether.

Well-designed reporting helps answer important questions, reveals trends, and often leads to better attribution by bringing together direct mail results, digital marketing activity, customer engagement, and purchasing behavior into a much clearer picture of what actually drove the sale.

The reporting itself is only part of the equation. The real value comes from understanding what the numbers are telling you and how to act on them. That’s why Elisa personally leads our dashboard reviews with clients, helping them interpret results, identify meaningful changes in customer behavior, and focus on the metrics that matter most to their business.

The goal isn’t more reports. It’s measuring the right KPIs needed to make better decisions, and taking action.

What’s your advice for organizations beginning a database project?

TB: Build for the future – but don’t overbuild.

Technology changes. Business needs change. The database should be flexible enough to grow without becoming unnecessarily complicated from day one. I have seen database RFP’s that contain complex requirements that increase cost and contain features and functions that never get used.

The best marketing databases aren’t the ones with the most bells & whistles.  The best marketing databases are the ones that get used. Thoughtful design, careful testing, thorough documentation, and at least one person on the team who can leverage the tool for the organization – that is the secret to long term success.

A marketing database that is not used returns no ROI. Dedicate the right resources so that your database can help the organization better understand its customers, make smarter marketing decisions, and continue evolving with the business.