A website and lead-intake concept for a fictional independent US plumbing company. The project explores how a service business can turn mobile visitors into qualified requests without claiming operational results it cannot verify.
ClearFlow exists only as a design demonstration. Names, locations, reviews, pricing, availability, and service areas are illustrative. No real appointments, dispatch, or customer requests are created.
Most local plumbing websites present a list of services and a phone number, then ask visitors to figure out the rest. On a phone, during an urgent situation, that friction costs attention.
The design challenge was to help mobile visitors understand services, choose an appropriate path, provide useful request context, and understand what happens next — without implying that ClearFlow itself operates a dispatch center or guarantees response times.
Mobile-first hierarchy: the most common situations are visible immediately. Clear service paths reduce the cognitive load of browsing a generic service list.
Visible trust context: service area, timing cues, and transparent next steps are shown before the intake form.
Structured intake: the form asks for location, urgency, and problem details so an office can triage without a second call.
Transparent confirmation: after submission, the visitor sees exactly what was captured and what the office will do next.
Search / Referral → Landing → Service discovery → Request details → Simulated confirmation → Proposed office follow-up.
The final operational handoff — routing the request to the right person, scheduling, and dispatch — is described as a real-client workflow proposal, not an existing ClearFlow integration.
The homepage routes visitors by situation first: leak, clog, no hot water, installation, maintenance. Each path leads to a focused page that explains the next step clearly.
Urgent-service paths are safety-aware: they do not claim actual emergency availability or technician dispatch. Instead, they guide the visitor toward the fastest appropriate contact method.
A guided assistant asks a short sequence of clarifying questions: the problem type, the affected fixture or system, and how quickly help is needed.
This is a design demonstration of structured self-selection. It does not diagnose, does not use AI or LLM integration, and does not replace a licensed plumber's judgment.
Services are organized around the visitor's problem rather than internal trade categories. Service-area pages include a ZIP-checking demonstration that shows how geography could be validated without implying genuine ClearFlow operating territory.
The documented multi-step demo collects: service type, location, problem/urgency, contact details, and a review step. Each step is lightweight and explains why the information is useful.
The exact visual interface is treated as a design target; current screenshots are pending approved exports.
No real appointment or service request is created in the demonstration. The confirmation screen summarizes what was captured and describes what a real client's office workflow could do next: acknowledge, triage, assign, and follow up.
Client-specific reviews, credentials, pricing, and availability would require verification in a real engagement. The concept shows where those elements belong and how they can be presented honestly. Demo or sample content is never presented as factual proof.
The concept is documented as a Next.js/TypeScript application with typed configuration, responsive image rendering, accessibility considerations, and a clear separation between simulated and production workflows.
ServiceHarbor's own implementation uses the same stack and design tokens, but it does not import or copy ClearFlow application code.
A real engagement would require verified business identity, service areas, phone number, proof of license/insurance, operating hours, intake delivery method, privacy policy and consent, integrations, availability, and clear follow-up ownership.