Customer Self-Service

After the sale, a customer reaches the business through two doors: the portal (web or app) and the contact center (phone, text, email). Most of what they want is small: when's my next visit, can it be Thursday instead, what do I owe, change my card, the technician missed the garage. Every one of those handled in the portal is a call nobody has to answer, and service businesses run on thin margins, so self-service pays for itself quickly. The catch is that the portal is not a simpler product with simpler rules. A customer rescheduling their own visit has to obey the same scheduling constraints, billing rules and compliance windows as a dispatcher doing it for them, and the portal has to say no as clearly as a person would.

Signing In Without a Password#

Customers of a service business sign in a few times a year. A password they set at the door in June is gone by September, so password login mostly produces reset requests. The better default is a one-time code sent to a contact the business already knows: the primary mobile number or email on the account.

NIST's SP 800-63B is the reference for how to do that safely. It classes out-of-band verification over the phone network (SMS and voice) as a restricted authenticator: allowed, but with known risks such as SIM swaps and number porting, which the verifier should check for where it can. An out-of-band secret must be used within 10 minutes and accepted only once, and a verifier has to limit consecutive failed attempts (to no more than 100 by default, and fewer is fine). In practice:

• Six digits, short-lived, single-use. A new code invalidates the previous one. My default lifetime is 10 minutes, with a cooldown of a few minutes before another can be sent.
• Count failures per contact point, not per code. Sending a new code doesn't reset the counter.
• Don't reveal who's a customer. "If that number is on an account, we've sent a code" is the only response, whatever happened (Authentication).
• Login links for the first visit. The welcome message after a sale can carry a single-use link that signs the new customer straight in. Creating a newer link invalidates older unused ones, and every link expires.
• Then a normal session, in an HttpOnly cookie (Authentication), with re-verification before the sensitive actions: changing the login contacts or adding a bank account.

Changing the phone number or email used to sign in is changing the authenticator. Confirm the new one with a code sent to it, notify the old one, and record who made the change.

Households, Accounts and Roles#

The person who signed the agreement is rarely the only person who deals with the service. A spouse schedules visits, an adult child pays the bill, a property manager handles a rental. And one person can be on several accounts: their home and their rental, or every house a small landlord owns. So a portal login is a person, an account is the billing relationship, and the link between them carries a role (Customers, Accounts & Properties has the data model):

Role	Can do
Owner	Everything, including inviting others and anything contractual
Manager	Schedule, pay, update payment methods, invite editors and viewers
Editor	Schedule visits and update contact details
Viewer	See visits, invoices and service history

• Ownership isn't invited. An invitation can grant any role except owner. Changing who owns an account is a contract question, and it's done by staff with a record of why.
• Invites expire and can be resent, with a cooldown, and re-inviting the same address updates the pending invitation rather than creating a second. Inviting an address that already belongs to a person links that person instead of creating a duplicate.
• After sign-in, pick an account. Someone on three accounts chooses which one they're looking at, and every request after that is authorized against that account and their role on it, on the server, every time (Authorization).
• Messages follow roles. Service notices go to the person designated to receive them, not to everyone on the account (Customer Communications).

Staff Acting as the Customer#

When a customer calls confused about what they're seeing, the fastest fix is for the agent to see it too. Impersonation lets a customer service agent open the portal as that customer. It's also the most powerful support tool you'll build, so it gets the controls in Authorization:

• The session names both people. It carries the customer it acts as and the staff member behind it, and every action is recorded with both.
• It's visible. A banner says who is impersonating whom, and it ends on its own after a short time.
• It can't do everything. An impersonating agent shouldn't change the customer's sign-in contacts or see one-time codes; staff screens mask secrets in the message history for the same reason.
• It requires a reason, ideally a ticket or call reference, and a permission most staff don't have.

Scheduling for Themselves#

Customers want to move visits more than anything else, and it's where self-service is most constrained. The customer chooses a date and an arrival window, never a technician or a route. Behind the scenes the portal asks the scheduling system for openings that fit the visit's duration, the technician skills and licenses it needs, the routes' capacity and the service area, and tries candidate openings until one books (Booking Appointments has the mechanics). The customer sees "Thursday morning", and the system did the rest.

Some changes shouldn't be self-service at all, and the portal should say so and give the number to call:

• The account has to be in good standing. An active subscription, possibly past due, but not frozen for non-payment (Collections & Retention) and not cancelled.
• The first service is booked by people. It's usually longer, needs someone home, may need preparation instructions, and was often promised at the sale. Changing it is worth a conversation.
• Same-day and in-progress visits go to the office. By the morning of service the route is built and optimized (Route Optimization); moving a stop now affects a technician who's already driving.
• Free return visits have a window. Many agreements include a return visit if the problem comes back between scheduled services (pest control calls it a reservice). The portal can offer it only within the window after the last completed visit that the agreement allows.
• Locked routes and full days are answers, not errors. "No openings this week, call us at…" with the service center's number is a better result than a spinner.

Record the channel on every booking, so the portal's bookings, the office's and the technician app's can be compared, and let customers leave a note for the technician ("dog in the back yard", "gate code changed") that travels with the visit. Standing preferences, like mornings only or never Mondays, belong on the account, where the scheduler reads them for every future visit (Recurring Schedules).

Paying and Payment Methods#

The portal is where customers update the card that broke autopay, so it's where most recovered revenue comes from. Keep it out of PCI scope:

• Hosted fields from the processor. Card and bank details are entered into the processor's iframe or SDK and never touch your servers, which keeps a web portal in the simplest assessment, SAQ A (PCI DSS). The page that embeds them is still in scope: the PCI Council confirms that merchants embedding a provider's iframe still owe SAQ A's requirements, including external vulnerability scans by an approved scanning vendor. Wallets (Apple Pay, Google Pay) come through the same component.
• Bank accounts by verification. Linking a bank account through an instant verification flow beats typed numbers and microdeposits (ACH & Bank Transfers).
• One method can fund several subscriptions. A household with general pest control and a separate termite contract may pay both from one card or pay each differently. Show which method pays what, let the customer make one the default, and reassign it across subscriptions in one step.
• Don't strand a subscription. A payment method can't be removed while it's the only one paying an active subscription. Ask for the replacement first.
• Autopay is a per-subscription choice with clear terms about what gets charged and when (Stored Cards & Recurring Billing), alongside the choice of paper invoices by mail.

Show the balance, the open invoices with what each covers, and payments made, and let customers pay any open invoice. For people who don't use the portal, staff can send a payment link: a signed, expiring URL that does one thing (add a payment method, or pay one invoice) without a login. That's also the safe way to take a payment during a call (Phone Payments).

A related trick works at the point of sale. When a customer applies for financing during an in-home sale, have them complete it on their own phone, from a code on the salesperson's tablet, while the tablet waits for the result. The customer's credentials and saved payment details stay on their device instead of ending up in the salesperson's browser or password manager.

Service History and Documents#

Customers trust a service they can see. Every completed visit should show in the portal with what the technician did, the notes and photos they took, the products applied and the technician's license details where regulations require them on the service record (Proof of Service), and a downloadable service slip. Alongside it: upcoming visits, the signed agreement and any addenda, and the invoices. When a customer asks "what did you spray in my kitchen?", the answer should be on their screen, from the same record the regulator would see.

Requests Between Visits#

The portal is also where customers ask for things that aren't on the schedule, and each request should become a structured record, not an email to a shared inbox:

• "The problem is back." A request for a return visit with a description and photos, checked against the agreement's return-visit window and booked through the same availability rules, or routed to the service center when it falls outside them.
• "Something changed at the house." A new gate code, a new dog, a new baby, a renovation. These are property details the technician needs before arriving, so they update the property record (Customers, Accounts & Properties) and show in the technician's app on the next visit, not in a note nobody opens.
• "I'm moving." The most common reason for a cancellation that didn't need to happen. Offer to move service to the new address when it's in a service area, which is a new agreement at a new property, carrying over the customer and payment method; otherwise schedule the cancellation for the move date (Collections & Retention).
• "My neighbor wants this too." A referral form that creates a lead for sales with the referring customer's code attached, so any reward follows automatically when the referred customer's first service is completed, not when they sign.
• "I want more." An upgrade to a bigger plan or an added service is a sale, with new terms and a signature (Signing the Agreement); the portal can start it, but it shouldn't quietly change what the customer pays.

The Contact Center#

Some customers will always call. The contact center is the other door, and it should see exactly what the portal sees.

• Identify the caller before an agent picks up. Match the calling number against customers' primary phone numbers and pass the account to the agent's screen with the call. The IVR can answer the common questions itself (next visit, balance) and take payments in a way that keeps card numbers away from agents (Phone Payments).
• Route by intent and place. A billing question and a "your technician damaged my sprinkler" call need different people, and the service center that runs the route is often the one that has to act.
• One timeline. The agent's screen shows the account's visits, messages sent and skipped (with reasons), notes, payments and open issues in one place. "Did they get the reminder?" should take one glance.
• Alerts on the account. Short, categorized flags (high priority, billing problem, follow up, a customer who needs special handling) with an owner, a due date and an expiry, shown wherever staff open the account, closed when handled or turned into a permanent note. A flag that never expires is just clutter.
• Roles with limits. Agents, supervisors and managers can do different things: a credit or refund above a threshold, waiving a fee, or processing a cancellation may need a supervisor, and every such action records who approved it.

Handoffs

Many calls end with "someone will call you back": a callback from the service center, a re-visit, a damage claim. Make each one a task with an owner, a due time and an escalation path, not a note that hopes someone reads it. Set the targets in business hours (my default is acknowledging within four business hours and resolving within one business day), escalate automatically to the next level of management when a task misses them, and close the loop by telling the customer what happened. The tasks and their timings are also how you find out which service centers are drowning.

What This Means for the System You Build#

• One-time codes to known contacts, short-lived, single-use and rate-limited, with single-use welcome links and step-up for sensitive changes.
• People, accounts and roles, with invitations that can't grant ownership and authorization on every request.
• Impersonation that records both people, shows a banner, expires, and can't touch sign-in or secrets.
• Self-scheduling through the same availability engine as staff, with explicit rules that send initial, same-day and frozen-account changes to a person.
• Hosted payment fields, per-subscription autopay, methods shared across subscriptions, and signed single-purpose payment links.
• Service history from the same record regulators see.
• A contact center screen with one timeline, account alerts with expiry, and callbacks as tasks with targets and escalation.

References#

Specifications

• NIST SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management, out-of-band verification over the phone network as a restricted authenticator, the 10-minute limit on out-of-band secrets, and limits on failed attempts
• PCI Security Standards Council: FAQ 1604, SAQ A merchants that embed a service provider's iframe still owe its requirements, including approved scanning vendor scans