Enpal Customer Portal — Self-service for the whole solar journey
Enpal makes solar power accessible by renting out full installations to German households. I designed their first customer-facing monitoring app — turning raw inverter data into a calm, legible daily companion that shows families what their roof is actually doing.
Role
Product design, user research
Timeline
2024 — 2026
Scope
Web portal (responsive), research operations
The context
The portal's vision rests on three pillars: process transparency, self-service, and proactive communication. The business case is simple — every question a customer can answer themselves is a call that Customer Service doesn't take. Our stakeholder research showed that around 20% of all incoming service calls were follow-up calls: customers asking about the status of something already in progress, simply because they had no way to see it themselves.
To keep the team close to real customers, I set up continuous user research together with our product manager: bi-weekly interviews with portal users, recruited through surveys and customer service, documented in Dovetail and shared with stakeholders across the fulfilment domain. Almost every decision below traces back to something we heard in these sessions.
01 — Dashboard
A home page that knows where you are in your journey
The portal had grown feature by feature — installation overview, financial overview, documents, energy data. The home page was a static grid of tiles that treated a customer on installation day the same as one who finished two years ago. Users told us they opened the portal with one question in mind ("what's happening with my installation?", "when is my next payment?") and had to find the answer themselves.
Process. We started by mapping what customers actually need at each stage of their lifecycle, based on interview data and support-call topics. Two clear segments emerged: customers in the installation process, and customers after it. Their needs barely overlap. From there we defined three design principles that guided every layout decision:
Scannability — a customer should understand their current status within seconds
Action-orientation — always make clear what (if anything) they need to do next
Personalization — content adapts to the customer's segment and products
For customers in installation, the dashboard leads with a progress tracker, open action items (document uploads, upcoming appointments) and recent updates. For customers with completed installations, it shifts to finances — next payment, loan balance — plus new documents and notifications. Everything reuses data that already exists in the portal's detail pages; the dashboard is a smart summary, not a new data source.
Outcome. The dashboard turned the portal from a menu into an answer. Time-to-information dropped, and it became the foundation for the portal's personalization logic as new products (heat pump, energy tariff) joined the platform.
02 — Damages
Reporting installation damage without picking up the phone
Installing a solar system means scaffolding, drilling and roof work — sometimes things get damaged. These were the unhappiest customers we had: the 6-week CSAT for damage-affected customers sat at 3.1, and reporting a damage meant writing emails or calling, then waiting in the dark. Damage payments alone made up around 14% of the accounting team's yearly cases, all handled manually.
Process. Instead of designing one big feature, we phased the delivery to reduce risk and shorten feedback loops:
Phase 0 — Discovery. Together with the data team we validated the real structure and quality of existing damage cases before designing anything. Throwaway work, on purpose — it defined the data model we could actually rely on.
Phase 1 — Visibility (read). Customers see a list of all their reported damages: type, status, reported and updated dates, with a detail view showing the full description and photos. Just seeing "we're working on it" removes the biggest reason to call.
Phase 2 — Reporting (write). A guided form to report a new damage — description, date, location, photo uploads — that creates a complete, pre-validated case directly in Salesforce.
Designing the form, the main tension was completeness vs. effort: Customer Care needs high-quality cases, but a frustrated customer with a broken roof tile has no patience for a long form. We kept required fields minimal, made photo upload the hero of the flow, and wrote status labels in plain language instead of internal case jargon (a customer shouldn't need to understand Salesforce states).
Outcome. A transparent, self-service channel for the most emotionally charged moment in the customer journey — targeting a CSAT lift from 3.1 to 3.4, fewer follow-up calls, and cleaner cases for the operations teams. The phased setup lets each release inform the next.
03 — Document Filtering
Finding one document among many
The document space started simple: three categories synced from SharePoint, plus general handbooks. Then the portfolio grew. Heat pump customers arrived with their own document types, the grid registration upload added a "My Documents" section, and loan customers accumulated invoices, payment schedules and annual statements. What used to be a short list became a pile — and our usability tests showed users scrolling and scanning instead of finding.
Process. The signals came from several directions: usability test participants disagreed on whether "new" or "all" documents should come first, asked for alphabetical ordering, and struggled with the search field's low contrast. In interviews, one of our standard questions was "have you ever looked for something in the portal and not found it?" — documents came up constantly.
We reframed the problem: the categories weren't wrong, they were just no longer enough as the only navigation. The solution layered filtering on top of the existing structure — filter by product (PV / heat pump / energy), by category, and by date, combined with an improved search. Filters had to work together with the category logic already in place, and stay meaningful for the simplest case: a PV-only customer with five documents shouldn't see a wall of filter chips they don't need. So filters appear progressively, based on what a customer actually has.
Outcome. Customers with complex product setups can now narrow dozens of documents to the right one in a couple of taps, while simple accounts stay simple. Document-related support requests — one of the original reasons the document space existed — kept trending down as the portfolio expanded.
Reflection
Three projects, one pattern: every feature earns its place by removing a reason to contact support. Working within the portal's continuous research cadence — rather than doing research per-project — meant we rarely started from assumptions alone. The insights that shaped the dashboard came from damage interviews; the document filtering signals came from tests focused on payments. That is the quiet advantage of always-on research: the next problem introduces itself before you go looking for it.