Effective after-sales support for an EPC solar street lighting project is not defined by warranty length alone. It requires an agreed spare-parts plan, measurable service timelines, a documented fault-evidence workflow, clear logistics and on-site responsibilities, maintainable product architecture, and—where justified—remote monitoring that leads to real corrective action.
A statement such as “five-year warranty with a 24-hour response” may sound reassuring, but it leaves most operational questions unanswered.
Does 24 hours mean acknowledgement, diagnosis, parts dispatch, or restoration? Who inspects the failed light? Who pays international freight and customs charges? What happens if a controller model is discontinued? Can the local maintenance team replace a battery pack without damaging the enclosure sealing?
EPC contractors and project owners should resolve these questions before shipment—not after the first group of lights stops operating.
Quick Answer: What Should EPC After-Sales Support Include?
After-sales support for a solar street lighting project should cover technical diagnosis, warranty administration, spare-parts availability, preventive maintenance, local replacement responsibilities, logistics, documentation, and system records. For connected projects, it may also include remote monitoring, communication services, alarm handling, account ownership, and platform support.
At minimum, the procurement team should confirm:
- Which components are covered by warranty;
- When each warranty period begins;
- What evidence is required for a claim;
- How quickly the supplier acknowledges and diagnoses a fault;
- How replacement parts are approved and dispatched;
- Who pays freight, customs, local labor, and access-equipment costs;
- Which spare parts will be delivered with the project;
- How discontinued components will be replaced;
- What records will be transferred to the owner;
- What remote monitoring can and cannot confirm.
Without these details, the project may have a warranty on paper but no practical recovery path in the field.
What Should After-Sales Support Cover in an EPC Lighting Project?
A complete project support arrangement normally includes seven connected functions: technical support, warranty processing, spare-parts support, remote diagnosis, preventive maintenance, corrective work, and documentation. Each function solves a different part of the failure-response process and should not be treated as interchangeable.
| Support function | What it should define |
|---|---|
| Technical support | How installation, settings, operating data, and fault symptoms will be reviewed |
| Warranty administration | Coverage, exclusions, claim evidence, approval authority, and remedy |
| Spare-parts support | Part numbers, quantities, compatibility, storage, replenishment, and availability |
| Remote diagnosis | Available operating data, alarm logic, communication limits, and support actions |
| Preventive maintenance | Inspection intervals, cleaning, tightening, sealing, testing, and recordkeeping |
| Corrective action | Who removes, replaces, configures, tests, and returns failed components |
| Documentation | BOM, drawings, settings, manuals, serial records, claim forms, and maintenance history |
A project can have strong warranty wording but weak maintenance support. It can also have a remote management platform without local technicians or replacement parts.
The support model must therefore be reviewed as a complete operating system.
Why Warranty Length Alone Does Not Prove Serviceability
A long warranty period does not automatically prove that a failed lighting system can be restored quickly. A useful warranty must identify the covered component, failure condition, remedy, evidence requirements, exclusions, logistics responsibilities, and start date.
EPC teams should distinguish the following concepts:
| Term | Practical meaning |
|---|---|
| Product warranty | Responsibility for specified defects or failures under agreed conditions |
| Technical support | Assistance with installation checks, settings, fault isolation, and corrective recommendations |
| Service-level agreement | Measurable time targets for acknowledgement, diagnosis, approval, dispatch, or restoration |
| Spare-parts support | Availability and compatibility of replacement components |
| Preventive maintenance | Planned work intended to reduce avoidable failures |
| On-site service | Physical inspection, access, removal, replacement, recommissioning, and verification |
| Defects liability period | A contractual project period that may include responsibilities beyond the product warranty |
A warranty should also clarify whether coverage applies to:
- The complete luminaire;
- LED modules or drivers;
- Solar modules;
- Battery packs;
- Solar controllers;
- Sensors;
- Communication nodes;
- Gateways or platform hardware;
- Seals, connectors, and cables;
- Coatings or structural components.
Different components may have different warranty conditions. “Five-year system warranty” should not be accepted without a component-level warranty matrix.
The contract should also define when the warranty begins. Possible starting points include the manufacturing date, shipment date, delivery date, installation date, commissioning date, or project acceptance date. These dates can differ by several months on an international EPC project.
Free Replacement Parts Do Not Mean Free Project Restoration
A supplier may agree to provide a replacement controller or battery under warranty, but that does not automatically include international freight, import duties, local transportation, lifting equipment, technician labor, testing, or recommissioning.
These costs should be assigned before the contract is signed.
For example, replacing a controller in a warehouse is not the same as replacing one inside a luminaire installed on a nine-meter pole in a remote area. The project may require:
- A bucket truck or lifting platform;
- Traffic management;
- Electrical isolation;
- Trained technicians;
- New sealing materials;
- Controller configuration;
- Nighttime functional testing;
- Asset-record updates.
A warranty that covers only the component value may still leave the EPC contractor exposed to substantial field costs.
Build a Project Spare-Parts Plan Before Shipment
A project spare-parts plan should identify what will be kept locally, how every part matches the delivered system, how it must be stored, and how replacements will be recorded. “Spare parts available on request” is not sufficient for a large or geographically dispersed project.
The plan should be built from the final approved BOM, not from a generic product catalogue.
| Spare part | Required identification | Compatibility information | Storage concern | Replacement record |
|---|---|---|---|---|
| Battery pack | Part number, voltage, capacity, connector, BMS version | Controller, enclosure, cable polarity, charging profile | Temperature, state of charge, storage inspection | Old and new serial numbers |
| Solar controller | Part number, firmware, current ratings, programmed profile | Battery chemistry, PV input, LED load, sensor interface | Moisture and electrostatic protection | Settings and firmware record |
| LED module or driver | Power, current, optical distribution, thermal interface | Housing, lens, wiring, controller output | Moisture, impact, contamination | Replacement date and configuration |
| Solar module | Rated power, voltage, dimensions, frame and connector | Controller PV range and mounting structure | Impact and moisture protection | Output check and serial number |
| Seals and connectors | Size, material, position, IP-related function | Housing generation and cable type | UV exposure, deformation, contamination | Maintenance record |
| Communication node | Protocol, firmware, SIM or device ID | Gateway, CMS, controller, regional network | Account status and subscription | Device reassignment record |
The correct spare quantity cannot be determined by one universal percentage. It depends on:
- Project quantity;
- Number of product configurations;
- Distance between sites;
- International and local lead times;
- Expected operating period;
- Local maintenance capability;
- Environmental exposure;
- Component replacement difficulty;
- Contractual availability targets;
- Risk of model changes or discontinuation.
Standardizing components across the project can reduce spare-parts complexity. If every road section uses a different controller, battery connector, optical system, or firmware configuration, the project may need a much larger and more difficult inventory.
The Sunlurio solar street light range can be reviewed alongside the project BOM, but the final spare-parts schedule should always match the approved project configuration.
Check Whether the Product Is Actually Maintainable
Replaceable components are useful only if field replacement can be completed safely without creating a new failure point. EPC teams should review access, connectors, configuration requirements, sealing, tools, and recommissioning procedures before approving a maintenance strategy.
Important questions include:
- Can the battery, controller, or LED module be replaced separately?
- Does opening the enclosure affect IP protection?
- Are replacement gaskets or sealing materials required?
- Are connectors keyed and clearly labeled?
- Is a special programming device required?
- Must the replacement controller receive the original dimming profile?
- Can the local team verify polarity before reconnection?
- Is functional testing possible during daytime?
- Does the product need to be removed from the pole for service?
- Will an unauthorized repair void the remaining warranty?
A “modular design” claim should be supported by an exploded drawing, replaceable-part list, instructions, and sealing procedure—not only by marketing language.
Define an SLA That Separates Response, Diagnosis and Restoration
An effective service-level agreement separates acknowledgement, evidence review, diagnosis, corrective-action approval, parts dispatch, field replacement, and final verification. Combining all these steps under one “24-hour response” promise creates an unrealistic expectation and a weak contract.
A workable fault process follows this sequence:
- Fault detected and ticket opened;
- Supplier acknowledges receipt;
- Evidence package is checked for completeness;
- Engineering team performs initial diagnosis;
- Additional tests are requested if necessary;
- Corrective action or warranty responsibility is approved;
- Replacement part is prepared and dispatched;
- Local team completes physical replacement;
- Product settings and operation are verified;
- Asset and maintenance records are updated;
- Ticket is formally closed.
The SLA should define a separate target for each controllable stage.
| SLA stage | Question to define |
|---|---|
| Acknowledgement time | How quickly will the supplier confirm receipt of the ticket? |
| Evidence review | How quickly will the supplier identify missing information? |
| Initial diagnosis | How quickly will engineering provide a preliminary cause or test plan after receiving complete evidence? |
| Corrective-action approval | Who approves a warranty replacement, parameter change, or field repair? |
| Parts dispatch | How quickly will an available replacement part leave the supplier’s warehouse? |
| Local replacement | Which party arranges technicians, access equipment, and site safety? |
| Restoration target | When should the light return to service, considering logistics and local resources? |
| Closure verification | What evidence proves the fault has been resolved? |
However, a manufacturer cannot independently control every part of the restoration time. Customs clearance, remote-site access, storms, road closures, lifting-equipment availability, and the owner’s approval process may all affect recovery.
For this reason, supplier-controlled times and project-controlled times should be written separately.
Set Different Priorities for Different Faults
Not every fault requires the same response. A single non-operating light on a low-traffic road is different from an exposed electrical conductor, a structurally damaged pole, or a group outage affecting an intersection.
A practical priority system may distinguish:
- Safety-critical faults: Structural instability, exposed electrical parts, fire risk, or severe collision damage;
- Network or group faults: Gateway outage, repeated communication loss, common configuration error, or batch failure;
- Major operating faults: Complete luminaire failure, repeated battery shutdown, or charging failure;
- Performance faults: Insufficient operating hours, unexpected dimming, or declining energy balance;
- Routine defects: Isolated sensor behavior, minor reporting errors, or non-critical cosmetic issues.
The priority definitions and response targets must be adapted to the project contract. They should not be copied into every tender without considering the site, project scale, local resources, and safety requirements.
What Evidence Should Accompany a Support or Warranty Claim?
A support claim should contain enough information to identify the exact asset, reproduce the operating condition, separate installation issues from product faults, and select the correct replacement part.
Evidence requirements should be issued during project handover—not invented after a failure occurs.
A practical fault-evidence package can include:
- Project name and purchase-order or contract reference;
- Site, road section, pole number, or GPS location;
- Product model and serial number;
- Installation and commissioning dates;
- Controller settings and dimming profile;
- Description of the symptom and when it began;
- Whether the fault affects one unit or a group;
- Recent weather or site conditions;
- Photographs of the luminaire, solar module, wiring, connectors, and mounting;
- Voltage or functional measurements, where safe and permitted;
- Video showing the operating problem;
- Installation and maintenance records;
- Previous repairs or component replacements;
- CMS alarms, trends, or event logs, if available.
The local team should not perform unsafe electrical work or open sealed components merely to obtain evidence. The evidence procedure must respect the approved maintenance method, electrical safety requirements, working-at-height controls, and warranty conditions.
Project Support Ticket Evidence Flow
A traceable support process should follow this sequence:
- Identify the pole and product serial number;
- Record the symptom, time, and site conditions;
- Attach installation, commissioning, and maintenance evidence;
- Review operating data and configuration;
- Classify the likely cause;
- Approve a test, setting change, replacement, or site repair;
- Verify operation after corrective action;
- Update the project asset record.
This process does not guarantee that every fault can be diagnosed remotely. It ensures that the engineering team begins with a defined asset and a usable evidence set instead of an untraceable message such as “some lights are not working.”
The importance of BOM and batch traceability is explained further in Sunlurio’s guide to IQC, IPQC, OQC, and project quality records.
What Can Remote Monitoring Actually Do?
Remote monitoring can shorten fault isolation by showing operating status, trends, configuration, and communication events. It cannot independently confirm every physical or electrical failure, and it does not replace local inspection, spare parts, safe access equipment, or trained technicians.
Depending on the system architecture and available sensors, a central management system may help identify:
- Whether a device is online;
- Battery-voltage or estimated-SOC trends;
- PV charging status;
- Load operating status;
- Controller fault codes;
- Dimming-profile execution;
- Communication interruptions;
- Similar abnormalities across multiple lights;
- Repeated low-energy or shutdown events.
Its limitations must be stated just as clearly.
| CMS may indicate | CMS cannot confirm alone | Additional action |
|---|---|---|
| Device offline | Whether the luminaire or communication network failed | Network check and local functional inspection |
| Low battery voltage or SOC trend | Actual remaining battery capacity | Battery testing and site inspection |
| Low PV charging input | Whether the cause is dust, shade, wiring, damage, or weather | Visual and electrical inspection |
| Load or driver alarm | Actual optical performance on the road | Night inspection or photometric verification |
| Configuration mismatch | Whether the original setting was approved | Compare with commissioning records |
| Repeated group anomaly | Whether the cause is a common component, installation method, or environment | Batch and site investigation |
| Communication loss | Whether the lamp continues to operate locally | Local operating check |
| Normal reported data | Absence of corrosion, loose fasteners, water ingress, or structural damage | Periodic physical inspection |
Remote monitoring shortens fault isolation; it does not eliminate field maintenance.
Remote Monitoring Has Ongoing Costs and Dependencies
A connected lighting system may require gateways, SIM cards, data plans, cloud services, software licenses, account administration, cybersecurity controls, and local network coverage. These are lifecycle responsibilities—not one-time hardware features.
Before approving a connected system, the EPC and owner should confirm:
- Which communication protocol is used;
- Whether the site has reliable network coverage;
- Who supplies and registers SIM cards;
- Who pays recurring data and platform fees;
- What happens when a subscription expires;
- Who owns the project account and historical data;
- Which users may change dimming settings;
- Whether configuration changes are logged;
- What happens when the platform or gateway is offline;
- Whether the lights continue operating autonomously without communication;
- How accounts and credentials are transferred at handover;
- How long platform support is expected to remain available.
A smart-lighting platform should be selected because it improves an identified operating requirement. It should not be added only because “remote monitoring” sounds more advanced.
For projects that genuinely require centralized monitoring, review the available smart lighting architecture and product options together with communication coverage, operating responsibilities, and lifecycle costs.
Divide Responsibilities Before Handover
Manufacturer, EPC contractor, installer, owner, local O&M team, and communication provider do not control the same tasks. A responsibility matrix should be agreed before handover so that a fault does not remain unresolved while each party waits for another party to act.
The following matrix is a review framework. The signed contract remains authoritative.
| Task | Manufacturer | EPC or installer | Owner or O&M team | CMS or telecom provider |
|---|---|---|---|---|
| Product-level diagnosis | Lead or support remotely | Submit evidence and perform requested checks | Report faults and maintain records | Provide network or platform information |
| Physical site inspection | Provide instructions | Usually execute during installation or DLP | Execute after maintenance responsibility transfers | Not normally responsible |
| Warranty review | Confirm coverage and remedy | Submit complete claim | Provide asset and maintenance history | Provide relevant logs if required |
| International shipment | Supply as contracted | Manage receipt or customs as contracted | As contracted | Not normally responsible |
| Local transportation | As contracted | Arrange during project period | Arrange after handover if assigned | Not normally responsible |
| Component replacement | Provide procedure or training | Usually execute during DLP | Local team executes after transfer | Not normally responsible |
| Reconfiguration | Provide approved parameters or procedure | Apply and verify as authorized | Control later changes | Maintain platform access |
| CMS operation | Support supplied system as agreed | Commission devices and accounts | Review alarms and manage users | Maintain connectivity or platform |
| Ticket closure | Confirm technical resolution | Provide verification evidence | Accept restored operation | Confirm communication restoration |
A supplier should not promise “global on-site service” unless the countries, personnel, response model, commercial conditions, and local access arrangements are clearly established.
Remote engineering guidance can support a local team, but it is not the same as dispatching a technician to the site.
Handover Documents Required for Long-Term Maintenance
Project handover should give the owner enough information to identify each asset, operate it correctly, maintain it safely, submit a support claim, and obtain compatible replacement parts.
The handover package should be adapted to the contract and may include:
- Final approved bill of materials;
- Approved datasheets;
- As-built drawings;
- Pole and luminaire location schedule;
- Serial-number and location register;
- Wiring diagrams;
- Controller settings;
- Approved dimming profiles;
- Installation instructions;
- Commissioning records;
- Inspection and acceptance records;
- Preventive-maintenance schedule;
- Troubleshooting flowchart;
- Replaceable-part list;
- Spare-parts schedule;
- Warranty matrix;
- Claim form and evidence requirements;
- Escalation contacts;
- Training records;
- CMS device, account, and data-access information;
- Record of approved deviations.
Sunlurio’s engineering support resources can be used to organize project-specific datasheets, drawings, photometric files, BOQ mapping, and technical review inputs.
Preventive Maintenance Must Be Separated From Warranty Work
Preventive maintenance reduces avoidable failures; warranty work addresses covered defects. Confusing the two can create disputes when poor cleaning, loose connections, blocked solar modules, unauthorized settings, or missing inspections contribute to a failure.
The maintenance plan should define:
- Solar-module cleaning criteria;
- Vegetation and shading inspection;
- Fastener and bracket checks;
- Cable, connector, and gland inspection;
- Enclosure and sealing inspection;
- Corrosion and coating checks;
- Battery operating-data review;
- Controller-event review;
- Luminaire and optical-surface inspection;
- Pole, arm, door, and foundation observation;
- CMS connectivity and account checks;
- Recording and escalation requirements.
The frequency cannot be copied blindly from another project. Dust, rainfall, coastal exposure, heat, road traffic, vandalism risk, vegetation, access difficulty, and local staffing can all affect the appropriate interval.
Maintenance records should identify the pole or asset, date, activity, finding, corrective action, technician, and any replaced component.
Common Red Flags in an After-Sales Proposal
A weak proposal usually relies on broad promises while avoiding measurable responsibilities. The following warning signs should be resolved during technical clarification or contract negotiation:
- “Five-year warranty” with no component-level coverage;
- “24-hour response” with no definition of response;
- No distinction between diagnosis, dispatch, and restoration;
- No published claim-evidence requirements;
- No final spare-parts list or part numbers;
- No compatibility information for batteries or controllers;
- No policy for discontinued components;
- No explanation of international freight or customs responsibility;
- No identification of local labor responsibility;
- Claims of worldwide field service without named service arrangements;
- A fully sealed product with no approved replacement procedure;
- Remote monitoring presented as a substitute for physical inspection;
- No definition of platform, SIM, gateway, or subscription costs;
- No account and data-transfer plan;
- No approved-settings record;
- No asset register at handover;
- Product defects and installation errors handled through the same unclear process;
- All responsibilities left for negotiation after a fault occurs.
These issues do not automatically prove that a supplier is unreliable. They show that the proposal is incomplete and creates avoidable project risk.
What After-Sales Arrangements Are Not Suitable?
Not every support model fits every project. A technically impressive solution can still be unsuitable if the local operating conditions, contract, or maintenance organization cannot support it.
Remote Monitoring May Not Be Suitable When:
- Network coverage is unreliable;
- The owner has no staff assigned to review alarms;
- Recurring platform costs are not funded;
- The system cannot transfer data ownership;
- The project does not permit remote setting changes;
- Local technicians and spare parts remain unavailable.
A Highly Integrated Sealed Product May Not Be Suitable When:
- The project requires long service life with local module replacement;
- International replacement lead times are long;
- The local team cannot reseal the enclosure correctly;
- The full fixture must be replaced for a minor component fault.
A Centralized Spare-Parts Model May Not Be Suitable When:
- Project sites are spread across several remote regions;
- Customs or domestic transport lead times are unpredictable;
- The contract includes strict availability targets;
- Local depots cannot obtain critical parts quickly.
The correct support strategy should be designed around project risk, not copied from a supplier’s standard brochure.
How to Write After-Sales Requirements Into an RFQ or Contract
An RFQ should request measurable fields rather than asking the supplier to “describe its good after-sales service.” The final wording should be reviewed by the project’s technical and contractual teams.
| Requirement field | Information to request |
|---|---|
| Warranty scope | Covered components, conditions, exclusions, and remedy |
| Warranty start date | Shipment, delivery, commissioning, acceptance, or another defined milestone |
| Acknowledgement time | Working hours or calendar hours after receiving a ticket |
| Evidence review time | Time to confirm whether the submitted package is complete |
| Initial diagnosis time | Time after receipt of complete evidence |
| Approval time | Authority and target for warranty or corrective-action approval |
| Dispatch time | Target for available stock after approval |
| Priority classes | Safety, group outage, major fault, performance issue, routine defect |
| Spare-parts schedule | Part number, quantity, price, location, storage, and replenishment |
| Discontinued parts | Compatibility and substitution policy |
| Freight and customs | Responsible party and applicable delivery terms |
| Local labor | Party responsible for inspection, access, replacement, and testing |
| CMS responsibilities | Platform, SIM, gateway, data, licensing, account, and support |
| Reporting | Ticket register, monthly report, availability record, or other requirement |
| Escalation | Primary and secondary technical contacts |
| Closure | Required functional test and acceptance evidence |
Avoid inserting a generic “24/48/72-hour” schedule without checking project geography, criticality, available inventory, local technicians, and customs conditions.
The requirement must be demanding enough to protect the project but realistic enough to be priced and delivered.
What Should Be Submitted for a Sunlurio Project Review?
A useful engineering review begins with project-specific information rather than a request for a generic warranty certificate. The available support package should be matched to the approved system, project quantity, installation country, tender stage, and maintenance model.
For review, provide:
- Project country and site type;
- Required quantity;
- Road or application information;
- Proposed solar street light architecture;
- Tender or employer requirements;
- Required warranty period;
- Target response or dispatch conditions;
- Local maintenance capability;
- Preferred spare-parts arrangement;
- Remote-monitoring requirement, if any;
- Required handover documents;
- Available BOQ, drawings, technical specifications, or compliance sheets.
Based on these inputs, the relevant project submission may include a proposed BOM, replaceable-module information, warranty matrix, spare-parts schedule, controller records, O&M documentation, or applicable smart-system architecture notes.
Request an engineering support review before the final RFQ, BOQ, or support responsibility matrix is locked.
Project After-Sales Review Checklist
Before issuing a purchase order, confirm that the answer to each question is documented.
Warranty and Claims
- [ ] Are all covered components identified?
- [ ] Is the warranty start date defined?
- [ ] Are exclusions visible before purchase?
- [ ] Is the claim-evidence package agreed?
- [ ] Is the remedy defined as repair, replacement, credit, or another action?
- [ ] Are freight, customs, and local labor responsibilities clear?
Service Timelines
- [ ] Is acknowledgement separated from diagnosis?
- [ ] Is diagnosis separated from approval?
- [ ] Is approval separated from dispatch?
- [ ] Is dispatch separated from site restoration?
- [ ] Are safety-critical and routine faults assigned different priorities?
- [ ] Are working days, time zones, and escalation contacts defined?
Spare Parts and Maintainability
- [ ] Is the spare-parts list based on the final BOM?
- [ ] Are part numbers and compatibility details included?
- [ ] Are storage requirements provided?
- [ ] Can critical modules be replaced safely?
- [ ] Is resealing or recommissioning required?
- [ ] Is there a discontinued-component policy?
Remote Monitoring
- [ ] Are the available data points listed?
- [ ] Are alarm limits and data gaps explained?
- [ ] Are network, SIM, platform, and subscription responsibilities assigned?
- [ ] Does the system continue operating when communication fails?
- [ ] Are account ownership and data transfer defined?
- [ ] Is local inspection still included in the maintenance plan?
Handover and Operation
- [ ] Is there a serial-number and location register?
- [ ] Are approved settings and dimming profiles recorded?
- [ ] Are as-built drawings and commissioning records included?
- [ ] Is a preventive-maintenance plan provided?
- [ ] Is local training documented?
- [ ] Is there a clear ticket-closing and record-update process?
Frequently Asked Questions
Is a 24-Hour Response SLA the Same as a 24-Hour Repair Commitment?
No. A 24-hour response normally means the support team acknowledges the ticket or begins reviewing it. It does not automatically mean diagnosis, warranty approval, parts dispatch, customs clearance, site replacement, and restoration will all be completed within 24 hours. Each stage should have a separate definition.
How Many Spare Parts Should an EPC Keep?
There is no universal percentage suitable for every solar street lighting project. The quantity should reflect project size, configuration standardization, component risk, international lead time, local access, contractual availability requirements, and maintenance capability. Critical components with long delivery times may justify a higher local stock level.
Who Pays Freight and Customs for Warranty Replacements?
The warranty or supply contract should state this explicitly. Free replacement of a defective part does not automatically include international freight, insurance, customs duties, local transportation, lifting equipment, or technician labor. These costs should be allocated before purchase.
Can Remote Monitoring Confirm That a Battery Has Failed?
Not by itself. Battery voltage, estimated SOC, charging trends, and shutdown events may indicate an abnormal condition, but they do not always prove loss of capacity or identify the physical cause. Configuration review, local inspection, and appropriate battery testing may still be necessary.
What Happens if the Original Controller or Battery Is Discontinued?
The supplier should define a substitution process covering electrical compatibility, dimensions, connectors, firmware, control settings, BMS requirements, and recommissioning. A replacement should not be approved only because its voltage or nominal capacity appears similar.
Is On-Site Service Included in a Manufacturer’s Warranty?
Not necessarily. Many warranties cover a component remedy but exclude travel, visas, local transportation, lifting equipment, site labor, removal, installation, and recommissioning. Any on-site service commitment should identify the location, scope, response model, and commercial conditions.
What Records Should Be Transferred to the Owner?
The owner should receive the final BOM, drawings, approved settings, asset and serial-number register, commissioning records, spare-parts list, maintenance instructions, warranty matrix, claim workflow, and—where applicable—CMS accounts, device mappings, and data-access information.
Can a Non-Smart Solar Street Light Receive Remote Technical Support?
Yes. Engineers can review photographs, videos, measurements, controller settings, installation records, and fault descriptions without a CMS. However, the diagnosis will depend on the quality of the submitted evidence and may still require a local inspection or controlled component test.
Final Takeaway
The strongest after-sales proposal is not the one with the longest promise. It is the one that explains what happens after a fault is detected: who reports it, what evidence is required, who diagnoses it, which part is supplied, who handles logistics, who completes the field work, and how normal operation is verified.
For an EPC solar street lighting project, after-sales support should be designed before shipment as part of the technical and contractual solution.
A documented spare-parts plan, realistic SLA, traceable fault workflow, clear responsibility matrix, complete handover package, and properly bounded monitoring system provide more protection than a generic statement such as “five-year warranty and lifetime service.”
Planning an EPC, municipal, or tender-based solar street lighting project?
Submit the project quantity, installation country, technical requirements, warranty conditions, local maintenance capability, and any remote-monitoring requirements to request a project engineering review.
