This interview is with Fabio Lauria, CEO & Founder, ELECTE.
To kick us off, how would you describe your expertise as a CEO & Founder in financial services and the mission of ELECTE to a business leader evaluating data analytics solutions?
I founded ELECTE in 2023 after scaling Lauria Impianti, a construction and HVAC business. Between that and running ELECTE across multiple jurisdictions, I’ve spent years on the operator side of finance—dealing directly with banks, tax authorities, and financial institutions, where a number either holds up under scrutiny or it doesn’t. This isn’t theoretical exposure; it’s the environment where I learned what a report must do to be trusted.
That perspective is ELECTE’s thesis. Most businesses don’t lack data; they lack the time and staff to turn it into something a decision-maker—or an auditor, or a lender—can act on. ELECTE is a platform that automatically analyzes data and creates visual reports, collapsing the gap between raw numbers and the one figure that changes a decision.
For a leader evaluating analytics solutions, the question isn’t “How sophisticated is the model?” It’s “How fast does this become a decision I can defend?” That’s the bar we build to. Over 80% of our revenue comes from clients outside our home market, which forces the product to stay legible across languages, industries, and reporting standards rather than tuned to one.
My own view, which shapes the roadmap: AI is compressing everyone’s output toward the same competent-but-generic median. The edge was never in the code—it was in knowing what to build with it. ELECTE is built so the leader keeps that judgment and offloads the production.
What key experiences in financial services and startups most shaped your path to founding ELECTE and your philosophy on data‑driven decision‑making?
Two experiences shaped it more than any others.
The first was years in construction and HVAC before ELECTE — a margin-thin, cash-flow-sensitive world where the financial decisions were concrete and consequential. Debt restructuring. Weighing different sources of debt against each other. Evaluating whether an early-payment discount beat the cash-flow value of a payment extension. Working to improve the company’s credit rating. Each of those had to survive scrutiny from banks and financial institutions, and you learn quickly that a number is only as good as your ability to defend it — and that most decisions fail not because of bad data but because data nobody had time to turn into something actionable. That’s where my instinct for decision-first analytics comes from. Not “what can we measure,” but “what will this change.”
The second was building ELECTE across multiple jurisdictions from 2023 onward. Running an entity structure that spans several countries means dealing constantly with different authorities, reporting standards, and financial systems that don’t agree with each other. It forced a discipline: data has to stay legible when it crosses a border, a language, or an audit. That constraint is now built into the product.
On philosophy, both experiences pushed me to the same conclusion. The value was never in generating more analysis — anyone can do that now, and AI is flattening everyone’s output toward the same competent median. The value is in judgment: knowing which figure matters and why. Competence was never in the code; it was in knowing what to build with it. ELECTE exists to hand the leader that judgment and take the production work off their plate.
When you walk into a small business with fragmented CRMs and spreadsheets, what is the first 90‑minute data quality audit you run to uncover issues that derail analytics?
I don’t start with the data. I start with the decisions. The first fifteen minutes are spent asking one question several ways: What are the three numbers you actually run this business on? Revenue by customer, pipeline, cash position—whatever they name. Everything I audit after that is measured against whether those three numbers can be trusted. An audit with no decision attached just produces a list of problems nobody has time to fix.
Then, roughly how the ninety minutes break down:
-
The next twenty minutes address the join problem. Fragmented CRMs and spreadsheets always fail at the same place—there’s no shared key. The same customer is “Acme S.r.l.” in one system, “Acme Srl” in another, and a misspelled email in a third. I check whether any reliable identifier exists across sources. Usually it doesn’t, and that single fact explains most of why their reporting has never reconciled.
-
The next twenty focus on duplicates and freshness. How many records are stale, orphaned, or duplicated? I don’t count them exhaustively—I sample. I pull fifty records and check them by hand. A 30% error rate in a sample tells you more, faster, than a perfect audit of one table.
-
Fifteen minutes are spent on the numbers that should tie and don’t. I compare total revenue in the CRM, the accounting export, and the spreadsheet the owner actually trusts. When three sources give three answers, the gap between them is the real finding—and which one they instinctively believe tells you where the shadow system lives.
-
Ten minutes on definitions. What counts as a “customer”? Does “closed” mean signed, invoiced, or paid? Half of all analytics failures aren’t data errors at all—they’re two people using the same word for different things.
-
I spend the last ten minutes writing down what’s load-bearing versus what’s noise. Not every problem is worth fixing. The output isn’t a hundred-line defect report—it’s a one-page answer to the question: ‘Can we trust the three numbers, yes or no, and what’s the single fix that moves the needle most?’
The thing I’ve learned: the technical mess is rarely the real blocker. It’s that no one has decided what the data is for. Fix that, and most of the cleanup prioritises itself.
After that foundation is fixed, how do you choose the single predictive use case to take to production first so it delivers quick, defensible ROI?
I pick the use case the business would act on even without me. That’s the whole filter. If the predicted outcome doesn’t change a decision someone is already responsible for making, it’s a demo, not a use case — and demos don’t survive contact with a P&L.
Concretely, I score candidates on four things.
First, is the decision already being made, repeatedly, by hand? Churn calls; which invoices to chase first; which leads a small sales team should phone this week. Recurring manual decisions are where a prediction has somewhere to land. A brilliant forecast for a decision made once a year is worthless this quarter.
Second, is the outcome measurable within weeks, not quarters? Defensible ROI means the business can see the model was right or wrong before anyone’s enthusiasm runs out. I’d rather ship a merely good model on a fast feedback loop than a great one whose payoff can’t be observed until next year.
Third, do we already have the data — cleaned in the foundation work — or does this use case need a new pipeline first? The first to production should never be the one that requires six weeks of new plumbing. That’s the second project, once trust is banked.
Fourth, what does being wrong cost? For the first use case I deliberately want an asymmetric one — where a wrong prediction is cheap and a right one is valuable. Prioritising which overdue accounts to call is forgiving; you lose a phone call. Anything where a false positive triggers an irreversible action waits until the team trusts the system.
The candidate that scores well on all four is almost always something unglamorous — collections prioritisation, churn flags, restock timing. That’s the point. The first production use case isn’t there to be impressive. It’s there to be right, fast, and in front of someone who can act on it, so the ROI is undeniable and the second, more ambitious project gets funded on trust rather than faith.
The competence was never in the model. It’s in choosing the one decision where a model earns its place.
Which one KPI do you ask leadership to track weekly to confirm automated reports are improving decision quality—not just speed—and why that one?
The percentage of decisions that changed because of the report. One number, tracked weekly: of the recurring decisions this report feeds, how many did the recommendation actually alter versus merely rubber-stamping what would have happened?
Here’s why that one, and not the obvious alternatives: Speed metrics — time-to-report, hours saved — increase the moment you automate anything, so they confirm the machine runs, not that it helps. Adoption metrics like open rate are worse: a report everyone opens and no one acts on is a very efficient way to produce nothing. Both feel like progress and measure nothing.
“Decisions changed” is the only weekly number that can’t be gamed by faster production. If the automated report keeps telling leadership what they already would have done, it’s a mirror — fast, clean, and useless. When it starts surfacing the overdue account they’d have missed, the churn risk they’d have dismissed, the reorder they’d have delayed — that shows up as a decision that went differently than it would have unaided. That’s decision quality, defined operationally rather than as a feeling.
There is a second reason I like it at a weekly cadence. It’s self-correcting. A change rate near zero means the report is redundant — kill it or sharpen it. A change rate that’s very high early on is a flag too: either the prior process was badly broken, or the model is overconfident and leadership is deferring to it without scrutiny. The healthy range is a report that changes the call often enough to earn its place, and gets challenged when it does. Tracking it weekly keeps that honest, because you can watch it move against outcomes you’ll see within the month.
The deeper point: you can’t automate your way to better decisions, only faster ones. The gain in quality comes from whether the report changes what a human decides. So measure that directly, and let speed be the thing you already got for free.
Can you share a specific example where predictive analysis changed a sales, marketing, or pricing decision and directly drove measurable business growth?
A B2B distributor we worked with was losing customers at roughly 18% a year and treating it as a cost of doing business. Their assumption — a reasonable one — was that churn was mostly price: someone always undercuts you. So retention effort, what little there was, went into discounts.
The data said otherwise. When we built a churn model on their order history, the strongest signals weren’t price at all. They were behavioral and early: lengthening gaps between orders, a drop in order-line variety, and a support ticket that went quiet instead of being resolved. Customers signaled they were leaving weeks before they actually left — and well before anyone in sales noticed.
That changed the decision. Instead of blanket discounting to defend against a price threat that was mostly imagined, the sales team got a weekly ranked list: these accounts are showing pre-churn behavior — call them now. Not a discount — a phone call from a rep while the relationship was still recoverable. Cheap intervention, precise targeting.
Churn dropped from about 18% to about 11% over two quarters. For a distributor running on repeat volume, that’s not a marketing number — it’s compounding revenue that simply stopped leaking. And critically, it cost less than the discounting strategy it replaced, because they stopped giving margin away to customers who were never going to leave.
The lesson I take from it is this: the value wasn’t the model’s sophistication. It was that it moved the decision earlier — from “win back the customer who already quit” to “call the one who’s about to.” The prediction was only useful because it landed in front of someone who could act on it while there was still time to act.
How do you design automated reporting so executives, finance, and sales each trust the outputs without creating competing ‘sources of truth’?
The mistake almost everyone makes is building three reports for three audiences. That’s how you manufacture competing sources of truth: the moment finance and sales each have “their” dashboard, any disagreement becomes a fight about whose numbers are right instead of what to do. I design the opposite way — one source, three views.
Concretely, that means the numbers are computed once, in one place, against one set of definitions. What varies by audience is the presentation, never the calculation. Sales sees pipeline and account-level detail. Finance sees the same revenue rolled up with margin and cash timing. The executive sees the three figures that matter and nothing else. But if sales sums their view and finance sums theirs, the totals reconcile—because underneath, it’s the same number filtered differently, not three numbers computed separately.
The hard part isn’t technical; it’s definitional. Most “competing truth” problems are actually vocabulary problems: sales counts a deal as closed when it’s signed, finance when it’s invoiced, and the CEO when cash lands. All three are right; they’re answering different questions with the same word. So before any report ships, I get those definitions written down and agreed upon — what “customer,” “closed,” “active,” and “revenue” mean, once, in plain language. That document does more for trust than any visualization.
Then two things make the trust durable. First, every number is traceable — an executive can click revenue and see which records and which rule produced it. Trust doesn’t come from a clean chart; it comes from being able to check it and finding it holds. Second, the definitions are visible in the report itself, so no one has to remember or assume. When finance and sales see a figure, they also see it was computed the same way for both.
The result is that disagreements move up a level — from “your numbers are wrong” to “we’re looking at the same number and I’d decide differently.” That second argument is productive. The first one is just friction, and it’s entirely avoidable if you refuse to let each function own its own arithmetic.
Working in a regulated environment, what concrete practices have you implemented to keep analytics GDPR‑compliant while still accessible to non‑technical teams?
The tension in the question is real: GDPR pushes toward locking data down, while accessibility pushes toward opening it up. I don’t treat those as opposites. Most of the conflict disappears once you stop assuming that useful analytics requires holding everyone’s personal data.
Three practices carry most of the weight.
-
Data residency in Europe. Where data physically sits is the compliance question people underestimate, so we removed the ambiguity — data stays in Europe rather than scattering across regions with different rules and transfer mechanisms. That single architectural choice eliminates a whole category of cross-border transfer problems before they start.
-
Minimization as a default, not a policy. We ask for the least data possible to do the job. Analytics rarely needs personal identifiers — it needs patterns. A sales leader looking at churn risk by segment doesn’t need names to act on the trend; they need names only when contacting a specific account. So non-technical teams get full access to the analysis without ever handling raw personal data, because the analysis genuinely doesn’t require it. The less you collect, the smaller the surface you have to protect and the less there is to get wrong.
-
Transience wherever possible. Data is processed in transit and not stored when it doesn’t need to be. The safest personal data is the record you never kept — it can’t leak, can’t be subpoenaed, and can’t be retained past its purpose, because it isn’t sitting anywhere. Where persistence isn’t necessary for the analysis, we don’t persist.
The throughline is the same across all three: compliance and accessibility only conflict if you assume everyone needs the raw personal record. They mostly don’t. Keep the data in Europe, collect as little as the job allows, and hold it only as long as the work requires — and the analytics stays open to the people who need it while the personal data itself is barely ever exposed.
For founders and operators building their analytics stack today, what build‑versus‑buy rule of thumb has saved you the most time and money at ELECTE?
My rule is one line: build what your customer pays you for, buy everything else — and be honest about which is which.
The trap founders fall into is building the undifferentiated middle. Nobody chooses you because you wrote your own email-sending infrastructure, your own auth, or your own data-pipeline plumbing. Those are solved problems with mature, cheap providers, and every week you spend rebuilding one is a week you didn’t spend on the thing that’s actually yours. I’ve watched more runway die to “we’ll just build it ourselves; it’s not that complex” than to almost anything else. It’s always more complex than it looks, and the cost isn’t the build — it’s the maintenance you signed up for in perpetuity.
So the test I apply is blunt: if this component were to work perfectly and invisibly, would a customer ever know or care? If the answer is no, buy it. Email delivery, payments, hosting, translation, the boring infrastructure — buy, and route your engineering attention to where a customer would actually feel the difference. We build the analytical core — the thing a customer is paying ELECTE specifically to do, the way data becomes a decision — because that’s the only place where building creates something someone would switch providers to get.
There’s a second-order version of the rule that’s saved as much as the first: buy doesn’t mean marry. I favor bought components that are replaceable — where the provider sits behind a thin interface I control, so if the pricing turns hostile or the product decays, I can swap it without rewriting the business. You get the speed of buying without the lock-in that makes buying feel dangerous. The mistake isn’t buying; it’s buying something you can’t leave.
The uncomfortable part of the rule is that it forces honesty about what you’re actually differentiated on. A lot of ‘we have to build this’ is really ‘we enjoy building this’ or ‘we’re afraid we’re not special enough to just buy the rest.’ Founders who answer that question honestly ship faster and spend less, because they stop pouring scarce time into the parts no customer will ever thank them for.
Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?
One thing, because it runs through everything I’ve said.
The reason I keep coming back to “does this change a decision” is that the industry is drifting the other way. AI has made analysis cheap and infinite — anyone can generate a dashboard, a forecast, or a report in seconds. The predictable result is that everyone’s output is converging on the same competent, generic median. More analysis than ever, less consequence than ever.
That’s the trap I’d warn any operator about. The scarce thing was never the production of analysis — it’s the judgment to know which number matters and the discipline to act on it while it still counts. Tools don’t supply that. They can only offload the work around it so the judgment has room to operate.
So if I’ve got one message for a leader evaluating analytics solutions, it’s this: don’t buy something that makes you faster at producing reports. Buy — or build — something that makes you better at deciding. The competence was never in the code. It was in knowing what to build with it. Everything at ELECTE follows from that one line.