A defined market
You can identify the geography, customer segment, sales channel, product problem, and local service capability behind the request.
Qualified scope discussion
White-Label Home Energy Solutions
Define the product, brand, software, customer, installation, and support layers before treating a white-label idea as a real offer.
Qualified service businesses can discuss co-brand or white-label possibilities with Grus, but no standard public package, fully white-label app, price, MOQ, territory, timeline, or support model is promised here. Each layer requires source review and written scope confirmation.
Who this path is for
White-label is a scope question, not a single yes-or-no feature.
This path is for established service businesses that can describe their market, customers, local delivery capability, brand requirements, and pilot intent. It is not a public private-label catalog or a promise of exclusivity.
A bounded first offer
You can prioritize one product or kit path and separate must-have branding from ideas that can wait until a later phase.
Operational ownership
You can explain who sells, installs, supports, communicates policies, and remains accountable to the local customer.
Scope the layers
Separate product supply, presentation, software, enablement, and service ownership.
A white-label request can mean several different things: neutral product supply, co-branded packaging, sales material, a partner landing page, training documents, an app experience, or a complete customer-support model. These layers have different evidence, cost, timing, and ownership requirements.
The current starting point is a qualified Water Protection Partner Kit discussion because local fit and installation ownership can be made explicit. Energy Monitoring and Smart Heating can be discussed as future scope questions only when product facts, documentation, channel status, certifications, and partner demand support the request.
- Name the first product or kit path and the customer problem it addresses.
- Distinguish co-brand presentation from a fully white-label product or app.
- Define local installation, customer service, warranty communication, and field response.
- Treat packaging, software, training, pricing, MOQ, and timeline as review items.
Responsibility boundary
A partner brand does not remove local delivery and support obligations.
A credible offer needs a named owner for every customer-facing step. Grus does not claim to provide the partner's local installation network, onsite response, local code review, customer acquisition, or first-line field service.
Possible product, packaging, sales, software, training, and support layers remain discussion items until the relevant facts, source files, responsibilities, commercial terms, and acceptance criteria are confirmed in writing.
Grus can discuss
- A starting product or partner-kit scope based on current evidence
- Product documentation and compatibility-material requirements
- Co-brand, packaging, landing-page, and sales-material questions
- Software and account-model requirements that need feasibility review
- A proposed product-support handoff for a limited pilot
The local business owns
- Market, customer, channel, and local value proposition
- Qualified installation, local rules, project delivery, and field records
- Customer acquisition, job pricing, scheduling, and onsite response
- Clear policy, warranty, support, and service communication to customers
- The local brand promise and continuing customer relationship
Scope sequence
Qualify one pilot before designing a broad branded program.
A staged review keeps feasibility and evidence ahead of presentation. It also prevents a visual mockup from being mistaken for an approved product, app, packaging, or commercial commitment.
- 01
Define the business case
Share the market, customer, channel, local service capability, product problem, and reason a partner brand is needed.
- 02
Choose the first layer
Prioritize product supply, kit presentation, sales material, landing-page support, or another bounded requirement.
- 03
Review facts and ownership
Confirm product evidence, software feasibility, packaging source, policies, installation, support, and customer handoff.
- 04
Confirm a pilot in writing
Only then discuss quantity, pricing, schedule, acceptance criteria, deliverables, and the conditions for a wider rollout.
What needs confirmation
Treat every branded layer as a separate evidence and delivery decision.
Product photos, packaging concepts, app screens, and sales materials can help define a request. They do not prove that a SKU, app, certification, inventory position, commercial term, or support commitment is ready for a partner launch.
A useful inquiry states what must be partner-branded, what can remain Grus-branded, what the local business will operate, and which facts must be verified before either side presents the offer to customers.
Product scope Confirm the exact product or kit and its current source evidence.
Brand and packaging Discuss required artwork, files, approvals, quantity, and production feasibility.
App and accounts No fully white-label app is promised; architecture and ownership require review.
Commercial terms Price, MOQ, territory, timeline, and exclusivity are not published.
Support model Define local first-line service and the agreed Grus product-support handoff.
Qualified inquiry
Describe the first offer precisely enough to test feasibility.
Include business type, service region, customer segment, sales channel, installation capability, proposed product path, pilot volume, desired branding layer, software expectations, and the support responsibilities you can own locally.
The inquiry starts a review. It does not approve a white-label relationship, reserve territory, create exclusivity, confirm pricing or MOQ, promise an app, or establish a delivery timeline.
Need a product answer before a business discussion? Contact support or review manuals and downloads.
Questions before inquiry
Partner path FAQ
Use the answers below to separate a qualified discussion from an unverified public offer.
Does Grus offer a standard public white-label package?
No standard public package is listed. Qualified businesses can describe a proposed scope, after which product, brand, software, packaging, commercial, and support feasibility must be reviewed and confirmed in writing.
Is a fully white-label Grus app available today?
This page does not claim that a fully white-label app is available. App branding, account ownership, infrastructure, data, support, and delivery requirements need a separate feasibility review.
What can be discussed first?
A qualified business can begin with one product or kit path and discuss product presentation, co-brand material, documentation, landing-page needs, pilot scope, and support handoff without assuming that every layer is available.
Who handles local installation and customer service?
The local partner remains responsible for local assessment, installation, project delivery, customer communication, onsite response, and the field relationship unless a different written agreement is approved.
Next partner step
Bring one defined offer to a qualified scope review.
State the first product path, market, customer, branding layer, local delivery capability, pilot size, and support model. Grus can then identify what is feasible, what needs evidence, and what requires written terms.