System Overview
A practical map of Tempr's business objects, ownership model, and state-driven behavior.
Tempr is easiest to understand when you treat it as a record lifecycle system rather than a collection of unrelated screens.
The Big Picture
At a high level, Tempr moves work through four layers:
- Demand enters as a lead.
- A lead becomes a customer and usually a project.
- A project turns into signed, paid, scheduled work.
- Scheduled work becomes a completed work order and a closed project.
The Record Hierarchy
| Level | Description | Common owner |
|---|---|---|
| Lead | Pre-sale opportunity waiting for action. | Consultant or sales queue |
| Customer | Long-lived account and contact record. | Consultant or account owner |
| Project | A specific sale, job, or engagement for that customer. | Sales plus operations |
| Measurement | A quoted or installed product/service line. | Project team |
| Work Order | Fulfillment package for execution in the field. | Operations or install team |
| Payment | Money collected for a project. | Sales, finance, or customer portal |
Important State Models
Tempr uses explicit states in several parts of the system. Those states determine what users can do next.
Lead states
ReceivedAssignedFollowUpQualifiedUnqualified
Project states
LeadPresentedAwaitingDepositPendingPOInManufacturingPendingSchedulingPendingInstallPendingFinalPaymentCompletedClosed- hold or cancellation states such as
AdminHold,CriticalHold,Canceled, andLost
Project sale states
UnsoldSold
Measurement approval states
UnreviewedAcceptedRejected
Work order states
DraftReadyToSchedulePublishedCompleted
Payment states
PendingSentToGatewayRequiresActionCompletedFailedRefundedVoided
Ownership And Assignment
Most new-user confusion comes from ownership rules:
consultant_idis used widely to tie leads, customers, and projects to a specific internal owner.- tasks may be scoped to
mineoralldepending on permissions. - telephony extension assignment determines how inbound and outbound call context is mapped to Tempr users.
- customer-facing activity may continue even when a consultant is later released or deleted, so some records can be intentionally unassigned.
Internal Surfaces Versus External Surfaces
| Surface | Audience |
|---|---|
| Main app pages | Internal employees doing daily work |
| Filament panels | Internal specialists and administrators |
| Customer portal | External customers reviewing, signing, and paying |
| Public webhooks and callback routes | External systems and integrations |
| API docs | Mobile clients, field tools, and machine-to-machine integrations |
How To Think About Changes
When you update a record, ask:
- What state is it in right now?
- Who owns it?
- Which downstream area depends on this value?
- Should this action happen in the main app, a specialist panel, the customer portal, or through an integration?
Avoid making process assumptions from labels alone. In Tempr, the current state and panel context matter more than the route name.