Customer Portal

The customer portal is a public-facing page where your customers interact with your business online. It gives them self-service access to view proposals, request estimates, pay invoices, leave reviews, and share referral links -- all without calling your office. The portal is branded with your company identity and accessible at a permanent URL that you share on your website, social media, business cards, and marketing materials.

V2 rollout note: The signed-in V2 account currently provides the secure history, service requests, estimate acceptance, and invoice/payment center described under Authenticated Customer Account. The broader public portal, reviews, referrals, feature settings, and other capabilities in this guide describe the established V1 experience and remain the V2 parity target unless a section explicitly says they are available in V2.

Portal URL

Your portal is available at:

app.cleanestimate.pro/portal/your-slug

The slug is your unique business identifier, set during onboarding. It appears in all portal links shared with customers. For example, if your company is "Sparkle Clean Pros" and your slug is sparkle-clean, your portal URL would be:

app.cleanestimate.pro/portal/sparkle-clean

The slug cannot be changed after initial setup. Choose a short, recognizable slug that matches your business name or brand.

How Customers Access the Portal

Customers reach your portal through several channels. No account creation or password is required for most features -- customers identify themselves by entering their email address or phone number.

Public organization and offer pages, estimate requests, and shared referral booking links can be opened without exposing a customer's private account details. V2 customer-specific reviews, referral codes, reward activity, and history require the email-code sign-in described in Authenticated Customer Account. Any no-login customer lookup described below is historical V1 behavior, not a V2 way to retrieve private customer information.

Portal, estimate, and invoice links open as normal browser pages. CleanEstimate Pro no longer prompts customers to install the site as a Chrome app/PWA.

Legacy Clean Estimate V1 deployments may still use a magic link on their dedicated customer login page. Clean Estimate V2 uses the email-code flow described in Authenticated Customer Account below; /customer/login renders outside the signed-in portal shell so signed-out customers can always reach it.

Direct estimate, proposal, maintenance-plan, and payment links are signed automatically. Generic quotes plus the shared quote-core linked-estimate pages for residential, fleet, commercial building, and holiday-lights records now use the shared public quote URL instead of the older signed estimate-only route whenever that saved quote has a persisted public quote token. When a customer opens a link from email or SMS, CE Pro still routes them to the correct public page without requiring an office login.

Commercial linked-estimate sends now preserve that saved shared quote token more reliably too. When a fleet or commercial building proposal already has a persisted public quote token on its linked estimate, resend and preview flows keep reusing that same /quote/[token] link instead of silently downgrading to a temporary signed estimate URL.

Holiday-lights sends now follow that same rule. If the linked holiday-lights estimate already has a persisted public quote token, CE Pro delivers the shared /quote/[token] link to the customer first and only falls back to the older seasonal portal URL when the shared quote link is not available yet.

Those signed estimate, proposal, maintenance-plan, and payment links still depend on the server-side CUSTOMER_TOKEN_SECRET environment variable. Set that secret before you send live customer links, keep it stable across deploys, and rotate it only when you are prepared for previously sent signed links to stop working. Customer delivery tokens now include an expiry window, so older links will age out instead of remaining valid forever. Shared quote-core public links are stored separately on the quote record and do not use that same customer-token URL format for the base page itself.

Customer sends now also fall back to the workspace's configured public site URL when the older dedicated app URL setting is blank. That means quote, proposal, maintenance-plan, shared quote, and holiday-lights portal links can still be generated during normal deploy or config transitions instead of failing the send with a temporary secure-link error.

Office-side send failures are now categorized more accurately too. If customer-link setup is the real issue, CE Pro still shows the secure-link setup warning. But if the draft is missing proposal options, missing a maintenance plan, or the email provider itself is unavailable, the send flow now surfaces that specific delivery problem instead of incorrectly blaming secure estimate links.

Estimate sends are also now resilient to live schema drift in the estimate pricing columns. The delivery helper no longer depends on newer optional estimate columns being present on every production workspace before a quote email can be generated, so sends keep working during rollout windows where one workspace still has an older estimates table shape.

Shared /quote/[token] pages now keep their online actions interactive even if that signing secret is temporarily unavailable. Quote acceptance, proposal package selection, maintenance-plan acceptance, customer-facing PDFs, and deposit actions can validate directly against the saved public quote token on the linked estimate, so a customer or office preview opened through the shared quote link no longer falls back to a misleading read-only "approval unavailable" state just because the customer-token secret is missing.

That same shared-quote fallback now also keeps office send messaging aligned with reality. When a generic, asphalt, residential, fleet, commercial building, or holiday-lights quote already has a persisted public quote token, CE Pro no longer warns the office that the delivered link is "view-only" or that secure quote setup is incomplete just because CUSTOMER_TOKEN_SECRET is temporarily missing. The email still sends, and the shared quote page keeps using the saved public token path.

Residential proposal-option and maintenance-plan links also keep their own public-view context when they hand off to the shared quote page. That means package-option opens still count as proposal views, maintenance-plan opens still count as maintenance-proposal views, and the customer sees the same specialized tab first instead of everything being treated as one generic quote open.

Portal proposal lookup and customer estimate lists now classify those mirrored residential package and maintenance offers from the shared quote-core offer layer too. Even after CE Pro moves proposal-option or maintenance-plan data off the parent estimate JSON, customers still land on the right public page from the portal instead of seeing a plain estimate link.

That same shared offer classification now also drives the customer dashboard and customer estimate list links directly. If a residential record is really a package proposal or maintenance offer, those summary cards now open the matching proposal or maintenance view instead of always defaulting to the base estimate link.

Authenticated Customer Account

Clean Estimate V2 customers sign in at /customer/login with the exact email address saved on an active customer contact. CE Pro emails an eight-digit, single-use code that expires after 10 minutes. This customer identity is separate from staff sign-in and never creates a team or organization membership.

When a signed-in account link points to a specific customer page, the email- code flow keeps that destination through verification and opens it after the session is created. A direct visit to the login page still opens the customer account Home page. For safety, CE Pro accepts only relative /customer account destinations; an external, malformed, encoded-bypass, or altered return address is discarded and the customer opens Home instead. The saved destination is short-lived and is cleared when verification finishes.

The V2 resolver allows one email to cover several customer/property records inside the same provider workspace. If that email maps to more than one provider, sign-in fails closed and the response does not disclose which accounts exist. A provider should give that customer the original secure estimate link or assign a provider-specific customer email before account access is retried.

Each 30-day session is bound to the exact customer records resolved when the email code is verified. If an office later adds or removes a customer record for that email, the existing session closes instead of silently widening or changing access; the customer verifies a new code to establish the updated scope. Acceptance and deposit checkout repeat that session-binding check after locking the estimate or acceptance, so a contact deactivation, customer reassignment, logout, or other scope change cannot race an already-open page and retain the removed authority. Identity-changing office statements lock only their affected provider workspaces in a stable order, then lock every affected email in a stable order; customer actions take the shared gate for their provider and their exact email lock. This covers deactivation, reassignment, deletion, newly matching emails, customer-location changes, and bulk edits without making an unrelated provider wait.

Invoice Checkout revalidates that complete identity inside the payment transaction. Contact deactivation, customer reassignment, email changes, and service-location access changes serialize with the checkout action, so a session that loses authority cannot race the change and create a payable link from its previous scope. The portal session remains a service-only credential: the staff application database role is not granted access to customer-session rows. CE Pro performs the session check, current customer-scope check, invoice ownership check, and payment locks together in the explicit customer service transaction.

Verifying another code replaces the previously active session for that email, including when two valid codes are submitted close together. Only one active browser session remains for that provider and customer scope.

The V2 account shows only records that already exist in the safer V2 data model. Estimate acceptance and deposit/invoice Checkout are controlled money writes; service requests, customer messages, and appointment-change requests are controlled workflow writes. Existing history remains immutable from the account:

When you switch the selected service property, Documents, Invoices, and Work reload for that property. Their lists, paging, loading and error states, and appointment actions reset with the new selection, so results from the previous property do not reappear.

Post-job retention status: An eligible signed-in customer can review one completed job's exact issued-invoice scope on its paid invoice detail or from the protected Work link in the post-job review and next-service follow-up message when the app URL is configured. Rebook this exact work asks the customer to choose explicitly between Pay after the next service and, when enabled and available, Prepay this exact work. On a new request, there is no preselected charge. Pay later creates one retry-safe office request and charges nothing. Prepay opens Stripe-hosted Checkout for the frozen issued-invoice total; it does not calculate new browser pricing or confirm an appointment. The office still confirms scheduling in both cases.

An unfinished repeat-work command saved by an older browser before the payment choice existed keeps its original notes and decision/request keys. CE Pro unlocks the choices and waits for the customer to select pay later or prepay, then upgrades that same saved command with the explicit choice. It does not silently default the old attempt to pay later. If the server already has a resumable prepayment, that server-fixed choice wins and only prepay is available to continue.

If a first prepay attempt is definitively unavailable before the server accepts it, CE Pro discards that uncommitted browser command, refreshes server truth, and reopens the payment choices—including pay later. No accepted server order or payment is changed; an accepted, open, or processing prepayment remains prepay-only. Before a new acceptance, the card shows the frozen line items plus subtotal, discount, tax, original invoice total, and exact offer expiration. A changed, replaced, or ineligible source—and an already-requested source without its exact resumable checkout—is withheld rather than silently switching scope. A teammate with Manage invoices enables exact-work prepay separately with Let customers prepay when rebooking the exact completed work under Settings > Customer payment offers. The control defaults off. Even when enabled, CE Pro shows prepay only while Stripe is configured, the connected account can accept charges, and the frozen total is inside Stripe's charge bounds.

Returning from exact-work Checkout never proves payment by itself. CE Pro re-reads the registered payment: an open Checkout stays resumable and shows only the already-chosen prepay path, an asynchronous payment shows processing, and only a verified Stripe settlement shows paid. Cancelling returns to the same frozen offer without creating a duplicate order; retrying reuses a compatible live session or safely replaces an expired one. A late success from a replaced or cancelled session always remains in the payment ledger. When it is the first applied payment, it settles the order and expires other payable attempts; otherwise it stays an unapplied duplicate and records a conflict. Any additional attempt still pending or successful holds fulfillment for payment or refund review, and database guards prevent job creation or progression until it is failed, cancelled, or fully refunded.

If Stripe reports that the applied exact-work prepayment was partially refunded, Work shows Prepayment needs office review instead of Prepayment received. The office must resolve the remaining balance before the work can be created or continue; the customer cannot reopen pay later, start another Checkout, or submit a second payment.

On a Refund attention row, the office refund button appears only to a teammate who has Manage calendar, Manage invoices, and Issue refunds. The dialog requires a 1–1,000 character reason and displays the payment's full remaining balance. The server re-derives that amount and the pinned connected account and PaymentIntent; the browser cannot choose them. An ambiguous or provider-pending response keeps the same durable command and Stripe attempt available for a safe same-key retry. Another currently authorized teammate can retry that command; its original actor, amount, reason, provider account, PaymentIntent, and command idempotency stay frozen. After an exact Stripe failed or canceled result, the next authorized retry advances that same command to a fresh durable provider-attempt key; it never creates a second command. Staff with both financial permissions see the original reason read-only before retrying, while calendar-only users do not receive the command identity, status, or reason. CE Pro shows a successful refund and refreshes the queue only after Stripe confirms the expected amount and PaymentIntent, or exact registered provider truth proves the exact scoped payment is fully refunded while the matching command remains unresolved. In that external-completion case, CE Pro supersedes the saved command locally without sending Stripe another refund request. A refund never creates a job.

An applied payment can be refunded after materialization only while its exact linked job is Unscheduled, Scheduled, or In progress; a Complete or Cancelled job cannot start that governed refund. Stripe runs first. If the provider does not confirm the refund, the same saved command remains retryable and the linked job remains active but blocked from moving forward. A provider-reported partial refund on the applied payment returns active or not-yet-materialized work to Refund attention with the remaining balance. It blocks job creation, scheduling, rescheduling, start, and completion until the money is resolved; a scheduled job can still be pulled back to Unscheduled for review. After provider success, CE Pro finalizes the money record and cancels that exact job in the same local transaction, using the refund reason and the normal job-status audit. If a full applied refund completes outside CE Pro while its matching refund command is unresolved, retrying that command reconciles registered provider truth and cancels an eligible linked job in the same local transaction without another Stripe request. Without a matching unresolved command, Refund attention keeps the Existing job link until the office reviews and cancels that job. Refunding only an extra duplicate can return the valid settled request to office review after every other attempt is resolved; it never cancels the valid linked job. A late duplicate cannot create a second job, and a pending or failed refund command blocks both initial job attachment and forward job progression until the money action reaches a resolved state.

Ready pay-later requests and settled prepayments appear in the office Repeat-work requests queue (Jobs workspace) with the frozen customer, property, scope, invoice, amount, and payment state, plus the customer's phone, email, and a link to their client profile. Every accepted offer -- including a prepaid rebook once its payment settles -- raises an office alert. A teammate with Manage calendar creates one unscheduled job; payment never schedules it automatically, and the customer cannot pick their own appointment date from any of these post-job offers -- the office always reaches out to coordinate the service date first. Refund-attention rows cannot be materialized until the money state is resolved. Creating the job reconciles the linked intake lead to the pipeline's single active Won stage. A custom pipeline with no unambiguous Won stage keeps the lead unchanged and records a durable reconciliation event rather than inventing a stage change. That event is not, by itself, a delivered office notification.

For commercial work, Request a custom maintenance proposal asks the office to prepare recurring options. It does not create or accept a maintenance plan and does not charge the customer.

For eligible residential work, an organization can separately enable Offer Suds Club after completed residential work. The protected Work card then shows the one server-priced plan for that property, including each included service and season, the signup amount, later monthly payments, and tax-inclusive year total. Joining opens Stripe-hosted Checkout. Returning from Checkout first shows Suds Club signup received while the payment is pending; only verified Stripe settlement changes the status to Suds Club is active and releases recurring service. Cancelling Checkout returns to the same Work offer. A retry resumes the same accepted plan and replaces an expired Checkout session instead of creating a duplicate membership. If the offer's original display window has already elapsed, Work shows only the pending Suds Club continuation; expired rebooking and other offer choices do not reopen. The invoice and follow-up surfaces both resolve that continuation to the exact accepted plan and price rather than another surface's older display. Verified settlement closes that continuation.

These post-job controls are independent from the existing organization-controlled invoice Pay offer sequence. Joining Suds Club does not turn a same-work request into a charge or appointment, and commercial work continues to offer only an office-reviewed custom maintenance proposal. There is no native mobile UI change.

When an exact-work request becomes a job, Work and the Home page's nearest upcoming visit keep showing the repeat order's frozen service property. A legacy estimate or plan property keeps its established precedence only when it agrees with that retained scope; a conflict is withheld instead of showing the customer the wrong address.

The Messages badge also follows server refreshes while the customer account shell remains open. If a confirmed office reply arrives while another portal page is polling or refreshing, the new count appears without requiring the customer to sign out or remount the account navigation; an in-browser read acknowledgment still clears the matching count immediately.

Invoice and payment rows expose only allowlisted customer-safe method labels and ledger facts. A staff-entered payment reference or note remains office-only and is not returned to the signed-in account, bearer invoice, or PDF.

Home resolves the nearest upcoming visit independently from the newest Work page, so a customer with a long future schedule still sees the actual next appointment. Date-only scheduled visits keep their saved calendar date. Estimate sends, acceptances, completed work, invoices, payments, documents, and messages display their event date in that record's service-location timezone. Estimates, Work, Documents, Invoices, Payments, and Messages load the 25 newest records first and expose a matching Load older control until the complete customer-scoped history has been returned. Stable date/time-and-ID cursors prevent duplicate or skipped records when multiple events share a timestamp or calendar date. The Home open-estimate total comes from a separate complete count of current, sent, unexpired revisions, so it remains accurate even when more open estimates exist than fit on the first Estimates page.

Internal notes, team-only messages, drafts, unrelated customers, and records from another provider are filtered at the data boundary. Unknown and ambiguous emails receive the same generic login response as known emails. Consent-blocked, missing-contact and failed outbound attempts are also kept out of customer history, because those never reached the customer at all. The test for inclusion is that the provider accepted the message — not that it was confirmed delivered — and the two channels then diverge sharply after that point. An accepted email goes on to earn a real verdict: Resend reports confirmed delivery, and reports a bounce, a complaint or a delay just the same, all of which reach the office on the Inbox thread. An accepted text earns nothing further, because no delivery report is ever sent for SMS, so acceptance is the last thing CE Pro learns about it.

Both kinds appear in customer history, and the customer's own view does not distinguish them — the portal shows what the office sent, not the office's delivery evidence for it. What differs is what the office can find out afterwards, which is why the same message can be marked as bounced on the Inbox thread while still appearing in the customer's history: the record of having sent it and the verdict on where it landed are two different facts. When a client has multiple contacts, each signed-in contact sees only messages attributed to a contact carrying that exact email. Proving one contact's email does not expose another contact's message bodies, and unattributed legacy messages remain hidden.

From Messages, a signed-in customer can choose an authorized service location and send up to 2,000 characters to the office. The message appears as normal inbound activity in that location's shared office Inbox, where an authorized teammate can answer through the existing provider-backed email workflow. The saved message subject includes the selected service address so the office does not have to infer which property the customer meant. Portal messages are labeled Portal in customer history; Clean Estimate does not claim an external email or text was sent when the customer used the portal form. If the account has no active service property, Messages explains that the office must add one instead of showing a composer that cannot submit. Properties whose service-location assignment or operational location has been deactivated are treated as unavailable on the page as well as at submission.

The active customer session, client, property, location, contact, and exact authenticated email are checked again inside the write transaction. A stable request key makes a retry return the original message instead of creating a duplicate, changed content cannot reuse that key, and the same-origin endpoint is rate-limited. Text entered for a follow-up while an earlier send is still finishing is preserved. Internal notes and staff-only delivery direction remain hidden from the customer before and after the reply.

New office email and text messages show an unread badge on Messages and a New marker in customer history. Read state belongs to the exact authenticated portal email rather than one browser session, so a message read on one signed-in device stays read after the customer verifies a new code elsewhere. The browser acknowledges only message IDs it actually rendered, and the service stores those exact per-message acknowledgements. An office reply that arrives while the page is opening remains unread for the next refresh. A previously failed or queued message also appears as new if the provider later confirms it was sent, even when that message record was created before other messages the customer already read. Customer portal form submissions are the customer's own inbound activity and never create a false unread badge.

The signed-in account does not mint or reconstruct proposal tokens. Its verified provider and customer scope authorizes the same immutable current proposal revision directly. The original secure estimate link from email or SMS remains valid; whichever surface accepts first creates the one authoritative acceptance, and the other surface then shows that result.

When the saved option roles are unambiguous, both the signed-in account and the delivered public proposal present the familiar offer story from left to right among the choices that exist: As requested, then Suds Club / maintenance plan, then More coverage. A one- or two-choice estimate does not show empty placeholder cards. An all-one-time neutral set keeps its complete office-authored order and uses neutral Option badges instead of inventing roles. For a legacy exact three-card set with one maintenance choice and two otherwise neutral one-time choices, Clean Estimate deterministically treats the first authored one-time choice as As requested, places Suds Club / maintenance plan in the middle, and labels the remaining one-time choice More coverage. An explicit As requested, As quoted, or original-scope label always wins over a generic label containing “one-time,” even if that generic choice was authored first.

Every choice shows its customer-safe included scope before the signature controls. A maintenance choice also shows its saved agreement cadence by year, seasonal visit, included service, and allocated visit value. The customer must affirmatively select a choice, enter their name, sign, and accept. Maintenance choices use their frozen signup schedule, including any upfront amount, instead of the one-time proposal's generic deposit rule.

If the signed choice requires money up front, the account opens Stripe Checkout for the exact outstanding amount and returns to the same signed-in estimate. Customer ownership and the active session binding are rechecked while the acceptance and estimate are locked. Any extra live Checkout sessions are expired before one compatible session is reused or a replacement is created, preventing two independently payable deposit sessions. Every Stripe payment record snapshots the connected account where the object was created. A monthly maintenance plan also freezes the account that owns its customer, schedule, invoices, and refunds. Expiry, completion, delayed failure, recurring invoice, cancellation, and refund handling all require that account plus the exact provider and payment record, so reconnecting a provider does not move an existing Checkout session and an identical account-scoped Stripe ID in another provider cannot be changed. Settled deposit records reduce the amount still collectible, completed deposits cannot be collected a second time, and refund evidence directs the customer back to the office instead of silently treating returned money as permission to charge again. Manual office resolution likewise remains final for portal checkout. If Stripe refuses an expiry request, Clean Estimate confirms that the hosted session is actually expired before changing its local state. An open, complete, unknown, or unreachable session blocks replacement or manual resolution so a second payable path cannot be created. The acceptance reminder appears only while that proposal is still sent and unexpired. Accepted, declined, expired, withdrawn, and reopened-draft records do not advertise an action the secure proposal flow would reject. The Home open-estimate count and signed-in estimate/document status use the same current-revision expiration check, even before a later write persists the estimate's expired lifecycle state.

Notification Preferences

From Account, a signed-in customer can choose email, text, both, or neither for each supported optional update:

• Estimate follow-ups -- reminders sent after the original estimate while

it is still awaiting a decision

• Appointment updates -- upcoming appointment reminders and schedule

changes

• Reviews and next-service follow-ups -- post-job requests for feedback and,

when eligible, a protected link to review same-work or maintenance options

The choices belong to the exact signed-in portal email identity and apply across every customer/property record that identity can access. Two people who share one customer record keep independent choices and cannot overwrite each other's settings. New identities default to both channels enabled. If the office later links another customer/property record through the same exact portal email, that property uses the identity's existing opt-outs immediately instead of silently restarting optional messages.

If several portal email identities share the exact contact and phone number selected for a text, Clean Estimate honors every identity's text preference. One person's opt-out cannot be bypassed because another email on that shared contact remains enabled.

These controls do not suppress an estimate or invoice the office explicitly sends, payment receipts, or a direct reply from the team. SMS STOP and email unsubscribe consent continue to apply independently and can still block a message even when an optional notification switch is enabled.

Preference saves revalidate the active 30-day portal session and its complete customer binding in the same transaction. Each optional automated send checks the saved choice when it claims the message and again while holding the choice stable through provider acceptance. If the customer disables a channel while a send is queued, Clean Estimate records the attempt as preference-suppressed and does not call the email or text provider. Suppressed attempts are not shown as delivered customer history. The exact email destination frozen when the message is claimed, or the exact portal-email identity set frozen for a text, remains authoritative at that final check even if an office edit concurrently deactivates the contact or changes/removes its email methods.

This foundation does not yet claim all established V1 portal capabilities. Invoice history, invoice PDFs, online invoice payment, immutable receipts for settled invoice payments, guarded appointment change requests, service requests that enter the normal office lead pipeline, direct customer portal replies with photo and document attachments, notification preferences, cross-device customer unread state, and optional office-enabled payment offers on the way into invoice checkout (see Invoices and Payments), hosted saved-card setup and management, and secure lead appointment self-booking are now available. Richer messaging tools, reviews, referrals, and configurable portal branding/settings stay on the V2 parity backlog until their durable V2 records and authorization contracts exist. Empty tabs explain the missing record type instead of showing sample data or actions that cannot complete.

A link to one quote still does not unlock the customer's full account. The public secure link can show only that quote; account history requires the separate email-code sign-in.

Requesting Service

From Home, select Request Service. The form preserves the established V1 choices and wording:

1. If the account has several properties, choose the Service location.
2. Under What do you need?, choose House Wash, Driveway Cleaning, Roof

Cleaning, Gutter Cleaning, Window Cleaning, Deck/Patio Cleaning, Fence Wash, Holiday Lights, Commercial Building Cleaning, Fleet Washing, Pressure Washing, or Other.

1. Optionally choose a Preferred date and add up to 2,000 characters of

customer notes.

1. Select Send request. The confirmation reads **Your request has been

received. We'll be in touch shortly.**

The request creates one normal lead with source Customer portal and assigns it to an eligible office teammate, preferring the workspace owner. Holiday Lights requests follow the normal Holiday Lights routing rule when one is configured; other services follow the workspace's default pipeline. The lead detail page preserves the requested service, preferred date, original notes, and received time so the office can qualify the request and create the right single-screen estimate. Pipeline, routing-rule, and entry-stage selection is bound explicitly to the customer's organization even when the request runs through the customer-service connection, so another workspace's routing setup cannot reject or redirect it.

A preferred date is a customer preference, not a confirmed appointment. The request does not occupy the shared calendar. Office staff choose the actual date, start/end times, and appointment assignee through the normal lead scheduling controls after confirming availability.

Each browser submission carries a one-time request key. Retries return the original lead instead of allocating a duplicate. The server rechecks the signed-in session and current property scope inside the same transaction as the lead and immutable request receipt; a forged or newly inaccessible property is refused. Responses are private/no-store, same-origin protected, and limited to six submissions per customer session and property every 30 minutes.

Requesting an Appointment Change

An eligible upcoming scheduled job in Work includes Request appointment change, which opens the customer change-request form. The customer can:

1. Request a future date and optionally choose morning, afternoon, or no time preference.
2. Request cancellation instead of a new date.
3. Add a short reason for the office.
4. Select Send request.

Sending the form does not reschedule or cancel the job. The current date, status, crew, and route remain authoritative until an authorized staff member decides the request. Only one pending request can exist for the same job; repeated sends reuse it instead of creating duplicates. The office must enter an exact arrival time before approving a reschedule, and an intervening office schedule change wins instead of being overwritten. Pending and final outcomes remain visible on the job card.

See Managing Jobs for the office review workflow.

Viewing Estimates and Proposals

Customers can look up their proposals through the portal's Proposals tab.

How It Works

1. The customer navigates to your portal URL.
2. They select the Proposals tab.
3. They enter the email address used on their estimate or proposal.
4. CE Pro checks for matching live proposals and estimates in that workspace, then emails secure links instead of rendering proposal data directly in the browser.

What the Customer Sees

After they submit the form, the portal shows a confirmation state:

• If matching live records are found and email delivery is available, the customer receives secure links in their inbox.
• If no matching live records are found, the portal keeps the response generic instead of exposing whether that email belongs to a customer.
• If email delivery is temporarily unavailable, the portal asks the customer to retry instead of falsely claiming links were sent.

Opening a secure link from that email takes the customer to the full proposal or estimate view, which includes:

• Detailed service descriptions with scope of work.
• Line-item pricing breakdown.
• Multi-option selections if the proposal includes tiered pricing (e.g., Basic, Standard, Premium).
• Package discount details if applicable.
• Terms and conditions.
• An Accept button with e-signature capture.
• A Download PDF option for the customer's records.

The shared viewer adapts the scope without changing the surrounding customer experience:

Every version uses the same branded frame and gives the customer a clear path to Estimates, Work, Documents, Payments, and Messages after account sign-in.

Residential quote choice page

Eligible residential estimates use the shared three-choice proposal on the secure hosted quote and in the signed-in V2 account. Both surfaces use the same immutable choices, acceptance, signature, and deposit record:

• As requested shows the original one-time services and saved total.
• Suds Club is the middle, recommended maintenance choice and shows its

saved payment terms, seasonal visit schedule, and covered services.

• Complete Property Care shows the expanded, separately measured one-time

scope, discount, tax, and total.

The saved card order is As requested, Suds Club, then Complete Property Care. Office-authored Option A/B/C proposals keep their explicit saved names and positions instead of being forced into this generated order.

The page then shows a side-by-side comparison, real project photos when the estimate has them, and one final review. Selecting a package updates that review; nothing is approved until the customer signs. A fixed Review and sign bar keeps the selected choice and price visible on phones without bringing back the older tabbed estimate screen.

After approval, the same page opens the payment step when the signed choice requires an upfront payment or deposit. In the established V1 portal, earlier work, invoices, service requests, documents, and messages remain in the signed-in customer account rather than crowding the quote decision page. The current signed-in V2 account shows Estimates, Work with guarded appointment change requests, proposal-revision Documents, Invoices, recorded Payments with immutable invoice-payment receipts, and customer-visible Messages.

On the exclusive hosted three-card flow, a selected Suds Club choice collects only that membership's signup price plus applicable tax at approval; selecting either one-time card uses only that option's saved deposit terms. Future monthly Club dues stay separate from the signup payment and approval balance.

The established mobile Close Kit and legacy flows can still present an explicit combined one-time-and-membership choice. Only in that combined flow does the amount due include both the one-time deposit and Club signup; its checkout and printable estimate break out those components separately.

Accepting a Proposal

When the customer clicks Accept, a signature pad and signer-name field appear. The name is prefilled from the estimate, remains editable when a different authorized signer is present, and is required before acceptance. The customer signs using their mouse, trackpad, or finger (on mobile devices). After signing:

1. The proposal status changes to "Accepted."
2. You receive a notification that the proposal was accepted.
3. The customer sees a confirmation screen.
4. A job record is created in your system automatically.

Office staff can also use the admin-side View Public Page preview to walk through the same signature flow while signed in. CE Pro now honors that authenticated office preview path instead of requiring a separate customer token just to verify the acceptance experience from admin. Shared quote-core public pages now inherit the workspace organization name in the header too, so customers see the office brand instead of a hardcoded product label when they open a shared estimate or quote link.

That office preview path now resolves through the same valid customer-link contract across residential estimates, package proposals, maintenance plans, fleet proposals, commercial building proposals, holiday-lights linked estimates, generic quotes, and asphalt quotes. If an internal teammate opens an older raw public route while signed in, CE Pro now hydrates the same interactive approval token the delivered link would have used instead of falling back to a read-only "approval unavailable" state.

Signature capture is now hardened across all three public acceptance pipelines too: shared estimate and quote links sign through the shared estimate-sign route, fleet and commercial building proposal pages self-heal missing signature-storage buckets before retrying the upload, and holiday-lights contract signing keeps using the inline contract signature fields. That keeps online approval reliable across estimate, proposal, maintenance-plan, and holiday contract flows instead of each module depending on a separate fragile signature setup.

If the customer adds notes or requests changes before signing, those comments are saved on the estimate record so your team can review them in the admin estimate detail view.

This eliminates the back-and-forth of emailing signed documents and accelerates the time from proposal to scheduled job.

Paying the Estimate Deposit

For quote types that use the standard estimate approval flow, approval and payment are separate steps. The customer can sign and approve a quote even when the deposit will be handled later. When the signed terms call for a deposit, payment choices appear beneath the approval confirmation on the same page.

The embedded form provides two tabs:

• Card for a credit or debit card. A successful card payment confirms on

the estimate page immediately.

• US bank account for ACH. The estimate page confirms that the payment was

submitted while the bank transfer is processing, and the payment record updates automatically when Stripe reports the final result.

CE Pro calculates the required deposit on the server from the current estimate balance and the payment schedule saved with the signed quote. Residential quotes use the standard 25% residential deposit; Holiday Lights and option-based proposals use the percentage or amount in the selected, signed offer. CE Pro does not guess a deposit for a quote that has no structured payment schedule. The public page cannot change the amount by altering browser data. If the deposit was already paid, reopening or retrying the form recognizes the existing payment instead of collecting it again. Customers who are not ready to pay can select Pay later without undoing their acceptance.

Standard estimates, package selections, and customer-customized residential proposals with a saved payment schedule use this same inline flow. Stripe's Payment Element handles the card and bank details; CleanEstimate Pro does not receive or store full card or bank-account numbers.

Legacy fleet and commercial proposal approval remains sign-only in the shared viewer. The office collects its deposit from the linked estimate or invoice; those legacy proposal pages do not open the inline deposit form.

The customer can also choose Pay another way and select check, cash, Venmo, bank transfer, money order, or another office-approved method. That creates a pending deposit request; it does not mark the estimate paid. The accepted quote remains valid while the deposit is pending. After the money arrives, the office records the amount, method, and a safe reference or memo; CE Pro timestamps the entry and updates the balance and receipt history.

If the customer changes back to online payment, CE Pro recalculates the amount before opening a fresh payment form. It does not reuse an older payment session that may have been opened before the offline arrangement.

Requesting an Estimate

The estimate request form turns your portal into a lead generation tool that operates around the clock.

The Request Form

Customers fill out a form with:

• Contact information -- Name, email address, and phone number.
• Property address -- With optional autocomplete for faster entry.
• Services of interest -- Checkboxes for the service types you offer (house wash, gutter cleaning, window cleaning, etc.).
• Additional notes -- A free-text field where the customer can describe their specific needs, timeline, or concerns.

What Happens After Submission

When a customer submits an estimate request:

1. A new lead is created in your pipeline automatically.
2. The lead source is tagged as "Portal" so you can track portal-generated leads separately.
3. You receive a notification (email or in-app, depending on your notification settings).
4. The customer sees a confirmation message thanking them for their request.

This means a homeowner who visits your website at 10 PM on a Saturday can submit their request immediately. Without the portal, that lead might forget to call on Monday morning.

Response Time

Portal estimate requests are warm leads -- the customer actively sought you out and took the time to fill out a form. Respond within one hour during business hours for the best conversion rates. Configure notifications to alert you immediately when a new portal request arrives.

Making Payments

Customers can pay outstanding invoices directly through the portal. Payments are processed through Stripe, so your Stripe integration must be connected before enabling this feature.

Payment Workflow

1. The customer navigates to the Pay tab on your portal.
2. They enter their email address or invoice number.
3. The portal displays their outstanding invoices with amounts and due dates.
4. The customer selects an invoice and clicks Pay Now.
5. A Stripe-hosted checkout page opens for secure card entry.
6. After successful payment, the invoice status updates to "Paid" automatically.
7. Both the customer and your team receive a payment confirmation email.

Benefits of Portal Payments

• Faster collection. Customers pay immediately without writing a check or calling to read a card number over the phone.
• Reduced friction. The fewer steps between "customer wants to pay" and "payment received," the faster your cash flow.
• Automatic reconciliation. Payments update your invoice records automatically. No manual data entry.
• Security. Stripe handles all card data. You never see or store credit card numbers.

Payment Methods

Stripe supports credit cards, debit cards, and (depending on your Stripe configuration) ACH bank transfers and digital wallets like Apple Pay and Google Pay. The available payment methods are determined by your Stripe account settings.

Leaving Reviews

In V2, customer-attributed reviews require the customer to sign in through Account > Share your experience. The review is tied to the signed-in customer's verified portal identity and selected service location/property, then stays unpublished until the office approves it. The legacy public review route provides branding and Google-link discovery only; submissions receive a sign-in handoff and do not look up a customer by email.

The detailed no-login submission flow below describes the historical V1 experience, not the current V2 review route.

Review Flow (signed-in customer)

1. The customer opens Account > Share your experience in the portal.
2. They confirm the service location (when they have more than one), enter

their name, and select a star rating from 1 to 5.

1. They write optional feedback (up to 2,000 characters).
2. They submit the review and see **Thank you for sharing. Your review was

sent to the office. It will stay private until the team reviews it.**

Historical V1 Public Review Page

In V1, a public no-login page accepted review submissions after an email matched an existing customer record. This is historical V1 behavior and is not the current V2 submission flow. In V2, the public route exposes branding and Google-review discovery; a submission hands off to customer sign-in.

In V1, every public review was saved unpublished and needed office approval before it could be treated as a public rating. After a V1 submission, the customer saw a thank-you screen and, when configured, a Leave a Google Review button linking to the business profile. This was the public no-login flow; V2 reviews instead begin from signed-in Account > Share your experience and stay private until office approval.

In V1, the review-request automation linked directly to this public page when the public web address and Reviews setting were configured. For the current V2 review flow, use the customer sign-in handoff to reach the account review form.

Using Reviews Effectively

• Send a follow-up message with a portal review link within 24 hours of completing a job, while the experience is fresh.
• Respond to all feedback, positive or negative. Customers who leave low ratings through the portal are giving you a chance to fix the problem.
• Track your average rating over time. A declining trend signals a service quality issue.

Sharing Referral Links

In V2, a customer's personal referral code and reward activity require customer-portal sign-in. Public referral lookup can show organization and offer discovery, but an email query does not reveal personal codes or reward totals. A signed-in customer can access their referral summary, and shared referral booking links remain public and carry the code to the booking flow.

The no-login email lookup steps below describe the historical V1 experience, not the current V2 identity boundary.

Historical V1 Referral Lookup

CE Pro uses the customer's email address to protect referral credit and keep the page from turning into an open public lead form.

• If the customer already has a referral code, entering their email immediately shows their existing share link and stats.
• If the email matches an existing customer but they have never used referrals before, the page asks for their name once and then mints a shareable code (format REF-XXXXXX).
• If the email is not tied to an existing customer record, CE Pro blocks the request instead of letting an unknown visitor create a referral code.

The page shows your configured referral offer text (for example, "$25 off your next service") above the lookup form when your account has one saved.

Historical V1 Referral Activity

In V1, the no-login flow let the customer copy or share a personal referral link; a referred prospect could open the link and reach the booking page with the referral code carried in ?ref=. The referral stayed pending until the lead's estimate was accepted. Returning customers could look themselves up again by email.

The V1 referral page showed total referrals, conversions, rewards, and reward amounts. Those personal codes and reward totals are not public in V2; the customer signs in to view their referral summary. Shared booking links remain public and carry their existing referral code. In the office, open the client's profile and select the Referrals tab to review referral records; see Client Profile for the office-side reward workflow.

Holiday Lights Portal Tab

If your account has the Holiday Lights module enabled, the portal automatically includes an additional tab for holiday lighting.

Customers can:

• View their holiday lighting proposal with design details.
• See mockups showing how their property will look with lights installed.
• Review zone configurations and light specifications.
• Accept the holiday lighting proposal with an e-signature.

This tab appears only when the Holiday Lights module is active. It is visible to customers who have an active or pending holiday lighting proposal.

Portal Branding

The portal displays your company branding to create a professional, consistent customer experience.

Branding Elements

• Company logo -- Displayed in the portal header.
• Brand colors -- Applied to buttons, headings, links, and accent elements.
• Company name -- Shown in the page header and footer.

If you have multiple brands configured in Settings > Brands, the portal uses your default brand. The branding ensures the portal looks like an extension of your company's website, not a generic third-party tool.

Configuring Portal Features

Go to Settings > Portal to control which features are available on your portal. Each feature has an on/off toggle.

Changes save automatically when you toggle a feature. For detailed portal configuration instructions, see the Portal Settings guide.

Sharing the Portal Effectively

The portal only provides value if customers know about it. Integrate the portal URL into every customer touchpoint.

Website

Add a prominent "Customer Portal" or "Pay Online" button to your website navigation. Place it in the header, footer, or on a dedicated customer resources page.

Print Materials

Include a QR code for the portal URL on:

• Business cards
• Door hangers left after estimates or jobs
• Yard signs placed during active jobs
• Vehicle wraps and magnets
• Flyers, brochures, and direct mail pieces

Email Communications

• Add the portal URL to your team's email signatures.
• Include portal links in estimate emails, invoice emails, and follow-up messages.
• Create a post-job email template that links to the review and referral sections of the portal.

Post-Job Follow-Up

After completing a job, send a follow-up that helps the customer reach:

• The signed-in Account > Share your experience flow for a private review

that stays unpublished until the office approves it.

• The invoice payment link when a balance is due.
• The signed-in referral summary for the customer's personal code and rewards;

the resulting shared booking link remains public.

This keeps V2 review and referral details behind customer sign-in while leaving the appropriate payment and booking links easy to open.

Tips

• Enable only relevant features. If you do not offer online payments through Stripe yet, do not enable the Pay tab. Empty or broken features erode customer trust.
• Test the portal from a customer's perspective. Open the URL in a private browser window and walk through each feature. Make sure everything works and looks professional.
• Mention the portal to customers. Technology only helps if people use it. Train your team to mention the portal during job completion and follow-up calls.
• Use the referral feature actively. Ask satisfied customers to refer a friend through the portal right after completing their job, while their satisfaction is highest.
• Respond to portal estimate requests quickly. These are warm leads. Aim for a response within one hour during business hours.
• Keep your Google Review URL current. If you change your Google Business Profile, update the URL in settings immediately.
• Track portal metrics. Monitor how many estimate requests, payments, reviews, and referrals come through the portal each month. This data justifies the effort of promoting it.

Troubleshooting

Portal page shows a 404 or "not found" error

Verify your portal slug at Settings > Portal. The URL must match exactly, including case. If the account was recently created, the portal may take a few minutes to become active.

Customer cannot find their proposal

The proposal lookup matches by email or phone number. The customer must enter the same email or phone number that was used when the estimate was created. If they use a different email, no results appear. Check the estimate record to confirm the correct contact information was entered.

Pay button is not showing on a V2 invoice

Open Settings > Payments (Stripe) and confirm the connected account can accept charges. The invoice must have been sent, must not be void, and must still have a positive ledger-derived balance. Draft, paid-in-full, and voided invoices intentionally have no payment action. If the customer is signed in, also confirm the invoice belongs to a service customer covered by that exact email-code session; company portfolio parents do not own invoices.

The customer's payment action remains Stripe Checkout. Authorized admins can separately record partial or split cash, check, ACH, external, and hosted-Stripe invoice collections and issue controlled refunds from the office invoice; the customer cannot self-report an offline payment. Embedded keyed-card entry, credits/write-offs, tips, and the remaining broader V1 collection tools remain parity work.

Google Review redirect is not working

Verify that the Google review link is configured under Settings > Portal, next to the Customer Reviews toggle. The URL must be the direct review link for your Google Business Profile, not your general business listing URL. You can find this link in your Google Business Profile dashboard under "Get more reviews."

Referral activity is not showing

In V2, personal codes and reward totals appear only after the referred customer signs in to the portal. Public referral pages show organization and offer discovery; they do not retrieve private details by email. Shared booking links can still carry a referral code into the estimate request. For V1, referral settings, public lookups, and lead-source troubleshooting are described above as historical behavior.

Portal looks unbranded or uses default styling

Verify that your company logo and brand colors are configured at Settings > Brands. The portal pulls branding from your default brand. If no brand is configured, the portal uses generic default styling.