Revelation Plumbing
Architecture review · Corey Crooks
A trust-heavy Pittsburgh plumber publishes two different phone numbers across its public surfaces. That is a data-integrity failure, and fixing it takes ownership and monitoring, not a copy edit.
Medium
Reflects how much could be verified from public surfaces for this review.
Evidence policy
Sources for verified claims: https://www.revelation-plumbing.com/ (public site, reviewed Jul 2026); Google Business listing data from discovery pipeline (rating/review count/listed phone). Review date: Jul 15, 2026. Assumptions are labeled inline. Performance measurements: not run—targets only.
Directly verified: Website phone 412-518-7170; Discovery listing phone (412) 618-1165; Schedule form with optional photo/video upload.
Opening thesis
Revelation Plumbing's website lists one phone number. Its business listing shows a different one. That single verified fact tells me more about what this business needs than any redesign mockup could.
Two phone numbers across public surfaces is not a typo to fix once. It means no single system owns the business's identity data, so the same drift will happen again to hours, service areas, or addresses. It corrupts call attribution, it can cost a ranking signal in local search, and in the worst case a customer calls a number nobody answers.
I would make the source of truth the project. One config module owns name, address, and phone. Every surface reads from it, including the site chrome and the structured data. A scheduled job compares it against the Google listing and alerts on drift. The lead form, which is already good, gets a backend that persists first and notifies second, so a notification outage never loses a customer. The visual redesign is the least important part of this work.
What I looked at
I reviewed the public website and the business's discovery listing data in July 2026. I did not have access to the company's analytics, hosting, call logs, or booking volume. Where those would change my recommendation, I say so below.
What is already working
The trust story is genuinely strong, and I would not rewrite it. The site earns credibility in words: the guarantee, the certifications, the no-service-fee policy, the same-day emergency promise. Homeowners vetting a plumber before price care about exactly these signals.
The schedule form is better than most in this industry. It captures the address and zip a dispatcher needs, and it lets homeowners attach photos or video of the problem. That media is real diagnostic value: it helps the plumber quote accurately before rolling a truck.
The rating footprint in the listing snapshot (4.9 across 555 reviews) suggests the operational side of the business does not need rescuing. This is a digital-system problem, not a business problem.
What I think is happening
This section is inference, labeled as such.
If that inference holds, the phone drift has a mundane cause: someone edited one surface and not the other, because there was no system that made them the same thing. The schedule form most likely delivers into an email inbox, which means a full mailbox, a spam filter, or a provider outage silently drops leads with no record they existed.
The homepage reads as one long trust narrative flowing into a feature grid, services, and the form. The messaging is good. The structure underneath it is what worries me.
Where pressure is accumulating
| Element | What I saw | Evidence | Why it matters |
|---|---|---|---|
| Phone | Two different numbers across surfaces | Known from public information | Wrong attribution, split call routing, trust damage |
| Schedule form | Rich fields plus media upload | Known from public information | High-value leads with no visible durable pipeline |
| Trust badges | BBB, NASSCO, licensed/insured claims | Known from public information | Strong but unstructured; not linkable proof |
| Financing | Advertised on site | Known from public information | Regulated capability the site should not own |
| Emergency | Same-day promise | Known from public information | No distinct emergency path or response expectation |
The failure path I care about most: a homeowner with a burst pipe submits the form with photos, the notification email bounces, and nobody ever knows. The business loses the job and the homeowner loses hours. Nothing on the public surface tells me this cannot happen today, and I would verify it internally first.
The decision I would make
The real system here is not the marketing page. It is business identity data plus lead capture, routing, and response. I would build one modular application around those two jobs.
In plain terms: visitors read a server-rendered site. The phone number, address, and hours come from one config record, and the same record feeds the LocalBusiness structured data, so the numbers cannot drift apart on surfaces I control. Form submissions write to Postgres first, then fan out to SMS and email. Staff work leads from a small inbox with status tracking.
The specific decisions
Engineering decision
Architecture decision record- Context
- The business phone number differs between the website and the business listing.
- Decision
- Introduce a single businessConfig record consumed by the UI, the JSON-LD, and call tracking, plus a scheduled job that compares on-site data against the Google Business Profile and alerts on drift.
- Alternatives
- Manually edit each surface; ignore it as a copy issue.
- Why this wins
- NAP consistency affects trust, local search, and attribution. Drift is a data-ownership problem, and a one-time edit does not fix ownership.
- Tradeoffs
- Requires a config module and a periodic consistency check job.
- Business impact
- Correct call routing, cleaner attribution, and drift that gets caught by an alert instead of a confused customer.
Engineering decision
Architecture decision record- Context
- A strong lead form, including media upload, can silently fail into an inbox.
- Decision
- Write every lead to Postgres first, then fan out notifications through an adapter. Uploads go to object storage with type and size limits and metadata scrubbing.
- Alternatives
- Email-only form delivery; a third-party form widget.
- Why this wins
- Capture must survive notifier outages. The photos and video help the plumber quote accurately, so losing them costs money twice.
- Tradeoffs
- Storage and moderation responsibility for uploads; more backend than a mailto form.
- Business impact
- A notification outage becomes a delay instead of a lost customer, because every lead can be replayed from the database.
Engineering decision
Architecture decision record- Context
- Financing is a feature homeowners expect, but lending is a regulated third-party system.
- Decision
- Link to the financing provider's flow. Do not rebuild any part of lending.
- Alternatives
- Custom financing UI; dropping financing from the site.
- Why this wins
- Underwriting and compliance sit far outside a marketing site's blast radius. Owning any of it creates risk with no upside.
- Tradeoffs
- Less visual control over the provider's flow.
- Business impact
- Keeps a high-intent feature without regulatory exposure.
I would also split the form by intent. Emergency submissions go phone-first with an immediate SMS to the on-call person. Planned work keeps the full form with the photo upload. The response expectations are different, so the paths should be different.
What I would measure
Before cutover: a Lighthouse and accessibility baseline on the current site, since none exists in this review. After launch: lead submission success rate, notification delivery rate with alerting on failure, time from emergency lead to first contact, and a weekly NAP consistency check result. All of these are proposed targets, not current measurements.
What I would not build
Why not an in-house financing flow?
- Why it might look attractive
- Keeping homeowners on-site feels like better control of the experience.
- Why it is not justified here
- Lending carries compliance and underwriting obligations that have nothing to do with a plumbing marketing site. The provider already owns that risk.
- Reconsider when
- The company becomes a licensed lender, which is a different business.
Why not a quick manual fix for the phone numbers?
- Why it might look attractive
- It looks like a five-minute copy edit.
- Why it is not justified here
- Editing both surfaces today does not change the fact that nothing owns the data. The next edit reintroduces the drift. The fix is a source of truth plus monitoring.
- Reconsider when
- Never. Consistency is a standing requirement, not a task.
Why not microservices for leads, config, and content?
- Why it might look attractive
- Separate services look clean on a whiteboard.
- Why it is not justified here
- One plumbing company's site does not have independent scale domains or independent team ownership. Splitting it multiplies failure modes in exchange for nothing.
- Reconsider when
- Multiple brands or regions need independently deployed systems.
Migration sequence
Reconcile the source of truth
Confirm the correct canonical phone number with the owner. I would not guess this; picking the wrong number is the biggest risk in the whole project. Fix it on the site, the Google Business Profile, and the top citations. Stand up the businessConfig module. Capture the Lighthouse and accessibility baseline.
Lead pipeline behind the current site
Keep the existing site live. Point its schedule form at the new lead endpoint with persistence, upload handling, and notifications. Run synthetic probes for two weeks to prove delivery reliability, including the SMS text-alert path, before touching anything a customer sees.
Cut over the frontend
Ship the redesigned site reusing the same config and form contracts. Map redirects for legacy URLs. Turn on the NAP consistency monitoring job.
The order matters. Data reconciliation and the lead pipeline both deliver value even if the visual redesign never ships, so they go first.
Failure modes and rollback
| Component | Failure | User impact | Detection | Mitigation | Recovery |
|---|---|---|---|---|---|
| Business config | Wrong canonical number chosen at reconciliation | Calls route to a dead or wrong line | Owner verification before publish; call-volume drop alert | Owner signs off on the canonical record before any surface updates | Single-field correction propagates to every surface from config |
| Lead form | Submission fails on flaky mobile network | Homeowner believes help is coming; nobody was notified | Client error reporting plus server-side submission logs | Idempotency keys tolerate double submits; phone number shown as fallback | Replay persisted lead; call the homeowner back |
| Upload storage | Media upload times out or exceeds limits | Lead arrives without diagnostic photos | Upload error rate metric | Accept the lead without media rather than failing the whole submission | Staff requests photos by text from the inbox |
| Notification adapter | Email or SMS provider outage | Delayed response to a captured lead | Provider webhook failures alert on-call | Leads are already persisted; queue retries | Drain the queue when the provider recovers; work the inbox manually |
Rollback posture: the lead endpoint is versioned, so the old form target keeps working during any frontend rollback. DNS rollback covers the marketing site. Notifications run independently of the UI, so rolling back the frontend never touches the lead pipeline.
What could change my recommendation
Internal information could move me off parts of this plan, and I would ask for it first:
- If call logs show the listing number is the one customers actually use, reconciliation flips direction. The website, not the listing, holds the wrong number.
- If the business already runs field-service software with its own lead inbox, I would integrate with it through an adapter instead of building a staff inbox.
- If lead volume is very low, the escalation and queueing machinery can wait. Persistence and drift monitoring still cannot.
- If the current form provably delivers reliably and someone monitors it, Phase 2 shrinks to adding persistence behind the existing delivery path.
Sources
- revelation-plumbing.com, public site, reviewed July 2026
- Google Business listing data from the discovery pipeline: rating, review count, and listed phone number
Verified directly: the website phone number 412-518-7170, the listing phone number (412) 618-1165, and the schedule form's fields including photo/video upload. Not verified: CMS and hosting details, actual form delivery behavior, call routing, and any performance or accessibility measurements. This review is based on public information. I am not affiliated with the business, and internal constraints could change the recommendation.