Skip to main content

In active developmentSolaDesk is not yet generally available

SolaDeskService operations
Menu

Service operations platform

The solar is installed. Who owns what happens next?

SolaDesk is a service desk for solar and battery portfolios. It is designed to take the alerts, faults, questions and follow-ups that arrive after commissioning and turn them into owned, auditable work with a name against it.

Designed in South Africa, for the way South African portfolios are actually supported.

Talk to us about a pilotSee how it works
Portfolio care
For portfolio managers who own or manage residential and C&I fleets
Direct residential care
For individual system owners with no portfolio manager behind them
Staging interface, synthetic dataCare Command - the operating day
The SolaDesk Care Command screen: a staging banner, a sidebar listing Care Command, Health Audits, Cases, Customers, Sites and Assets, Visits, Journeys, Opportunities, Partners, Quality and Reports; the state of today's portfolio health audit; counters for findings awaiting review, open cases and visits scheduled; and panels for today's care plan and lifecycle check-ins.
Screens shown on this page are the SolaDesk console running on its protected staging deployment. Every partner, site, customer and case in them is synthetic test data created for validation. They are not customers and the data is not real.

Commissioning is the beginning of the service problem, not the end of it

A portfolio that is installed and monitored still generates a continuous stream of service work. Without somewhere for that work to live, these are the failure modes it falls into.

  • An alert fires, and nobody in particular owns it

    Monitoring platforms are good at detecting. Detection is not ownership. An alert that appears on a dashboard nobody is accountable for is an alert that ages quietly.

  • Support scatters across WhatsApp, phone calls and inboxes

    When the conversation that resolved a fault happened in a thread on somebody's phone, there is no record of it - so it cannot be reviewed, measured or handed over.

  • Underperformance can stay invisible until somebody complains

    Monitoring can flag a fault, but a system producing steadily less than it should may not trip any alarm at all - and if nobody is reviewing it, the customer's bill is what raises it.

  • No single answer to who owns it, or what was promised

    Without a case record there is no owner, no severity, no due time and no history of what was already attempted. Every enquiry restarts from zero.

A service operation, not another dashboard

SolaDesk is built around the way a service desk runs: a daily sweep that finds what needs attention, a case that carries ownership, and a record of every contact made along the way. What follows describes the staging console as it behaves today.

  1. Start from coverage, not from a green tick

    A daily health audit reports how many sites in a portfolio were actually assessed and how many could not be - the gaps are the point. A summary that shows nothing wrong because it looked at nothing is worse than no summary.

  2. One case, one owner, one due time

    In the staging console every piece of work becomes a case with a reference, a severity, an assigned owner, a due time and a record of the attempts already made to reach the customer.

  3. Contact that is earned, not assumed

    Customer identity stays masked until the agent is verified for that specific case - the staging console enforces this today. Outbound contact is gated on recorded consent and staffed hours, and no channel is connected, so nothing is sent at all yet.

  4. Coordination with the people who do the work

    Installers and field teams are partners in the workflow, with their own scoped view. SolaDesk does not replace the installer relationship - it gives it a shared record.

Staging interface, synthetic dataHealth Audits - coverage and gaps, per portfolio, per day
The Health Audits screen: one row per portfolio for the operating day. BrightPeak Energy shows 12 of 12 sites assessed with no gaps, Karoo Solar Installers 4 of 4 with no gaps, and Ubuntu Energy Services 12 of 14 with 2 gaps. Each row names the data source and links to its findings.
Screens shown on this page are the SolaDesk console running on its protected staging deployment. Every partner, site, customer and case in them is synthetic test data created for validation. They are not customers and the data is not real.

Two service mandates, deliberately kept separate

The same service operation supports two completely different relationships. Merging them would mean guessing who the customer is, and that is a mistake you cannot undo later.

Business to business

Running on staging

Portfolio care

For portfolio managers who own or manage residential and C&I fleets

The service relationship is with the portfolio manager. SolaDesk works across the sites they manage under an explicit mandate, and the portfolio manager stays the party who holds the end-customer relationship.

  • Mandate-scoped access - an agent sees only the portfolios they are mandated for
  • A partner view of case progress, without exposing other portfolios
  • Reporting written for somebody who has to answer for the fleet

Direct to customer

Designed, not built

Direct residential care

For individual system owners with no portfolio manager behind them

A homeowner whose installer has moved on has nobody to call. This mandate is designed to give that owner a direct service relationship - a real case, a real owner and a real answer - rather than a monitoring app and silence.

  • A direct service account, not a seat inside somebody else's fleet
  • Designed for owners whose systems report through SyncApp
  • Being built now - not yet open to sign up

Why this separation matters

A standalone residential customer is not a portfolio manager's customer merely because both systems report into the same energy platform, and there is no workflow that moves a customer from one to the other. Sharing infrastructure does not merge a commercial relationship. SolaDesk treats the two as separate mandates because they are separate businesses.

How it works

How a piece of service work travels

Six stages, each one a place where the work has a defined state and a named owner. This is the designed path; stages two to six run in the staging console today, on synthetic data.

  1. Operating context arrives

    In the designed workflow, site, asset and alert context reaches SolaDesk from the energy platform through a governed read interface - never by reaching into its database or by copying telemetry streams. That interface is not connected yet; on staging the context comes from a deterministic demo source.

  2. Triage

    The daily audit and incoming occurrences are assessed for severity and coverage. Findings that need action become cases; gaps in coverage are reported as gaps.

  3. Case ownership

    A case is opened with a reference, a severity, an owner and a due time. From this point there is always an answer to “who has this?”

  4. Diagnose, escalate or dispatch

    Guided diagnostics first. If the answer is not remote, the case escalates to a partner or becomes a scheduled site visit with the context already attached.

  5. Engage the customer

    Contact is made against recorded consent, inside staffed hours, by an agent verified for that case. Every interaction lands on the case timeline.

  6. Close and report

    Closure records an outcome and the effort it took. Quality review samples the work, and reporting answers to whoever holds the mandate.

What is built

Running on staging

These eleven surfaces make up the SolaDesk console today, on a protected staging deployment with synthetic data. They are the console's actual navigation, not a roadmap - and the three screens shown on this page are captures of it. Depth varies between surfaces.

  • Care Command

    The operating day in one view: whether the audit has run, what is awaiting review, what is open and overdue, and what is due next.

  • Health Audits

    A daily sweep per portfolio, idempotent per partner and operating day, reporting sites assessed, coverage gaps and the findings raised.

  • Cases

    The unit of accountable work: reference, severity, owner, due time, timeline, evidence and outcome.

  • Customers

    Service context for the customer behind a case, with identity masked until the agent is verified for it.

  • Sites & Assets

    The site, its installed assets and their commissioning history, as service context rather than as a telemetry feed.

  • Visits

    Scheduled field work, with the case context and the reason for the visit attached to it.

  • Journeys

    Lifecycle follow-up - the scheduled check-ins that stop a new installation from going quiet after week one.

  • Opportunities

    Service-led opportunities recorded under explicit approval gates, so a service conversation cannot quietly become a sales pipeline.

  • Partners

    Installers and delivery partners, with a scoped projection that shows them their work without exposing anyone else's.

  • Quality

    Review and sampling of closed work, so service quality is measured rather than assumed.

  • Reports

    Reporting for the party that holds the mandate, built from the service record.

Evidence is a snapshot, never a stream

When a case needs proof of what a system was doing, SolaDesk captures a bounded point-in-time snapshot and keeps it with the case. It never duplicates the telemetry stream itself. The energy platform stays the authority on what the equipment did; SolaDesk stays the authority on what the service operation did about it.

Staging interface, synthetic dataWhat a partner sees - identity withheld until verification
A case as a delivery partner sees it. The case reference, severity, status, due time and timeline are visible, together with the site and its installed assets. The customer panel is marked 'Unverified - details masked': the name reads 'Customer details withheld', the phone number and email address are replaced by dots, and the language is withheld.
Screens shown on this page are the SolaDesk console running on its protected staging deployment. Every partner, site, customer and case in them is synthetic test data created for validation. They are not customers and the data is not real.

Two systems of record, one boundary between them

SolaDesk is a service platform that reads energy context. It is not a monitoring product wearing a service label, and the line between the two is drawn on purpose.

Energy system of record

GridSync

  • Sites, assets and devices
  • Telemetry and time-series energy data
  • Health rules, analytics and alerts
  • Any command sent to a device

Governed boundary

Read-only operational context for a site

Durable alert-occurrence events

Stable source identifiers, with freshness and provenance

Service system of record

SolaDesk

  • Service partners, mandates and direct accounts
  • Cases, queues, evidence and outcomes
  • Consent, verification and every interaction
  • Visits, escalations, quality and reporting

What the boundary does not allow

  • A shared database between the two platforms
  • Copying raw telemetry streams into SolaDesk
  • SolaDesk sending any command to any device
  • Treating an energy-platform organisation as a service mandate by default
A simplified view of one part of the ratified architecture: the interface between the energy platform and the service platform. It omits the other client applications, the operator personas and the device and provider layers, which are not what this page is about.

Where this actually stands today

Integration not connected

The interface described above is designed and ratified, and it is not connected yet. The console currently runs against a deterministic demo source, and if it is pointed at a live source without credentials it fails closed rather than pretending to have data. When the integration is built, this page will say so and will say when.

Designed for people, not for an auto-reply

Software routes the work; people resolve it. SolaDesk is being built for a staffed desk with agents, service leads and quality review rather than for an automated reply that closes the ticket. No desk is operating yet - these are the roles the product is designed around.

Planned contact channels

The service model is designed around three provider channels. None of them is connected today, and the product does not send or receive a single real message.

  • Virtual PBXInbound and outbound voice for the service deskPlanned
  • WhatsAppA planned customer messaging channelPlanned
  • EmailWritten confirmation and reportingPlanned

The roles it is designed around

  • Service agents

    Would own cases, run diagnostics and contact customers

  • Service leads

    Would hold the queue and approve escalations and gated transitions

  • Quality

    Would sample closed work and report on how the desk is performing

Pilot and partnership

Looking for the first pilot portfolios

No pilot has started yet. If you manage a fleet whose service workload has outgrown a spreadsheet and a WhatsApp group, or you install and maintain systems and want a shared record with whoever holds the mandate, this is the right moment to talk.

Worth a conversation if

  • You manage residential or C&I sites and the service load is growing faster than the team
  • You install and maintain systems and want coordination rather than another portal
  • You need to show somebody what was done, when, and by whom

Not yet, honestly

  • You need a live integration to your monitoring platform today
  • You need a contractual response-time commitment
  • You are a homeowner looking to sign up right now - direct residential care is still being built

The contact route is not published yet

SolaDesk has not published a public contact address, and this site will not invent one. There is deliberately no form here: a form that cannot deliver anything is worse than no form. The route will appear here once it is approved.

Straight answers

Can I use SolaDesk today?
No. It runs on a protected staging deployment with synthetic data and has no production release. No pilot has started and there is nothing to sign up to yet - what exists now is a conversation.
Is this a monitoring platform?
No, and it is not trying to become one. Monitoring detects; SolaDesk owns what happens after detection. The energy platform stays the system of record for telemetry, health rules and alerts.
Is the GridSync integration live?
No. The read interface and the alert-occurrence contract are designed and ratified, but not connected. The console runs on a deterministic demo source, and live mode fails closed instead of inventing data.
Does SolaDesk control my inverter or battery?
No, by design and not by omission. Device commands belong to the energy platform's control plane. SolaDesk has no path to a device, and the architecture prohibits one.
Will you contact my customers?
Only under an explicit mandate, against recorded consent, inside staffed hours, and by an agent verified for that specific case. Customer identity is masked until that verification exists. Today no real message is sent at all - no channel is connected.
Do you replace my installer?
No. Installers and O&M providers are partners in the workflow with their own scoped view. The point is a shared record, not a substitution.
How does this handle POPIA?
Consent, purpose limitation and data minimisation are built into the product rather than promised in a policy: an append-only consent record, identity masking until verification, and structural redaction of personal data in logs. Calling that “compliant” would be a legal conclusion nobody has signed off, so we do not.
What does it cost?
There is no price yet. Pilot terms will be agreed with the first portfolios rather than published as a tariff we cannot stand behind.
Who is behind it?
SolaDesk is built by the team behind GridSync, the energy platform it reads from. They are separate products with separate users, separate authorisation and separate systems of record - which is exactly why the boundary between them is written down.
Does this website track me?
This site sets no cookies, loads no third-party scripts, and runs no analytics or advertising. There is no form to submit, so it asks you for nothing. Our hosting provider does process ordinary technical request data - the IP address, the time, the page and the browser string - because that is how a page gets delivered and protected from abuse. It is not used to profile you.