BigChange DaaS: What It Gives You, and Where It Stops

BigChange DaaS (Data as a Service) is BigChange’s paid route to getting your own data back out of the platform: job records, finance data and vehicle tracking, delivered every hour into a database your own reporting tool can read. It is one of the better documented routes out of a field service system, and for a business that has outgrown the built-in dashboards it is a real step up. This is a plain look at what it gives you, what it costs, and the questions it still leaves you holding.

What BigChange DaaS actually is

Sign up and BigChange puts a copy of your data into Snowflake, a cloud database built for reporting rather than for running your day-to-day operations. You are not handed the underlying database and left to work out how it fits together. The data arrives already sorted into sets structured for reporting (BigChange calls them data marts), covering job data first and now finance and vehicle tracking as well.

Three things worth knowing about how it behaves:

• It refreshes every hour, so what you are looking at is at most an hour behind the field.
• Data flows one way only. Nothing you do in there writes back into BigChange, so anything that needs to change a record still goes through BigChange’s separate developer tools.
• It is available outside the UK, with everything defined in English and times recorded in UTC.

If you have been pulling data out through the standard exports, or paying someone to write a connection to BigChange for you, DaaS is the vendor’s answer to that: the same underlying data, delivered as a proper feed rather than something a person assembles by hand each month.

In short, it is a paid data service, priced separately from your BigChange licence, that lands your operational data somewhere your reporting tool can properly reach it. (BigChange’s own DaaS page describes this as merging job data into your existing warehouse “for a comprehensive, cost-effective business overview.”)

What it’s good at

It is a proper feed, not an export. Nobody is downloading a spreadsheet on the last working day of the month and hoping it caught everything. The data sits in a database your reporting tool connects to directly, an hour behind live at worst. Reports refresh themselves, and nobody has to remember to run anything.

Job, finance and vehicle tracking all come from the same place. This is the strongest thing about DaaS and it is genuinely unusual. On most field service platforms, vehicle tracking is a separate product from a separate supplier, so getting job records and vehicle records into the same report means an integration project before you can ask your first question. With BigChange they arrive together, already tied to the same jobs and the same engineers.

That changes what you can ask. An engineer’s day shows seven hours logged against jobs; the vehicle data shows the van was moving for three of them. Run that across a region and across a year and you can start to see which contracts are quietly paying for drive time rather than engineering time, which sites are expensive to reach rather than expensive to fix, and whether a patch that looks profitable on job hours still looks profitable once travel is counted. On a platform where tracking is bolted on from another supplier, answering that is a project. Here the two sets of data are already sitting side by side.

The structure has been worked out for you. Being given sets already organised for reporting, rather than the underlying database, saves a real chunk of early work. Somebody would otherwise have to sit down and work out how BigChange’s tables relate to each other before building anything on top of them. That is days rather than hours, and it is the least interesting part of the job. Worth being precise about what this does and does not mean: the shape of the data has been sorted out for you. Whether the values inside it are right is a separate question, and one I come back to below.

Hourly is fast enough. For operational and management reporting, being an hour behind is not the constraint. Businesses that think they need fresher than that usually want an alert rather than a report, and that is a different thing to build.

What BigChange DaaS costs

BigChange does not publish a price. It is quoted on the size of your organisation and how much data you are likely to move, so you will have to ask.

There is a second bill that is easy to miss when you do. BigChange recommends customers hold their own direct agreement with Snowflake, charged on what you use rather than as a flat fee. So there are two recurring costs, and only one of them is BigChange’s. (BigChange’s help centre confirms customers “will need to enter into a direct agreement with Snowflake.”)

BigChange’s documentation also points at a third-party tool for copying the data onward into your own systems. Whether you need that depends entirely on where you intend to build, and it is worth being clear about it before anyone quotes you for one. If Snowflake is going to be the place your reporting is built, you are already paying for it and you can build there. A copying tool earns its keep when you are pulling several sources together somewhere else, and it is one of the cheaper parts of the job when you do need it. It is a decision, not an unavoidable extra.

None of this makes DaaS poor value. It makes it a decision worth costing properly rather than in pieces. Before you sign anything, ask your account contact to price the whole thing together: the DaaS fee, the Snowflake usage, any copying tools, reporting licences, and whoever builds the reporting on top. That last item is usually the largest, and it is the one nobody has costed. If you want a second opinion on the total before you commit, a Data Strategy Accelerator is a fast, low-commitment way to get one.

Where it stops

BigChange tells you where, in its own marketing. DaaS is positioned for businesses that already have people who work with data, and reporting tools already in place. Its own words are that it suits organisations “equipped with data analytics professionals”. Customers who cannot say yes to that are pointed back to the built-in dashboards, and the help centre asks much the same question in a different way: do you already have somewhere central to keep your data, do you already connect your systems to each other. If the answer is no, the vendor’s own advice is to stay where you are. That is unusually straight, and it is the most useful thing in the documentation. DaaS supplies well-organised raw material. It does not supply the answer.

It is still one system’s data. Vehicle tracking being included helps, and it closes a gap most competitors leave open. But pay rates, absence records, HR data and the specific terms of each contract are not in BigChange, so they are not in Snowflake either. The moment a question needs one of those, DaaS has done everything it can.

Your rules have nowhere to live. Overtime, call-out rates, contract-specific terms and on-call calculations tend to be accumulated exceptions rather than anything that was ever written down properly. Tidy data is not the same as data that knows your rules. Somebody still has to set those rules down once, somewhere both payroll and reporting can draw from, which is the job a Data Platform Build or Warehouse QuickStart is built to do.

Data quality comes across unchanged. Jobs left open that were finished weeks ago, overlapping time entries, engineers quietly working around a known quirk in how something gets logged. All of that arrives in Snowflake exactly as it left BigChange. Building reports on top of it makes the errors faster and more official-looking, not smaller.

The tell is the same as always. If the DaaS bill is being paid and someone is still rebuilding the overtime numbers in a spreadsheet every pay run, getting the data out was never the problem.

What joining it to everything else actually involves

“Join it to payroll and finance” is easy to write and it hides most of the work. It is worth knowing what the work actually is, because it determines whether this is a few weeks or a few months, and because it is the part nobody quotes for.

Nothing links your engineers to your employees. BigChange knows an engineer by its own internal reference. Systems such as Sage, Iris or BambooHR know the same person by an employee number that has no relationship to it. The only thing the two systems share is a name, and names fail exactly where it matters: two J Smiths on the same patch, someone who changed their name last year, subcontractors paid through a different route entirely, a leaver whose record was reused. Every payroll question you want to ask depends on this link being right, and it does not exist until somebody builds it. The durable fix is not a lookup spreadsheet that one person maintains. It is putting the HR system’s employee number into the engineer record in BigChange as a custom field, so the link is maintained where the people data is already maintained, then carrying that reference through everywhere else. That is a small piece of process change and it saves years of reconciliation.

Your contract hierarchy exists in neither system. BigChange holds a customer and a site. Your finance system, whether that is Sage, NetSuite, AccountsIQ or something older, holds an account and possibly a contract. They rarely line up. One customer in BigChange can sit under several finance accounts. One contract can cover forty sites that BigChange treats as unrelated. Cost-to-serve by contract, which is usually the question that started all this, needs a hierarchy that neither system holds and that somebody has to define, agree with the people who negotiated the contracts, and then maintain. This is the step that turns into six weeks when it was quoted as two, and it is worth surfacing before you start rather than after.

Job time and pay time are different units. Jobs happen continuously. Payroll runs weekly, fortnightly or four-weekly, with cut-offs that fall in the middle of shifts. A night job crossing midnight belongs to two days and sometimes to two pay periods. Overtime thresholds apply per person per week, not per job, so you cannot arrive at an overtime figure by adding up job hours. The working week has to be rebuilt first, in the shape your contracts actually define it, and only then can the rules be applied. This is the single most common reason a business ends up with beautiful dashboards and a payroll process still being done by hand.

One caveat on the travel-versus-job-time story, since it is the strongest thing DaaS offers. Tracking data is per vehicle, not per person. Vans get shared, an engineer takes a different van when theirs is in for a service, and a mate travelling in the passenger seat generates no data of their own. To turn vehicle movement into a claim about a person’s day, you need to know who was in which van on which date, and that assignment changes. It is entirely solvable, and the answer is usually a dated assignment table rather than anything clever, but a report that quietly assumes one van equals one engineer will produce numbers somebody can disprove. In this sector, being disproved once costs more than being late.

Where the joined data should live. There is no universal answer, but there is a short one. If Snowflake is going to hold most of it and BigChange is the dominant source, build in the Snowflake account you are already paying for and do not add another platform for the sake of it. If you are already a Microsoft business running Power BI and Microsoft 365, Microsoft Fabric is usually the shorter path and the licensing tends to work out more sensibly, with DaaS copied in alongside payroll, HR and finance. Either way, the rules go in a modelled layer with dbt over the top, in version control, so that “what counts as overtime on this contract” is written down once, reviewable, and produces the same answer in payroll as it does on the board pack. That layer is the deliverable. Everything either side of it is moving data around.

Questions BigChange DaaS cannot answer on its own

• What did this contract actually cost to serve last quarter, once engineer pay, travel and subcontractor costs are included?
• Which sites are consistently unprofitable, and is it pricing or delivery?
• How do the overtime rules in each contract apply to the hours we logged, and what did that come to?
• How does absence relate to missed response times?
• Are we invoicing everything we are entitled to invoice on this client?

Each one needs BigChange data joined to at least one other system, with your own rules applied consistently across all of it. That is a question about how your systems fit together, not about getting data out, and it is the part DaaS deliberately leaves to you.

What to do about it

Three steps, in order.

1. Be honest about whether you are the customer BigChange describes. If nobody in the business is going to work with the data once it lands, DaaS is a recurring bill rather than an answer. The built-in dashboards are already paid for, and most businesses have not exhausted them. Start there.
2. Deal with data quality before building anything on top. Open jobs, inconsistent time entries and known workarounds all need attention first. Automating on top of them just makes the errors arrive on time.
3. Build the layer that joins BigChange to payroll, HR and finance, with your rules held in one place. DaaS gets the data to a good starting position. The value comes from what happens next: applying the rules once, reliably, so every report draws from the same definitions rather than from whoever built the last spreadsheet.

If you don’t have data people

Read BigChange’s qualification again, because it is more useful than it first looks. DaaS suits organisations “equipped with data analytics professionals”. Most businesses in the £5m to £30m range are not, and are not about to be. A permanent Head of Data is a six-figure commitment before anything gets built, and the job in a business this size is not a full-time job forever. It is intense for a few months and then occasional.

That is the gap I work in. Fractional Head of Data means you get the person who decides what gets built, sets the rules down properly and oversees delivery, for a few days a month rather than on the payroll. In practice it means somebody is accountable for the answer being right, which is the thing that is actually missing when a business buys DaaS and then discovers that owning the data and understanding it are different problems.

If you are weighing DaaS up and the honest answer to “who will work with this once it lands” is nobody yet, that is worth solving before the subscription starts rather than a year into it.

What this looks like in practice

I should say plainly that I have not built on DaaS. No client of mine is running it, and I would rather tell you that than describe a project I have not done. I have worked with BigChange data, and the work on cloud data warehouses is the work I do every week. Here is what it looked like on a different platform.

At Linaker, an engineering maintenance business, the jobs and the timesheets sat in Joblogic while vehicle tracking sat in a separate system, which is the integration project BigChange customers get to skip. Joining the two and rebuilding the working week in the shape the contracts actually defined it was what made an automated overtime calculation possible at all. That work replaced a paper-based timesheet process and freed two full-time positions in the accounts team. It also put travel time next to job time in the same report, which is a view most contractors have never had. See the Linaker case study

At Flow-Right, the work was payroll, and it turned up something more common than anyone expects. Before any of the calculation could be automated, the pay and bonus rules had to be written down and agreed, because they had never been documented anywhere. No connector finds that. No dashboard finds that. It surfaces when somebody sits down and tries to write the logic out, and it has to be settled first, or you automate the ambiguity.See the Flow-Right case study

The pattern I would expect with DaaS is the one I see everywhere else. A contractor buys it, connects Power BI to Snowflake, and within a fortnight has dashboards considerably better than what they had before. Job volumes, response times and invoiced values all update themselves. Twelve months later payroll is still being prepared by hand, because overtime works differently across thirty-odd contracts and nothing in the data knows that.

The Snowflake data is fine. The dashboards are fine. What was never built is the layer that turns clean job records into a pay figure you can defend. BigChange has done its part well, and its part ends at exactly the point yours begins.

FAQ

What is BigChange DaaS?

A paid data service that delivers your BigChange job, finance and vehicle tracking data into a Snowflake database, already structured for reporting, refreshed hourly, for use with your own reporting tools. Data flows out only; it does not write back into BigChange.

How much does BigChange DaaS cost?

BigChange does not publish a price. It is quoted on organisation size and how much data you move. BigChange also recommends customers hold a separate direct agreement with Snowflake, charged on what you use. Budget for both, plus reporting licences and the work of building the reporting itself.

Can BigChange DaaS connect to Power BI?

Yes. The data sits in Snowflake, so any reporting tool that connects to Snowflake will read it, Power BI included.

Can BigChange DaaS be joined to payroll and HR data?

Yes, but not automatically, and it is more work than it sounds. BigChange identifies engineers by its own internal reference, while payroll and HR systems use employee numbers that have no relationship to it, so the link between the two has to be built and then maintained. Job time and pay periods also run on different clocks, so the working week has to be rebuilt before overtime rules can be applied. Both are solvable and both need doing once, properly.

Do I need a tool like Fivetran with BigChange DaaS?

Only if you are building somewhere other than Snowflake. If Snowflake is where your reporting will live, you can build there without copying the data onward. If you are bringing payroll, HR and finance together in Microsoft Fabric or another platform, a copying tool is the straightforward way to get DaaS data across, and it is one of the smaller costs in the project.

Do I need BigChange DaaS?

BigChange’s own guidance is that it suits organisations that already keep data centrally, already connect their systems to each other, and already have people who work with data. If none of those apply yet, the built-in dashboards are the more sensible starting point, and DaaS becomes worth revisiting once there is somewhere for the data to go.

Can BigChange DaaS calculate payroll or overtime?

No. It supplies the underlying time and job data, but contract-specific overtime rules, pay rates and HR records sit outside BigChange. That calculation has to be built in a layer above it.