Solar Proposal App: Mobile Buyer Test Guide

A solar proposal app should preserve technical sources, commercial approvals, immutable versions, and delivery evidence across exact phones, tablets, browsers, plans, regions, and roles. Select through synthetic failure tests. Verify permissions, offline conflicts, rendering, consent, pricing, contract, export, device loss, offboarding, and exit before sending a real customer proposal.

Mobile convenience can shorten field work. It can also let a stale design, wrong price, unapproved discount, or personal message bypass controls.

This page owns mobile proposal execution. Use the proposal software features guide for broad capability selection. Use the solar quotation app guide for narrower quotation workflows.

Solar proposal app selection needs 17 gates

Require evidence for these gates:

1. Exact channel, app, browser, device, and region
2. Task parity by plan and role
3. Controlled objects and stable identifiers
4. Separate technical, commercial, document, and delivery states
5. Traceable design, energy, equipment, and BOM sources
6. Approved price, discount, tax, subsidy, and finance inputs
7. Immutable proposal versions and withdrawal control
8. Segregated mobile permissions and override audit
9. BYOD, shared-device, and lost-device controls
10. Offline, sync, conflict, retry, and reconciliation tests
11. Deterministic rendering and preview acceptance
12. Recipient, channel, consent, send, and delivery evidence
13. Privacy, security, incident, and retention controls
14. Synthetic normal and failure pilot
15. Complete cost, plan, contract, and renewal review
16. Export, archive, offboarding, deletion, and exit test
17. Equal evidence standards for every vendor

Mark each gate pass, conditional, or fail. A condition needs an owner, evidence, due date, and consequence. Do not average away a failed source, approval, privacy, or exit gate.

Distinguish app, PWA, browser, and customer view

The word app can describe several delivery patterns. Record the exact channel before testing.

A responsive customer proposal does not prove that an installer can create or administer it on the same phone. A store badge does not prove current listing availability.

Record vendor, publisher, package, store destination, web URL, supported OS, device class, region, language, accessibility, release, update method, permissions, storage, and support.

Test on the actual device fleet. An old phone, managed tablet, and current personal device can behave differently.

Build a task-parity matrix

Do not ask whether mobile is supported. Ask whether a named role can complete a named task through a named channel.

Test these tasks:

• Create customer, account, site, opportunity, and project
• Import or select a controlled design
• Review equipment, capacity, BOM, and energy source
• Edit commercial items and approved assumptions
• Request and grant technical approval
• Request and grant commercial approval
• Generate and preview the document
• Confirm recipient and sending permission
• Send, retry, withdraw, supersede, and archive
• Review delivery and customer-response states
• Configure templates, roles, price books, and rules
• Import, export, delete, and retrieve audit evidence

For every row, record phone, tablet, desktop, app or browser, OS, release, region, plan, role, expected result, actual result, limitation, and fallback.

Do not infer administration parity from salesperson access. A mobile user may create a proposal but lack price-book, template, export, or deletion controls.

Use the mobile CRM guide when lead and field-record tasks extend beyond proposal execution.

Define objects and relationships

A proposal should not become the only record for the customer, site, design, or commercial opportunity.

Define these objects where applicable:

• Lead, contact, household or account
• Site, opportunity, and project
• Design, equipment set, BOM, and energy model
• Price book, tariff, subsidy, tax, and finance scenario
• Proposal, option, template, and approval
• Recipient, message, consent, and acceptance
• Task, activity, attachment, and audit event

Use stable identifiers. A mutable email or phone number should not be the only key. Link one customer to multiple sites and opportunities without overwriting history.

One proposal can present several options. Each option needs its own technical and commercial source references. The accepted option should create or link the project record without erasing rejected versions.

Keep every state separate

One pipeline stage cannot prove technical approval, document delivery, or customer acceptance.

Use separate state groups:

These are example labels, not a mandatory vendor workflow. Define entry, evidence, allowed transition, authority, automation, exit, backward movement, and reopen rules.

Delivered is not viewed. Viewed is not accepted. Accepted is not paid. Paid is not installed or satisfied.

Trace every technical source

Proposal values should link to a controlled technical project and revision. Mobile edits must not silently alter technical facts.

Trace:

• Project identity, address, site, and customer route
• Load, bill, utility, and tariff source
• Layout, capacity, exact modules, inverters, and strings
• Shading model, weather source, generation method, and losses
• BOM, storage, backup, export, and other design inputs
• Author, checker, approver, date, assumption, limitation, and validity

Every displayed capacity, generation figure, equipment item, and technical note should identify its source record. A copied number without provenance should fail review.

A proposal app does not replace survey, design, engineering, professional, authority, utility, tax, legal, finance, or safety review. Assign each responsibility separately.

Use the survey-to-proposal workflow to control the handoff. The solar design software guide covers technical-tool selection.

Control price and commercial assumptions

Every item needs source, unit, quantity, conversion, cost basis, selling price, markup or margin basis, discount, approval floor, and currency.

Keep these controls separate:

• Price-book selection and effective date
• Item and quantity override
• Cost, markup, margin, and selling-price visibility
• Discount request, reason, limit, and approval
• Tax classification, rate, invoice, and reviewer
• Tariff source, date, structure, and limitation
• Subsidy or incentive route, version, eligibility, and qualification
• Finance provider, product, assumptions, terms, and approval boundary
• Deposit, milestone, warranty, exclusions, validity, and escalation

Do not turn a calculated subsidy, tax, savings, payback, return, or finance scenario into guaranteed cash or outcome. State source, date, assumptions, limitations, and reviewer.

Phone edits should not bypass approval. Record before and after values, requester, reason, evidence, approver, time, affected version, and audit event.

The PM Surya Ghar proposal software guide covers India scheme-calculation controls. Authority rules, not proposal software, define eligibility.

Control templates and immutable versions

The template is a governed commercial and legal artifact. Record template ID, version, language, brand, legal entity, approvers, effective date, and permitted users.

Check that it controls:

• Salesperson and legal entity identity
• Customer, address, contact, and project scope
• System, equipment, visuals, production, and limitations
• Price, taxes, financing, and incentives
• Warranties, exclusions, terms, and validity
• Acceptance, privacy, next steps, and required notices

One immutable proposal ID and version should tie the generated PDF or web link to its technical and commercial sources.

Do not regenerate an old version with current data under the same identifier. Create a new version and preserve the old output.

Withdraw superseded links and documents where supported. Record withdrawal time, recipients, reason, replacement version, and residual access.

Use the solar proposal template guide for content architecture. This page owns mobile execution and evidence.

Segregate permissions on mobile

Separate technical edit, commercial edit, discount, margin override, tax, subsidy, finance, template, terms, approval, sending, withdrawal, export, and deletion permissions.

A salesperson who can send should not automatically change tax or approve a discount. A technical reviewer should not inherit customer-export rights without need.

Review:

• Named accounts and least privilege
• MFA where supported
• Session duration, reauthentication, and recovery
• Biometric option and device-bound behavior where offered
• Local cache, files, downloads, gallery, and screenshots
• Clipboard, camera, location, contacts, microphone, and notifications
• Deep links, share sheets, external storage, and personal cloud backup
• Audit events for access, edits, approvals, sends, exports, and deletion

Test denial, not only successful access. Verify that a blocked role cannot act through an old session, shared link, offline queue, or another device.

Manage BYOD and device loss

Define whether phones are corporate, managed, shared, or bring-your-own. Apply a written policy to each class.

Cover:

• Device registration and inventory
• Supported OS, browser, app, security patch, and storage
• Screen lock, encryption evidence, and account separation
• Rooted or jailbroken device treatment
• Local download and screenshot rules
• Repair, replacement, resale, and disposal
• Lost or stolen reporting and session revocation
• Employee role change and exit
• Remote management where adopted
• Recovery without restoring uncontrolled customer files

Do not use a personal WhatsApp account, local gallery, personal cloud drive, copied PDF, or shared phone as the sole production record.

Test lost-device response. Revoke sessions, remove access, review exports, preserve audit records, and restore work through the controlled system.

Define offline and synchronization behavior

Offline can mean a cached view, local draft, queued action, or full edit. Verify each task separately.

For every mobile-to-cloud or external handoff, define the system of record, object ID, field owner, direction, event, timing, version, and idempotency. Also define conflict, error, alert, replay, reconciliation, and audit rules.

Test:

1. Open an existing proposal offline.
2. Create a local draft.
3. Edit an allowed field.
4. Add an attachment.
5. Preview without network access.
6. Queue a send or approval action where claimed.
7. Restore connectivity.
8. Create a conflicting desktop edit.
9. Submit duplicate and out-of-order actions.
10. Expire the session or token.
11. Update the app or browser.
12. Exhaust local storage safely.
13. Delete or reassign the server record.
14. Reconcile the final state and audit history.

The conflict rule should not be a hidden last-write-wins assumption. Technical, price, tax, approval, recipient, and consent conflicts may need manual review.

Retries should be idempotent. A reconnect must not create duplicate proposals, approvals, messages, or customer activities.

Approve before generation and sending

Use a staged workflow:

1. Completeness review
2. Technical approval
3. Commercial approval
4. Legal or compliance review where required
5. Document generation
6. Deterministic preview
7. Recipient confirmation
8. Send authorization
9. Delivery tracking
10. Customer access or acceptance
11. Expiry, withdrawal, or revision
12. Archive and downstream handoff

Generation should use one fixed source snapshot. A background design or price change must not alter an approved proposal silently.

Require preview on target phone, tablet, desktop, browser, PDF viewer, and print path where relevant. Test page count, fonts, tables, images, charts, units, currencies, tax, totals, links, accessibility, and file size.

Wrong rendering is a failed output even when the source values are correct. Preserve the generated artifact and rendering evidence.

Record delivery by channel

Email, SMS, WhatsApp, app message, web link, PDF, portal, download, and in-person display are distinct channels. Each has different evidence and consent needs.

Capture:

• Sender account and authorized user
• Recipient identity and confirmed destination
• Purpose and channel permission
• Template where applicable
• Proposal ID and immutable version
• Send time and timezone
• Provider message ID where available
• Accepted, delivered, failed, read, or bounce state where supported
• Retry, recipient correction, opt-out, and fallback
• Link access, expiry, withdrawal, and supersession

A generated PDF is not a sent proposal. A provider-accepted message is not delivered. A link view is not a signature or valid contractual acceptance.

Use the solar CRM with WhatsApp guide when delivery enters a broader CRM workflow. Do not infer a native integration from a share button.

Control consent, privacy, and security

Keep data-processing notice, sales communication, service communication, marketing permission, channel consent, signature, acceptance, opt-out, suppression, withdrawal, correction, deletion, grievance, and retention states separate.

Map the vendor, app stores, cloud, PDF or link host, email, messaging, analytics, crash reporting, payment, signature, support, and other subprocessors.

Record data categories, purposes, recipients, regions, transfers, retention, deletion, access, security, incidents, and audit evidence.

India’s current DPDP materials include phased and date-specific commencement. Review the official MeitY DPDP route with qualified advisers.

Qualified review should determine actual roles, notice, consent or another basis, rights, security, breach, retention, transfer, deletion, and grievance duties. Do not treat later-starting obligations as already operative.

Run a synthetic failure pilot

Use synthetic projects and recipients. Do not contact real customers, accept legal terms, or create external accounts without authorization.

For every case, record channel, device, OS, role, input, expected state, allowed edit, blocked edit, approval, output, audit, reconciliation, fallback, and pass limit.

Test:

• Exact phone, tablet, and desktop tasks
• Wrong login, role, project, and recipient
• Lost device and revoked session
• Offline draft, reconnection, and conflicting edits
• Duplicate and out-of-order actions
• Expired session, app update, and schema change
• Invalid fields and storage exhaustion
• Unauthorized price, discount, tax, or terms change
• Design change and equipment substitution
• Stale tariff and qualified subsidy scenario
• Expired and withdrawn offer
• PDF and web-link rendering
• Failed and delayed send
• Resend, opt-out, and recipient correction
• Superseded version and controlled acceptance
• Complete export, offboarding, retention, deletion, and exit

Do not claim hands-on testing unless the authorized evidence exists. Product pages remain first-party claims until reproduced in the accepted pilot.

Reconcile mobile activity and reporting

Reports should derive from controlled objects and state evidence. A dashboard count is not enough when mobile queues, retries, withdrawals, or duplicates remain unresolved.

Reconcile:

1. Approved technical source versions
2. Approved commercial source versions
3. Generated proposal IDs and file hashes
4. Previewed and send-authorized versions
5. Queued, sent, failed, retried, and delivered messages
6. Recipient corrections, opt-outs, withdrawals, and supersessions
7. Customer views and supported acceptance records
8. Opportunity, payment, and project handoffs
9. Offline actions, conflicts, error queues, and replays
10. Exports, archives, deletions, and offboarded accounts

Define the reporting timezone, date boundary, duplicate rule, excluded test records, and late-event treatment. Preserve raw events behind calculated metrics.

Do not describe a sent proposal as a contacted customer without channel evidence. Do not describe a view as acceptance or conversion.

Audit changes to report filters, state mappings, owner assignments, and historical dates. Restrict bulk edits and preserve before-and-after values.

Use the solar proposal analytics guide for metric definitions. Use the CRM with quotation software guide for downstream system-of-record reconciliation.

Normalize TCO, contract, renewal, and exit

Build a three-year cost sheet. Separate public, quoted, estimated, usage-based, pass-through, optional, and unknown amounts.

Include:

• Base plan, seats, roles, devices, and regions
• Proposal, template, storage, and attachment limits
• Messages, email, SMS, WhatsApp, PDF, and link hosting
• API, connectors, CRM, accounting, and signature services
• Setup, migration, customization, and training
• Support, sandbox, backup, security, and incident work
• Tax, overages, price changes, and renewal
• Internal administration, approvals, reconciliation, and audit
• Export, archive, transition, termination, deletion, and exit

The contract should state service scope, plan limits, support milestones, data ownership, exports, deletion, termination, post-termination access, change notice, price change, and exit assistance.

Test a complete export before purchase. Preserve objects, relationships, IDs, versions, sources, approvals, recipients, messages, consent, audit, attachments, and deleted-state treatment.

Evaluate QuickEstimate through identical gates

Related-party disclosure: SurgePV and QuickEstimate have a commercial relationship. QuickEstimate receives no automatic preference. Its claims face the same evidence, pilot, contract, and acceptance gates as every product.

The QuickEstimate download page makes first-party mobile, store, web, offline, sync, proposal, WhatsApp, CRM, subsidy, tariff, and plan statements.

Prior research could not resolve the direct store destinations. A badge or vendor download page is discovery evidence only. Verify the exact publisher, package, listing, target device, OS, region, plan, role, release, permissions, installation, and workflow.

The QuickEstimate product page remains first-party evidence. Do not infer speed, parity, delivery, integration, customer count, or outcomes.

Review current pricing, security, privacy, and terms pages.

The separate refund policy should be reconciled with pricing-page wording before purchase. Neither page proves refund eligibility.

Apply identical channel, source, commercial, permission, offline, sync, delivery, consent, security, cost, contract, support, export, and exit gates. Choose another product when it performs better.

Apply the same evidence standard to SurgePV

SurgePV is the site owner’s product. Its current first-party pages describe proposal output, solar design and BOM, shadow analysis, and a generation and financial tool.

Treat those as first-party capability statements. Test the exact device, browser, project, region, role, source, output, and current workflow.

Do not infer a native app, CRM, offline operation, WhatsApp delivery, e-signature, approval workflow, QuickEstimate connection, or external integration. Do not infer accuracy, savings, timing, or outcome.

Red flags that justify a pause

Pause selection when a vendor:

• Uses app without naming the delivery channel
• Cannot resolve its direct store listing
• Demonstrates another device, region, plan, or role
• Treats customer mobile view as creator parity
• Allows phone edits to change technical sources silently
• Mixes technical, commercial, document, and delivery states
• Regenerates one proposal version with changed data
• Allows unapproved price, tax, subsidy, or terms overrides
• Cannot explain offline conflicts and duplicate retries
• Stores the only proposal copy on a personal device
• Treats sent, delivered, viewed, accepted, and won as one state
• Cannot withdraw a wrong recipient or superseded link
• Claims security without the complete data path
• Hides plan limits, dependencies, recurring costs, or exit terms
• Cannot export relationships, sources, approvals, and audit history

Convert missing evidence into a pilot condition or reject the product. Do not replace failed workflow evidence with a badge or ranking.

Buyer acceptance checklist

Before production use, confirm:

• Exact app, browser, device, OS, region, plan, role, and release
• Task parity for creation, editing, approvals, sending, administration, and exit
• Objects, IDs, relationships, and separate state groups
• Technical source, revision, assumption, approval, and validity traceability
• Price, discount, tax, tariff, subsidy, finance, terms, and override controls
• Template, immutable proposal version, withdrawal, and archive
• Mobile permissions, BYOD, local data, device loss, and offboarding
• Offline, sync, conflict, retry, replay, reconciliation, and audit
• Generation, preview, PDF, web-link, print, and accessibility tests
• Recipient, consent, channel, delivery, fallback, and customer-state evidence
• Privacy, security, incident, processor, retention, and deletion review
• Synthetic failure pilot, TCO, contract, renewal, export, and exit

A useful mobile proposal workflow makes controlled work available on smaller devices. It should never shrink technical, commercial, privacy, or audit responsibility.

Frequently asked questions

What is a solar proposal app?

It is a mobile or mobile-accessible workflow for creating, reviewing, approving, generating, previewing, sending, and retrieving solar proposals. Verify whether it is native Android, native iOS or iPadOS, a PWA, or a responsive browser service on the exact target device.

Can a solar proposal be created entirely on a phone?

Possibly, but only a target-device test can prove task parity. Creation, technical editing, commercial editing, approval, rendering, sending, administration, export, and deletion may differ by operating system, browser, plan, role, region, and release.

What should be locked before a solar proposal is sent?

Lock the project, design revision, equipment, BOM, production source, price, discount, tax, tariff, subsidy, finance, warranty, exclusions, terms, validity, template, proposal version, recipient, and approval evidence. Withdraw superseded documents and links.

How should offline proposal editing be tested?

Use synthetic records to test offline creation, edits, attachments, preview, queued actions, reconnection, conflicts, duplicates, and out-of-order events. Also test expired sessions, updates, storage exhaustion, replay, reconciliation, recovery, and audit. Define the system of record and conflict rules first.

Does proposal delivery prove that a customer accepted it?

No. Generated, previewed, sent, provider-accepted, delivered, failed, viewed, accepted, signed, paid, won, installed, and satisfied are separate states. Capture evidence for each supported state without converting delivery or a link view into a sales outcome.

How should QuickEstimate mobile claims be evaluated?

Treat QuickEstimate pages as related-party first-party evidence. Verify the exact store, publisher, package, device, region, plan, role, permissions, and task parity. Test offline behavior, sync, delivery, security, pricing, contract, export, support, and exit through an authorized pilot.

Does SurgePV have a native mobile proposal app?

No native app claim is made here. Current first-party pages describe design, shading, generation and financial modeling, BOM, and proposal capabilities. Verify exact browser and device behavior. Do not infer CRM, offline, WhatsApp, e-signature, approval, or external integration.

What privacy controls should a proposal app have in India?

Map parties, purposes, notices, permissions, consent, recipients, subprocessors, regions, transfers, retention, deletion, rights, incidents, grievances, and audit. Treat Indian DPDP commencement as phased and date-specific. Qualified review must determine the actual duties for the deployed workflow.

How should buyers calculate solar proposal app TCO?

Include plans, seats, devices, proposals, templates, storage, messages, integrations, API, setup, migration, training, support, security, and backup. Also include taxes, overages, renewal, internal administration, export, archive, termination, deletion, and exit. Separate public, quoted, estimated, usage-based, and unknown costs.