An administrator follows the saved screenshot. The portal now asks a different question, but the procedure has no owner and nobody knows when it was last checked. The team solves the immediate problem in a chat message, leaving the next person to encounter it again.
A useful solar operations playbook gives people a repeatable way to complete work and a clear route when the instructions no longer fit. Its value depends on maintenance as much as the initial writing.
Start with a few frequently used procedures: sales handover, document collection, customer updates and internal close-out. The structure below is a suggested management approach, not an official compliance manual. Your responsible professionals still need to determine the requirements that apply to each job.
Give every procedure a usable identity
Create a short cover record for each standard operating procedure, or SOP. A reader should be able to establish whether the procedure applies before following its first step.
| Field | What to record |
|---|---|
| Procedure ID and purpose | A stable reference and the outcome it supports |
| Scope | Job type, program, state and network area where relevant |
| Process owner and backup | People responsible for resolving questions and maintaining the procedure |
| Required reviewer | The person authorised to assess technical or other specialist changes |
| Version and effective date | Which issue is in use and when its instructions apply |
| Sources | Links to current official guidance and relevant manufacturer instructions |
| Last review and next review | When the procedure was checked and when it will be checked again |
| Change history | What changed, why and who authorised the release |
Keep the scope concrete. “Solar applications” is too broad when the steps differ by distributor or technology. A procedure can instead identify a particular process and direct other cases to the appropriate owner.
Distinguish the internal effective date from an external rule's commencement date. An internal release cannot delay a requirement that already applies. If a change has transition provisions, have the responsible person decide which jobs fall within them.
Write around decisions and evidence
For each step, state what starts it, which source the worker uses, what they do and what evidence demonstrates completion. Add the condition that sends the task for review.
For example, a document-collection step might begin when the installation record arrives. The administrator checks the agreed document list, records missing items and routes the file to its reviewer. The procedure should identify where the completed check and outstanding questions are stored.
Avoid a single instruction such as “finish the STC pack”. CER requires the necessary documents to be completed and signed before STCs are created. The internal procedure should make that checkpoint visible and identify the person responsible for verifying readiness. CER: creating small-scale technology certificates.
Use screenshots to support the explanation, with a capture date and the relevant portal context. Remove real customer information from training examples. A screenshot shows where a field was located; it cannot explain every decision or prove that today's requirements are unchanged.
Link to the authority behind the instruction
Maintain a small source register alongside the playbook. Record the authority, page or document, version where provided, scope and the internal procedures that depend on it. This makes a source change easier to trace through your instructions.
SAA publishes its accreditation requirements and policies through its scheme administration page. Use that current entry point when checking which technical document is published, rather than relying only on an old attachment in a shared folder. SAA: scheme administration.
Some workflows depend on an ordered sequence, not just a list of completed fields. For SA Power Networks Flexible Exports, device registration is part of the manufacturer's commissioning process, and registration is needed before the capability test can be completed. Portal close-out is a separate step. A procedure should preserve those dependencies and direct technical work to the responsible installer. SA Power Networks: installer checklist.
That example is specific to the stated network process. Do not copy its portal instructions into another distributor's procedure. Our flexible exports admin tracker shows how administrative support can organise the associated records.
Turn a reported mismatch into a controlled update
Give staff one place to report an instruction that no longer matches the work. Ask for the procedure ID, affected step, observed difference and the job reference where appropriate. Keep customer details in the approved job system.
The process owner then checks the current source and routes specialist questions to the relevant reviewer. Staff can describe the mismatch without deciding its technical meaning.
Consider a hypothetical portal change that introduces a new question. The administrator records the change and asks the owner to clarify the permitted response. The owner identifies affected jobs, obtains any necessary review and updates the instructions. A difficult question should not be bypassed simply to keep the queue moving.
Record any temporary direction, who authorised it, its scope and when it expires. When the permanent procedure is released, replace the temporary instruction in the places staff actually use. A message buried in chat is a poor long-term substitute for maintained guidance.
Retire old working copies without erasing history
Keep a clearly identified current procedure and archive prior versions with their release records. Remove obsolete shortcuts and templates from active work areas so people do not accidentally start from the wrong version.
Check less obvious copies: onboarding packs, bookmarked documents, printed sheets and saved email templates. Keep historical records under the business's applicable retention rules; retiring an instruction from use does not mean deleting every record of it.
For project drawings, use a separate PV revision-control register. The SOP explains how to manage revisions; the project register identifies the actual drawing issued for a particular job.
After a substantial change, walk the team through a representative example. Ask them to locate the current procedure, identify its scope and explain where an exception goes. This checks whether the update can be used, rather than merely whether an email was sent.
Make maintenance part of the operating rhythm
Set review intervals with the process owner, based on how often the workflow changes and the consequences of outdated instructions. Also review when a source changes, an error recurs or staff report a mismatch. A calendar reminder alone cannot catch an urgent change between scheduled reviews.
A Philippines-based VA can maintain the source register, organise review reminders and prepare proposed edits. The authorised owner and specialist reviewer make the relevant decisions before release.
Track unanswered procedure questions, overdue reviews and errors linked to obsolete instructions. Start by fixing the procedure that creates the most repeat work. Talk to Nexus about solar administration training to build a playbook your local and offshore teams can maintain together.
