Customers

The customer's identity lives on a Patron account — the same account architecture used for donors and volunteers across the platform. Personal information is largely self-managed: the customer signs in to update their address, phone, emergency contact, and demographic fields they choose to share. Required fields stay tight (name, date of birth, address, time zone); optional demographic and identity fields stay optional. The same Patron can hold customer profiles at multiple organizations, plus donor and volunteer roles, all under one identity. Linking a Patron to a customer record — or creating a new Patron at the same time — lives on the Patron Linked Account tab.

Each customer has their own account on the platform's double-entry ledger, with running balance, payment history, and transparent fee disclosure. Invoices for program services land on the customer record, with a public Pay-Invoice flow available so the customer (or anyone with the invoice number and date of birth) can pay without an account. Saved payment methods are tokenized at the processor; SecureCare never stores raw card data. Recurring payment plans for service invoices are managed from the customer record — set up once with a smart final-payment cap, run nightly through the platform's recurring engine.

Service delivery shows up across four tabs that work together. Appointments lists scheduled meetings; Calendar provides a composite day-by-day view that surfaces appointments, services, authorized absences, and other scheduled activity in one place. Cases is the case management workspace — intake, services, assessments, outcomes — documented in depth on the Case Management feature page. Authorized Absence captures planned leaves — a residential customer leaving for a family event, a treatment cohort participant taking a documented break — so the case timeline reflects what actually happened rather than reading every absence as a no-show.

Insurance information attaches to the customer record where it can be referenced from any program service that bills insurance. Multiple policies can be tracked when applicable; the active policy at the time of service is what bills. Programs that have insurance turned on draw from this tab automatically; programs that don't simply ignore it. Per-program insurance configuration lives on the Programs feature page.

Files attach directly to the customer record — intake forms, signed agreements, ID copies, treatment-related uploads — under the platform's standard Document Storage rules. Encrypted at rest, retained per HIPAA, visible only to staff with access plus the customer themselves through their patron portal (when the staff member marks the document public). Secure Messages provides an in-platform channel between staff and the customer; messages and attached files are HIPAA-compliant and live alongside the rest of the record. The full messaging story is documented on the Messaging feature page.

An Authorized Person is someone the customer has formally given permission to interact with the organization on their behalf. Each entry carries a name, relationship, phone number, and an explicit expiration date — authorization is not a permanent setting. Staff can record verification of full name, address, date of birth, and Social Security Number on the form so the platform captures provenance for the authorization. The list is maintained by staff and surfaces in other parts of the platform: when a staff member logs a phone call on the Call Log tab, the caller dropdown pulls from the Authorized People list. The relationship is the audit trail.

Emergency Contact is who the organization calls if something happens — a fall, a missed check-in, a medical event. Informational, no system access. Guarantor is who is financially responsible — invoices route automatically to the guarantor's email, with SMS reminders going to the guarantor's phone when SMS is enabled. The two roles often overlap (a parent guarantor who is also the emergency contact), but the record keeps them as separate fields with a one-click "Set From Emergency Contact" or "Set From Guarantor" copy when the same person fills both roles. The platform doesn't assume; it asks.

Customers in the same family unit can be linked to each other on the Family / Group tab. Both people must already exist as customer records on the platform; the link captures the relationship in both directions ("they are my Uncle, I am their Niece") so reports and views can express the relationship from either side. Multiple family members can be linked to build out the household over time. Each link is its own record; the platform doesn't try to infer family structure from shared addresses or last names.

Staff manually log phone calls on the Call Log tab — date, time, caller, topic, notes. The caller dropdown pulls from the customer's Authorized People list, so logging a call from the customer's mother (an Authorized Person on the record) is a click rather than a re-entry of her name and relationship. Calls from people not on the Authorized list can be logged with free-text caller info. The log is permanent; entries cannot be deleted, only added to, in line with the rest of the platform's audit posture.

SMS consent is captured per use case — appointment reminders, payment notifications, message-thread alerts — not as a single global toggle. Customers can opt in to one channel and out of another, and the consent log records the moment of opt-in for compliance. The Donations and Appointments features both honor this same consent model when sending SMS to a customer; the customer record is where the consent lives.

The customer record is the spine. Cases attach here. Appointments draw from here. Invoices land here. Documents file here. Messages thread here. The patron-portal access flows through the linked Patron account here. When a staff member opens a customer record, they see the whole picture — not five different tools that pretend to be one platform, but one record that everything else hangs from.