The unglamorous part everything else sits on top of
CRM, accounting, website and the spreadsheets people actually rely on, arriving in one place on a schedule and joined well enough to answer a question that spans two of them. This is where most of the effort goes. It is also where you find out the data is worse than anyone believed.
In short: We move data out of your CRM, accounting package, web analytics, support desk and spreadsheets into one place on a schedule, then build the joins that let a single question cross two systems. Dashboards, forecasts and automated reports all rest on this. So does whether anyone believes the numbers.
One place, on a schedule, with the joins made
Most businesses can already answer questions inside a single system. Your accounting package knows what you invoiced. Your CRM knows what the pipeline looked like. The trouble starts at the question that crosses the boundary, which is almost always the question worth asking: what did the leads from that campaign actually pay us, over eighteen months, net of refunds. Nobody can answer that from one screen, so somebody exports two files and does it by hand once a quarter, and it takes a day and a half.
Sources
CRM, accounting, ecommerce, support desk, web analytics, ad platforms, and the spreadsheets that never made it into a system but run half the business anyway.
Schedule
Nightly suits most things. More often only where a same-day decision depends on it. Every table carries the time it last updated, on screen, where people can see it.
Joins
A customer in the CRM and a customer in the accounts are rarely the same record with the same name. Reconciling them is the work, and the reason this is not just copying.
Definitions
Written down in one document, in language somebody outside the data team can read, so that next year nobody has to reverse-engineer what active meant.
The joins are the actual product
Copying tables from one place to another is close to a solved problem, and there are decent off-the-shelf connectors for the common systems. We use them. What no connector will do is decide that Brightwater Ltd in the accounting system is the same company as Brightwater Group in the CRM, despite the different legal name, a trailing space, and two contact records created eleven months apart by different salespeople.
That is judgment, so we build a matching layer where the rules are visible and can be overridden by a person. Confident matches go through. Ambiguous ones land in a queue somebody reviews, and their decision is remembered so the same pair never gets asked about twice. Over a few weeks the queue empties out and stays small. Without that layer you can report on either system accurately and never on both at once, which is precisely the question everyone wanted answered.
You will find out the data is worse than you thought
There is a week in every one of these projects where somebody’s face falls. Duplicate accounts nobody had counted. A meaningful share of orders with no region recorded because the field only became mandatory in a later version. A custom field that changed meaning in 2023 when a departing employee repurposed it for something else and told two people.
None of this is unusual. It is not a sign that your team has been careless. Every system in the world accumulates this, and it stays invisible for years because nothing forces two systems to agree until you join them and the totals do not match. So we plan for it rather than acting surprised: a profiling pass across the real data early on, before the rest of the work is priced, so that the estimate reflects what is actually there rather than what the documentation claims. Then we write down what we found, in plain terms, and you decide what to do about each item. Some of it gets fixed at source. Some of it gets a rule applied in the pipeline. Some of it gets an explicit caveat next to the number forever, which is not elegant but is honest.
Built so it keeps running without you watching
Pipelines break. Vendors change an API, someone rotates a credential, a source system goes down for maintenance on a Sunday night. The question is not whether it happens but whether you find out from an alert or from a customer. We build row-count checks, freshness checks and reconciliation tests that compare our totals against the source, and we make failures loud. A pipeline that stops with an error is a minor inconvenience. A pipeline that silently serves yesterday’s numbers as though they were today’s is genuinely dangerous, and it is the failure mode people build for last.
Once this layer exists, the rest of it gets much cheaper. Dashboards, scheduled reports and forecasting all read from the same joined tables and the same written definitions, so they cannot contradict each other. Where the goal is writing data back into operational systems rather than reading it out for analysis, that is a different job with different risks, covered by our CRM data integration and automation work.
What we won’t do
We won’t copy a source you have no question for
Every table pulled in is a table somebody maintains forever. We start from the questions and take only what answers them. Adding more later is straightforward; removing something once three teams have quietly built on it is not.
We won’t clean your data quietly
When we find duplicates, or a field that changed meaning partway through, you hear about it and you set the rule. A tidy fix applied without telling anyone becomes an undocumented assumption, and somebody inherits it years later with no idea it is there.
We won’t replace a working system to make things tidy
If the spreadsheet works, we will read from it on a schedule instead of migrating it. Standardization projects nobody asked for are how a three-month integration turns into a two-year program with nothing shipped in the middle.
What question would you ask if it could span two systems?
Name the two systems and the question. We will tell you what the join needs, what tends to go wrong with those particular sources, and roughly what shape the work takes.
For most mid-sized businesses yes, and it is less imposing than it sounds. A managed warehouse such as BigQuery, Snowflake or a hosted Postgres holds the joined data and costs far less at this scale than people expect. Querying live production systems instead tends to slow them down and break whenever somebody changes a field.
How often does the data refresh?
Nightly covers most reporting comfortably. We move to hourly or near-live only where a decision genuinely depends on it, because frequent refresh raises both the running cost and the number of things that can fail. Every table shows when it last updated so nobody has to guess.
What if one of our systems has no API?
It happens more often than vendors admit. The options are usually a scheduled export into a watched folder, a read replica of the database, or a browser-driven export as a last resort. We will tell you which of those we are depending on, because the fragile ones need to be known rather than buried in a diagram.
How long does this take?
A first useful slice, meaning two or three sources joined well enough to answer a real question, usually lands in weeks rather than months. The full picture takes longer and depends far more on the state of your data than on how many systems there are. The early profiling pass is what makes the estimate worth anything.
