FAQs

Quantum Spark exists to help organisations work out what they need, before they go shopping for it. Most technology and AI projects begin with a product or a vendor conversation, when the harder, more valuable conversation, working out what "good" actually looks like, hasn't happened yet. That's the gap we sit in. We're independent of any vendor or platform, so our advice starts and ends with your goals, not a sales target.

Quantum Spark was founded by Rich Lansdowne, drawing on 35 years in technology, including 28 years at Semtech Corp, the company behind LoRa and LoRaWAN. His career spanned the technology stack, from radio equipment and silicon design through to network infrastructure, IoT, cloud services and enterprise strategy. That technical breadth, combined with more than 15 years of P&L responsibility and board-level experience, allows Quantum Spark to bridge the gap between the people who need technology and the people who build and sell it.

Both, though it's worth drawing a careful line between the two. Rich's time at Semtech, as part of the team that created LoRa and LoRaWAN, means the advice includes real hands-on experience. This spans from the internal details of the hardware such as sensors and gateways to the protocols and functions of the network servers and cloud platforms. But Quantum Spark itself doesn't sell or install LoRaWAN, or any other specific technology, today. That hands-on depth informs the strategic advice and shapes the questions we know to ask, rather than becoming a product we're pushing. The outcome of the strategy development will inform the technology choice and the build/buy decisions, while the execution phase will help to select vendors and partners.

Quantum Spark works alongside you as an embedded, independent advisor, not a team arriving with a solution already decided. Every engagement starts with your organisation's actual goals and readiness, not a standard package. The Readiness Review, the strategy and the execution support that follow are all shaped around your context, your estate, your constraints, so the relationship stays bespoke from the first conversation through to delivery.

No. Quantum Spark doesn't sell hardware, software or platforms of any kind. That independence is deliberate, it means our recommendations on what to build, buy, own or rent are shaped by your needs, not by a product we need to move. What decades in the industry does give us is a wide network of direct vendor relationships, so where a specialist solution is genuinely the right answer, we can draw on contacts most organisations wouldn't have access to on their own.

Quantum Spark works with organisations for whom technology isn't the core business, but has become impossible to ignore. That covers schools, hospitals, estate and facilities management teams, and product development companies, often in the public sector or managing ageing estates, where the pressure to "have an AI strategy" is real but the starting point is often unclear.

It's the fog of overloaded language that surrounds most technology decisions. Words like "platform," "gateway" or "management" get used constantly, but rarely mean the same thing twice, so quite reasonably every vendor and system uses them slightly differently. For an organisation trying to make a confident decision, that ambiguity is often the real barrier, not the technology itself. Cutting through it is where Quantum Spark starts.

Because each of those words describes a role rather than a fixed thing, and different vendors build that role differently. A "gateway," for instance, might be a physical box translating sensor data into something a network can carry, or a piece of software doing the same job in the cloud, and both are correctly called a gateway. This kind of ambiguity is exactly what the maze of complexity is made of, and it's one of the more common reasons projects stall before they start. We can't unpack every term here, but if this is the kind of confusion you're facing, it's worth a conversation.

Pilot purgatory is what happens when a promising pilot project never quite becomes a real, funded, organisation-wide capability. It stays small, stays "interesting," and quietly stalls, often because no one worked out from the outset what success needed to look like, or what would need to be true to scale it. Avoiding it starts before the pilot does, with a clear view of the destination, not just the first step.

Usually because the buying decision came before the strategic one. An organisation identifies a problem, finds a product that seems to address it, and only later discovers that the product doesn't fit how the organisation actually works, or was never going to get them all the way to where they needed to be. Getting the sequence right, understanding the destination before choosing the vehicle, is most of the battle.

You can, and many organisations do, but time and internal expertise are often the constraint, not willingness. Technology and AI move quickly, the vendor landscape is wide, and getting it wrong is costly in time and money as well as budget. Quantum Spark exists to shortcut that learning curve, bringing structured, independent judgement to a decision most teams only make once every few years.

A Readiness Review is an honest look at where your organisation stands today, where it's heading, and the size of the gap in between. It covers your current technology estate, your goals, and where AI genuinely has a role to play — and where it doesn't. Just as importantly, it looks at organisational readiness: whether you have the people, processes and operational capability needed to run what comes next, whether that's a Network Operations Centre (NOC), a support function or something else, or whether that capability needs to be built or brought in. It's the foundation everything else builds on, so we take the time to get it right rather than rushing to recommendations.

A fact-based plan that turns the gap identified in the Readiness Review into a clear set of decisions: what to build, what to buy to get you to "base camp," and beyond that, whether to own and maintain the solution yourselves or take it as a service. Owning brings ongoing operational and support costs that are often underestimated, so we make sure those are visible and weighed properly, not discovered later. The result is a plan that cuts through the maze of complexity, the fog of overloaded, inconsistently used technology terms that makes most decisions harder than they need to be, not another layer added to it.

Execution delivers whatever mix of build, buy, own or rent the strategy calls for, through to completion. Quantum Spark doesn't sell or install the technology itself, instead we draw on a wide network of vendor and delivery relationships to bring in the right specialists for your specific needs, and oversee that delivery against the plan. The goal throughout is the one the strategy set out, ending pilot purgatory, projects that stay small, promising and permanently unscaled, and delivering the original vision, not a partial version of it.

Every engagement is different. Some organisations come to us with a clear strategy already and need help executing it, others need to start from the Readiness Review because the gap itself isn't yet understood. We'll always recommend the starting point that fits where you genuinely are, not a fixed package.

It depends on the scale of the organisation and the complexity of the gap being addressed, a Readiness Review is typically the shortest stage, while Strategy Development and Execution scale with the size of the change involved. We'll give you a realistic timeline once we understand your starting point.

Pricing depends on the scope and scale of the engagement, so it's best discussed directly rather than quoted generically here. We work flexibly, on a day rate basis or a costed project basis, whichever suits how you'd rather engage. Get in touch and we can talk through what's involved for your organisation.

Everything from the physical world through to the decisions made about it. That spans sensors and data acquisition, the connectivity that carries that data, the cloud or on-prem systems that store and process it, the AI and agentic analysis that makes sense of it, and the control layer that turns a decision back into a physical or operational action. Most organisations only ever deal with one or two parts of that chain directly, so having someone who understands how all the pieces connect is often the missing piece itself.

Before any system can decide what to do, it needs an honest, accurate picture of what's actually happening, not what a dial or a default setting assumes. That often means establishing a genuine baseline first, and being willing to question whether existing sensors are measuring the right thing at all. In our "Closing the Loop" project, an ageing 1960s office block fitted with smart heating controls, we found the sensors built into the radiator valves were being distorted by heat from nearby pipework, so independent room sensors were added to capture what people were actually experiencing, not what the valve believed. Getting this layer right is unglamorous, but everything downstream depends on it.

Data has to travel from wherever it's generated to wherever it's needed, and the right way to move it depends entirely on the situation, distance, power constraints, the volume and speed of data involved, and what's practical to install. That can mean anything from a couple of wireless basestations covering a single building, through to wide-area IoT networks covering an entire estate. Choosing the right connectivity is a technical decision, but it's also a cost and reliability one, which is why it's usually part of the strategy conversation, not an afterthought.

It depends on what the data needs, not on which option sounds more modern. Factors like latency, existing infrastructure, regulatory or data sensitivity requirements, and how the system needs to scale all weigh differently for every organisation. A hospital's constraints look different to an estate management team's, and both look different again to a product development company's, so this is very much a "what does your situation call for" decision rather than a default answer.

Sometimes significantly, sometimes not at all, which is exactly why it's worth working through properly rather than assuming. Public cloud tends to offer scale and cost flexibility, private cloud tends to offer more control and predictability, particularly around data handling and compliance. For organisations in the public sector especially, this distinction often has real weight, and getting it wrong is one of those often-underestimated costs that shows up later.

It only earns its place once there's something worth deciding on, which is why observation and a genuine baseline always come first. Done well, AI isn't a fixed rulebook applied on top of existing systems, it's given a goal and left to continuously work out how best to reach it, adjusting as conditions change rather than waiting for someone to rewrite the rules. That's the difference between standard automation and what's now called agentic AI, and it's only ever the right answer where it genuinely adds value, not by default.

This is where the loop actually closes. A system can observe and decide all it likes, but without a way to act, a valve adjusting, a schedule shifting, a workflow triggering, nothing changes in the real world. Too much building and estate technology stops at the dashboard, leaving a person to notice an alert and act on it manually. Closing that loop, so the system observes, decides and acts without waiting to be told, is usually where the real return on investment is found.

Yes. This page is kept deliberately in plain language, because it's written for the widest audience across an organisation, not just a technical one. The detail your IT team needs, architecture choices, integration specifics, protocol and platform decisions, is exactly what the Readiness Review and Strategy Development stages produce, working directly with your technical team rather than around them. Nothing here is the limit of how deep we go, it's simply not where that conversation belongs.

Probably not, at least not as a separate thing. AI works best as one option within a broader technology strategy, sitting alongside the same build, buy, own and rent decisions as everything else, not as a standalone initiative bolted on top. The more useful question is usually where AI fits into your organisation's actual goals, and that's a conversation, not an assumption.

By starting with the problem, not the technology. The Readiness Review looks at what you're actually trying to achieve, and AI is brought in only where it genuinely earns its place. Often, a simpler fix, better data, clearer processes, connectivity that actually works, delivers most of the value before AI is even needed. Where AI does make sense, we'll say so plainly, and where it doesn't, we'll say that too.

It doesn't have to. In our "Closing the Loop" project, an AI agent took over the fine-grained work of managing an office building's heating, and the change was almost invisible to staff: no new routines to learn, no jobs affected, just a building that stayed comfortable without anyone having to think about it. In applications like this, AI can remove friction quietly in the background rather than asking people to change how they work around it.

Then that's a perfectly good outcome, not a wasted process. Part of what a Readiness Review offers is clarity, and sometimes that clarity is that AI isn't where your effort or budget should go right now. We'd rather tell you that early than sell you a strategy built around it regardless.

Not necessarily. Where AI is genuinely part of the answer, our approach is to observe and understand first, then introduce change gradually rather than asking staff to change their behaviour all at once. Done well, people should notice the improvement more than the transition.

They're the four basic paths to getting a capability in place, and most technology decisions come down to some combination of them. Build means creating something bespoke for your situation. Buy means purchasing an existing product or platform outright. Own means taking on the long-term responsibility of running what you've built or bought. Rent means taking that same capability as a service, with someone else carrying the operational load. Very few strategies are purely one or the other, the right answer is usually a mix, tailored to what each part of the solution actually needs.

By weighing what matters most for that specific piece of the puzzle, cost, control, speed, and how core the capability is to what makes your organisation distinctive. Something highly specific to how you operate may be worth building or owning. Something more standard, where a mature product already exists, is rarely worth reinventing. This is exactly the kind of decision the maze of complexity, the fog of overloaded, inconsistently used technology terms, tends to obscure, so we bring a fact-based, side-by-side comparison to it rather than a default preference.

It depends on which path you take, and that's often part of the decision itself. Different build, buy, own and rent models can create very different upfront and ongoing cost profiles. Owning typically means greater upfront investment alongside the continuing cost of operating and maintaining the capability; taking something as a service can reduce that upfront requirement in exchange for an ongoing service cost. Neither is inherently better. We make those costs visible so you can weigh the options against your organisation's financial priorities, operational capability and appetite for long-term ownership.

More than most organisations expect going in, which is exactly why it's often underestimated. Owning means someone has to monitor it, maintain it, and respond when something goes wrong, often through a dedicated function like a Network Operations Centre, along with the wider support organisation, staff, processes, spare capacity, needed to keep it running properly. Those costs don't disappear because they weren't part of the original conversation, so we make sure they're visible and weighed from the outset, not discovered a year in.

It means someone else carries that operational load instead, a third party runs the NOC, handles the monitoring and support, and is accountable for keeping the service running, while you focus on the outcome rather than the infrastructure behind it. It typically trades a lower upfront cost and less internal complexity for an ongoing service relationship, which suits some organisations far better than building out an internal capability from scratch, particularly where the capability in question isn't core to what you do.

Yes, this is one of the more common starting points, not an unusual one. Often it's not that the product itself was wrong, but that the strategic decision behind it was skipped, or made before the gap was properly understood. We can help work out whether what you have can be built on, needs to be supplemented, or genuinely needs replacing, without starting from zero.

Yes, our "Closing the Loop" report covers a recent project in full. An ageing 1960s office block had a reputation for being impossible to heat properly, staff too cold some mornings, too hot by afternoon, energy bills climbing, and confidence in the heating system long gone. Rather than jumping straight to new controls, we started by observing the building as it actually behaved, then introduced an AI agent whose goal was to maintain comfort precisely when and where it was needed, not to keep every room warm all day regardless. Download the full report. It's a good illustration of how we work in practice, not just in theory.

Every project is different, so we won't promise a specific number upfront, but the office block project gives a sense of what's achievable when the approach is right. Energy use fell by around 25 percent, the capital cost was recovered within the first year against a three-year target, and manual adjustments to the heating dropped by 74 percent, not because staff were told to stop, but because the building stopped giving them a reason to intervene. What's usually more telling than any single number is that some of the strongest savings, in this case a matching drop in electricity use from portable heaters, were never part of the original brief at all.

Against the goals set out at the start, not against a generic benchmark. That's why establishing a genuine baseline is always the first step, before any new technology goes in, so we can tell how much of a result comes from the change itself rather than a mild winter or a lucky quarter. From there, we track outcomes continuously against the original targets set in the Strategy Development phase, so success is judged by whether the vision was actually delivered, not just whether something was installed.

A conversation. Get in touch and tell us the headline, rising costs, an ageing estate, pressure to "have an AI strategy," whatever's prompting the question now. You'll likely already know the problem, it's the path to solving it that's usually less clear, and that's exactly where we start. From there, we'll recommend the right starting point, usually a Readiness Review, but not always.

Most organisations already know the headline, rising costs, an ageing estate, pressure to modernise, even if the detail underneath isn't yet clear. That headline is exactly where we start. Come with your overall goal, however roughly defined, and the review itself is where we drill into it together, testing the problem statement against reality to uncover what you actually need, rather than what the initial framing assumed.

It varies by organisation, but a useful mix usually includes someone with budget or decision-making authority, and someone close to day-to-day operations, facilities, IT, or estate management, depending on the focus. Between them, that combination covers both the strategic goals and the practical reality of how things actually run, which is exactly the gap a Readiness Review is meant to close.