Senior Data Scientist, AI and Analytics

Reports to: CTO Works closely with: platform and backend engineers, customer success and operations, the BD Energy Services lead, and the executive team. The shift we are building for Four shifts are landing on EV charging operators and on us at the same time, and each of them rewrites the work a senior data person does. EV charging volume is real. Customers run fleets, depots, and forecourts where uptime, utilisation, and energy cost decide the unit economics. The dashboards they have today were built for last year’s question. Charging is an energy asset. Loads need to be visible to and steerable against dynamic tariffs, balancing markets, and local DSO signals. That requires forecasts, optimisation, and decisions that survive contact with reality. Operators want answers, not data. They are not going to write SQL against our database. They want a tool that tells them which charger is degrading, which site under-performs, why, and what to do about it. That is a product problem with a data scientist’s name on it. AI on operational data is a real thing now, when it is done with discipline. Retrieval over our own logs and documentation, fault classifiers on session telemetry, copilots that answer real operational questions: these earn their place when grounded in data we already have. They embarrass the team when bolted on for a slide. About eMabler eMabler is the EV charging software company behind an open platform used by energy companies, retailers, and parking operators across Europe. Our customers add EV charging to a service they already run: energy retail, fuel retail, grocery, parking. They use our APIs to launch a charging service in weeks as an integrated part of the user experience they offer. We just closed our Series A and are scaling our product, engineering, and data teams. Where the data is today We sit on years of charging telemetry, session records (CDRs), fault patterns, OCPP and OCPI traffic, and energy market data. The store is Azure Data Explorer (ADX), which we use heavily through KQL. Microsoft Fabric is in the picture for some downstream work. We are pragmatic about the stack: Fabric is not a religion, and if a clearly better answer shows up for a given problem we will move. The data has done useful work for support and reporting; it has not done enough work yet for the product or for the customer. Why this role exists We need a senior data person who turns the data we already have into operator-facing analytics, smart charging decisions, board-grade commercial reporting, and AI-assisted features that do real work on our own data instead of being a chat box on a marketing page. We use AI heavily in how we work. A senior here knows where AI earns its place in the product (production analytics on operator data, fault classification on telemetry, retrieval over OCPP logs and incident history) and where it does not, and ships accordingly. What you will own Four areas, roughly equal weight at the start, with the mix shifting as the company learns what pays. Charging analytics for operators. Session quality, utilisation, fault patterns, uptime, segment behaviour. Both customer-facing (inside our product, in the operator’s hands) and internal (for support, success, ops). The first wins are unglamorous and high-value: showing an operator why their utilisation is half of what their previous dashboard claimed. Energy Management, Forecast site-level load, optimise schedules against dynamic tariffs and DSO constraints, and support the energy services we are building with the BD team. Work with platform engineers so models run in production, not in a notebook on your laptop. AI on our own data. Specialise models for our domain. Fault classification on charge-session telemetry, retrieval over OCPP message logs and incident history, operator-facing copilots that answer real operational questions, and the evals to know they actually work. This is not a generic LLM-on-everything project. It is making AI useful on data we already have. Commercial and product analytics. Pricing, churn, funnel, and KPI reporting for the exec team and the board. Smaller datasets, more politics, same engineering rigor as the rest. Who you are Five to eight years working with real data in production. IoT, energy, mobility, telematics, or other high-volume telemetry domains preferred. Comfortable with at least one streaming or telemetry stack (Azure Event Hubs, Kafka, Kinesis, or similar) and at least one analytical store. Hands-on with Azure Data Explorer (ADX) and KQL is a strong plus; experience with Microsoft Fabric, Databricks, Snowflake, or BigQuery is recognisable currency. Deep familiarity with modern AI systems for production analytics, including LLMs where they fit, but also the broader toolkit: forecasting, anomaly detection, classification, optimisation, ranking, and other model types that matter in real products. You see how these translate into revenue, margin, retention, and strategic advantage. You know how to turn AI from a slide into a commercial asset: choosing the right approach for the problem, focusing on use cases that create measurable value, keeping outputs grounded and reliable, and making disciplined calls on where AI genuinely improves the economics of the product. You use AI as a default, not a side experiment. Experience with Cursor, Claude Code, Copilot, or similar helps; judgment matters more. You look for where AI multiplies what one person can deliver, and you raise the bar on review and code quality to match. Working English required. Helsinki HQ preferred, regular on-site presence expected. Bonus, not required EV charging domain: OCPP 1.6 and 2.0.1, OCPI, CDRs, roaming, eMSP/CPO mechanics. Energy markets: Nord Pool, balancing (FCR, aFRR, mFRR), local flexibility, dynamic tariffs, DSO interfaces. Hands-on customising or fine-tuning models for a specific domain, not just calling an API. Experience inside an early-stage B2B SaaS where the team is small and the stakes are real. dbt, DuckDB, or other tools that keep analytics engineering honest.