This page is the controlled working agreement and source of truth for the HFHS Growth + Customer Care plan. The high-level outcomes describe the intended direction; detailed responses and implementation approaches are not authorized until Lee approves them. Each approved item will receive a defined result, owner, acceptance criteria, evidence, and status before implementation begins.
What we're signing up for
Five outcomes. Everything below rolls up to one of these:
Outcome1. Sales gets transparent decision support for every lead: service fit, relationship potential, conversion readiness, confidence, reasons, a recommended membership level, and the next conversion action. Every lead continues through the normal contact process; this is not a call-order ranking system.
WWherk responseProposed clarification / implementation approach
Proposed direction pending HFHS confirmation: help the salesperson identify the membership level that best fits the homeowner and property, explain the recommendation, identify missing information, and suggest a useful conversion action. Recommendations remain advisory, can be overridden with a reason, and must not rely on an unexplained overall score. The initial release cannot automatically route, disqualify, contact, or mutate a lead. Existing operational tables and live records remain read-only; any new recommendations, reasons, overrides, and validation results must live in isolated related tables, and any migration requires Lee's explicit approval. The plan catalog, cadences, decision rules, and conversion additions below must be confirmed before implementation.
Outcome2. The conversion journey (address - assessment - inspection - report - follow-up - membership) runs as one pipeline instead of a bunch of disconnected steps.
WWherk responseProposed clarification / implementation approach
The dividing line: anything observable and capturable in the home belongs to the person standing in it (checklist, photos, notes, recording the owner's requests, flagging urgent items); anything involving pricing, vendor engagement, scheduling commitments beyond the visit, or customer-facing written output belongs to home base with human approval before it goes out. The app already enforces a version of this split (techs document, HMs coordinate) - the first-visit standard at Gate 1 will publish the explicit matrix: every action in the journey, who can initiate it, who must approve it.
Outcome3. Every home has one verified, concise record built from recordings, notes, photos, and staff judgment.
WWherk responseProposed clarification / implementation approach
Agreed - the internal record and what the customer sees are two views of the same data. The customer-facing version is plain language: the visit summary after every visit, and in Phase 3 the home health report / QBR that shows them their home's record the way a doctor walks you through a chart. The customer should be able to say "they know my home better than I do" - that's the test. We never show the raw internal record; we show the curated, human-approved story built from it.
Outcome4. No dropped commitments. Every promise to a customer has an owner, a due date, evidence, and an escalation path. Eric’s two-month showerhead issue becomes structurally impossible.
WWherk responseProposed clarification / implementation approach
Two channels. To the customer: the visit summary explicitly lists "here's what we committed to and by when," and if a promise date moves, the customer gets a proactive status update - they never have to ask. Internally: the master list is the single source; alerts, reports, and management views all pull from it, and anything critical that goes overdue lands in a named person's queue (see the escalation chain, now HM → GM → Emily). The customer hears about promises twice - when we make them and when we keep them - and never has to chase.
Outcome5. AI does the heavy lifting on extraction and drafting, but a human approves anything a customer sees. Always.
WWherk responseProposed clarification / implementation approach
Proposed starting SLAs (to be finalized in the Detail Packs, tightened as the pilot proves out):
WWherk responseProposed clarification / implementation approach
- AI draft ready: within minutes of visit close / recording upload.
WWherk responseProposed clarification / implementation approach
- Human review + approval: same business day.
WWherk responseProposed clarification / implementation approach
- Customer-facing summary sent: within one business day at pilot start, driving toward same-visit (see the real-time discussion in section 2).
WWherk responseProposed clarification / implementation approach
- Negative sentiment escalation: human acknowledgment within 4 business hours.
WWherk responseProposed clarification / implementation approach
- Overdue critical promise: surfaced to the owner immediately, escalated after 48 hours without action.
WWherk responseProposed clarification / implementation approach
These get measured on the pilot scorecard from day one, so we're not guessing whether we hit them.
WWherk responseProposed clarification / implementation approach
Agreed, and this slots into two existing pieces. Training: the onboarding materials in the Measurement/Adoption workstream get a module that isn't just "how to use the app" but why the checklist and methods work - merchandising the system to our own people so they can merchandise it to the customer. A tech who understands why the checklist exists sells it in the home without trying to. The caring part: the satisfaction check on every visit plus sentiment monitoring is exactly how we find out whether the customer feels cared for, and the per-employee compliance view (see the alerting/escalation answer below) is how we find out who on staff isn't delivering it. The software surfaces it; management acts on it.
The work
Standardized home + lead profile. Before anything else, one trusted record per property: address, attributes, service area, member density, engagement, enrichment data. This is the foundation - scoring, assessments, and routing all sit on it, and nobody re-enters the same info twice.
WWherk responseProposed clarification / implementation approach
Four questions, each driving a next step:
WWherk responseProposed clarification / implementation approach
1. Can we serve this home? (address → service area, distance to nearest members) → route or disqualify.
WWherk responseProposed clarification / implementation approach
2. What is this home worth to us? (home value, size, age → LTV potential) → prioritization and which product to lead with.
WWherk responseProposed clarification / implementation approach
3. What will this home need? (age, systems, property type → likely near-term projects and maintenance profile) → talking points for the rep and the inspection focus.
WWherk responseProposed clarification / implementation approach
4. How do we win it? (source, engagement history, member proximity for social proof) → which sequence and which opener.
WWherk responseProposed clarification / implementation approach
The concrete field list - every attribute, where it comes from (county data, enrichment, our own history), and which next step it drives - is part of the Gate 1 Detail Pack. Nothing goes in the profile unless it answers one of those four questions.
Lead scoring and routing. Every lead scored on home value, home age, proximity to members, and every score shows its reasons. We validate against historical booking outcomes on data before sales relies on it. Reps can override with a reason (we learn from the overrides). Performance comparable by market, source, and rep.
WWherk responseProposed clarification / implementation approach
Exactly - and we'll make that clear in the model. The score isn't just "will they book," it's expected lifetime value: home value + age + systems condition ≈ expected annual service spend, and owner signals (engagement, responsiveness) ≈ retention likelihood. LTV shows up as one of the visible reasons on every score, so a rep can see "high LTV, lower close probability" versus "easy close, small home" and prioritize accordingly. We will validate the LTV proxy against actual member spend history before it drives routing.
Address-based assessment and inspection as THE conversion event. Instant house profile from an address; lead magnet on the site, and rep prep so we know the house the second we're on the phone. The free inspection is the standard conversion moment, with an auto-generated leave-behind report built from verified inputs. The whole journey is measurable end to end. Pricing stays hidden per Erik.
WWherk responseProposed clarification / implementation approach
Right - this describes the target state, not the current one. Sequencing plan: first we map the inspection flow as it actually happens today (Phase 1, part of the sequence audit), then we phase the changes so sales never loses the current motion mid-transition. The current process keeps working until the new one demonstrably beats it.
Follow-up and coaching. Every lead-facing sequence mapped and tightened...un-booked estimates get automatic follow-up that stops on reply, booking, disqualification, or signature. Every automated contact is attributable and protected from duplicate sends. Coaching: third-party call tool first, our script, manager review before any coaching counts, and a reviewed gold set of calls so we know the scoring isn't making things up. Phrasing-level feedback, not "did they say the magic words."
WWherk responseProposed clarification / implementation approach
Agreed, and the mechanism generalizes. The rollout order is deliberate: sales reps first (Phase 1 pilot - recordings already exist there and consent is simplest), then HMs and techs on in-home first-visit recordings (gated on the consent language work in Non-negotiable #1 - in-home audio across two-party-consent states has to be done right), then vendor-facing calls - the negotiation and deal-making side - with its own flow, landing alongside the vendor SLA work in Phase 2. Same engine, same gold-set validation, three different scorecards. The vendor piece is a real change to how deals get made, not just a recording tool - see the vendor answers below.
!Gated client decision
Confirm the membership plans and proposed conversion approach
Implementation is blocked until HFHS confirms or corrects the plan catalog below and accepts or rejects Wherk's conversion recommendations.
This gate supersedes the earlier Outcome 1 proposals about queue prioritization, generic product routing, and making a free onsite inspection the standard conversion event.
Our read-only review of the contract system and proposal language found these currently configured offerings:
- Quarterly: four four-hour visits per year.
- 6 Visit Quarterly: three monthly four-hour onboarding visits followed by three quarterly four-hour visits.
- Bi-Monthly: six visits, either every other month or frontloaded based on property needs.
- Monthly: twelve four-hour visits per year.
- House Manager: as-needed visits rather than a scheduled maintenance cadence.
- Concierge: present in the system, but its configured cadence, active-contract cadence, and proposal language do not agree.
HFHS response needed
- Which of these plans are officially offered to new leads today?
- What is the official name, visit cadence, visit duration, service scope, and intended customer for each plan?
- Should 6 Visit Quarterly and Bi-Monthly remain separate offerings? If yes, how should sales explain the difference?
- Is Concierge actively offered? If yes, please provide its canonical cadence and service definition; otherwise, should it be excluded from recommendations?
Accept or reject Wherk's proposed conversion additions
- Add a short, no-cost Membership Fit Assessment to the existing sales call or Zoom—not a universal free onsite inspection.
- Use the answers to recommend one membership level and, when useful, one alternative, with reasons, missing information, and confidence.
- Keep Concierge as manual review only until its official definition is confirmed.
- Later test a complimentary virtual or onsite consultation only for qualified prospects who remain uncertain, measuring conversion benefit against delivery cost before making it standard.
Please reply: confirm or correct the plan list, then mark each proposed conversion addition Accept, Reject, or Revise.
Team discussion from the Google Doc
ESEmily ShnidermanRelayed by Lee Schwartz · Jul 24
On the first-visits work, close the feedback loop with the technician who remains after the HM leaves. The HM's member follow-up must encompass the totality of the first visit: maintenance findings, possible subsequent off-cycle needs, and the rest of the technician's observations.
Guided mobile visit flow. Extends the existing audio/photo ingestion into a guided first visit. A visit can't be completed until the checklist, room/asset context, required photos, notes, disposition, owner, and due date are captured. Works offline, incomplete items visible before submit, no shadow notebooks. New hires should be able to run a compliant first visit without shadowing anyone.
WWherk responseProposed clarification / implementation approach
iPad: yes. The app runs on iPad today; as part of the pilot we'll verify and polish the first-visit flow specifically on iPad (layout, photo capture, offline) so it's the standard field device for first visits - an iPad in the home also presents better than a phone, which matters for the same reason the uniform does. Uniform: agreed it's a part of the same professional first impression, but it's an ops decision.
AI-assisted home plan. The ingestion engine (built, needs use and testing - this is the missing piece of the service, per Erik) turns approved recordings, notes, and photos into proposed profile updates, repairs, projects, parts, promises, and prioritized next steps. Every generated item links to its source evidence. Staff accept, edit, or reject. Every pilot first visit produces a reviewed, prioritized home plan within one business day, but ideally in real-time. Next day has the appearance of human-generation…real-time has an obvious AI footprint. Unsure which will resonate more with the member. Can test both or just make the call and run with either version. In either case, AI will generate, humans will “bless”…the only question is the timing of the send.
WWherk responseProposed clarification / implementation approach
Agreed on the framing - AI generates, a human blesses, and the only open question is send timing. Recommendation: build for real-time, test both framings. The AI draft is ready in minutes either way; the bottleneck is the human approval, so the flow will support the HM reviewing and blessing the plan before they leave the driveway. On the Westport pilot we split it: half the visits send same-visit, half send next-morning, and the post-visit satisfaction responses tell us which resonates. If you'd rather skip the test and just call it, real-time is the call I'd make - "wow, that was fast" beats "looks hand-crafted" for this generation of customer, and it matches what you said you'd want as an owner. Either way we're not waiting on the answer to build; the timing is a config, not an architecture.
Every promise gets tracked. One master list of every commitment we make to a customer and every next action that comes out of a visit, who owns it, when it's due, where it stands, and the evidence behind it. Alerts, reports, and management views all pull from that same list, so there's one version of the truth. If something critical goes overdue, it cannot sit there invisible... somebody sees it and somebody owns it. And staff work one exception queue, not five.
WWherk responseProposed clarification / implementation approach
This is a real upgrade to the design and it's adopted: the master list tracks both sides of the conversation - what the owner asked for (requests, captured near-verbatim from the recording) and what we said we'd do (promises). The ingestion engine extracts both, each linked to its source evidence. The gap between them is the "expectation vs reality" you're pointing at: any owner request that didn't turn into a promise, a decline, or a documented "not now" gets flagged for HM review before the visit closes. So we'll know, per appointment, exactly what was asked, what was committed, and what fell in the crack - which today is invisible.
Visit summaries + satisfaction. Auto-drafted customer summaries from reviewed visit info, honoring comm preferences. Post-visit satisfaction check on every visit. Negative sentiment creates a human-owned escalation with a documented resolution... review requests only fire at approved moments.
WWherk responseProposed clarification / implementation approach
That first sentence is the design principle for the whole satisfaction loop - the system's job is to make "we didn't know" impossible: a satisfaction check on every visit, AI sentiment monitoring on every captured interaction, and negative signals creating a human-owned escalation that can't be closed without a documented resolution. On "AI listens and instructs": the trajectory is agreed, staged deliberately. Now: AI listens to everything captured and surfaces - issues, gaps, next actions, coaching feedback. Instructing (AI telling staff what to do next) starts as recommendations a human approves, per Outcome 5. As the gold sets prove accuracy, we widen what the AI can drive autonomously - that's exactly the keep/kill/scale decision at Gate 3, made on evidence instead of faith.
Vendor discipline. This one's from the call. Quote SLAs get measured, aging quotes surface automatically instead of being discovered by an angry customer, and we run the paid-quote pilot - a hundred bucks to a vendor for a next-day quote beats three weeks of silence every single time. Or we may have enough data to produce a rough estimate that is subject to adjustment based on new information from Vendors.
WWherk responseProposed clarification / implementation approach
Both ideas go into the Phase 2 vendor workstream as first-class experiments alongside the paid-quote pilot:
WWherk responseProposed clarification / implementation approach
1. Data-backed rough estimates: once quote history is structured, we can quote a range instantly ("typically $X–$Y for this, vendor confirms within 48h") - the customer gets a number same-day instead of silence, and the vendor quote becomes a confirmation, not a blocker. We'll validate estimate accuracy against actuals before customers see ranges.
WWherk responseProposed clarification / implementation approach
2. Vendor onboarding fee / SLA relationship: instead of paying per rushed quote, pay once to "open up" a vendor into a preferred relationship where fast quote turnaround and scheduling priority are contractual. Pilot with 2–3 trades where quote aging hurts most, measure turnaround before/after, and compare cost-per-fast-quote against the per-quote payment model.
WWherk responseProposed clarification / implementation approach
The SLA measurement infrastructure is the same either way, so building it first (as planned) keeps both options open.
We extend the existing automation/outbox patterns - not a parallel AI system. Retries, failure visibility, named owners. Every step stores its evidence, model version, reviewer, and approval. Every automated message and alert is traceable. Alerts support severity, aging, dedupe, acknowledgment, suppression, and digests….all designed against alert fatigue from day one, because an HM with 40 houses drowning in pings is the same as no alerts at all. And no failure recovery may ever double-contact a customer.
WWherk responseProposed clarification / implementation approach
Two commitments come out of this. (1) Vendor-as-customer: the vendor side gets the same machinery the member side gets - promises we make to vendors tracked on the master list, response SLAs measured in both directions, and vendor scorecards (performance, margin, responsiveness) so we know who our best vendors are with data instead of vibes. (2) Vendor recruitment at the right margins is a sales/marketing motion, and it deserves an owner with that Type A mandate - the software supplies the scorecards, pipeline view, and SLA evidence; a named person on your side drives the recruiting posture. Recommend we name that owner at Gate 1 (this connects to the vendor-deal coaching extension in section 1 - same person, same standard).
Live pilot scorecard extending the existing dashboards (not a new reporting system). Gold sets of calls and first visits testing AI accuracy, omissions, and hallucination. End-to-end tests covering offline visits, failed providers, retries, approvals, negative feedback, and duplicate-contact prevention. Onboarding materials for HMs and techs. And at the end: production results, documentation, ownership transfer, remaining backlog, and a go/no-go recommendation on every experimental capability.
Alongside
Emily / James / Wilmer own; Wherk supports
Alerting/escalation policy for stalled projects and repairs - they own it, I help shape the design.
WWherk responseProposed clarification / implementation approach
"Three strikes" isn't the proposal - severity-based thresholds are, and the numbers get set by the people who own the policy (Emily/James/Wilmer), not by the software. The shape:
WWherk responseProposed clarification / implementation approach
- Critical items (safety, an explicit customer promise, negative sentiment): escalate after ONE miss. There is no acceptable number of strikes on a promise to a customer.
WWherk responseProposed clarification / implementation approach
- Routine items (documentation gaps, aging non-critical tasks): the item escalates up the chain (HM → GM → Emily) after a defined aging window, and patterns - not single misses - show up on a per-employee compliance view the managers see.
WWherk responseProposed clarification / implementation approach
Nothing punitive is automated. The system's job is to make misses visible and undeniable; what happens to a repeat offender is a management decision made with data. That also answers "why 3" - there's no magic number; there are severity tiers, and the policy doc (Phase 1, locked with Emily/James/Wilmer) states each tier's threshold and who acts.
Emily's shipped/next/blocked view of the quality initiative (end of July) and her chat assistant (this week - Google Chat, else Telegram).
Timeline
In progress
Phase 1 - Foundations (Jul 21 → Aug 8). Ingestion pilots live with either a hand-picked set of HMs or all of them. First-visit capture standard defined. Sequence audit done. Scoring model designed with Jack. Coaching pilot on 1–2 reps. Alerting design locked with Emily/James/Wilmer.
◆Gate 1 (~Aug 8): pilot HMs actively using ingestion, you sign off on the first-visit standard and the scoring model, and I deliver the Detail Packs for Phase 2.
Planned
Phase 2 - Build the rest (Aug 10 → Sep 11). Assessment on every lead. Sequences automated. Coaching on all reps. Guided first-visit flow to the pilot. Scoring live in routing. Vendor SLA + paid-quote pilot. Post-visit satisfaction pilot. Commitment ledger live.
WWherk responseProposed clarification / implementation approach
Most of Phase 2 IS parallel - those eight items run as concurrent tracks, not a queue. The sequencing that exists is dependency-driven, not preference: scoring can't drive routing until it's validated against historical outcomes (or sales is flying on an untested model); the guided visit flow can't build until the capture standard is signed at Gate 1; QBRs come last because they use the data everything else produces. The genuine serial constraint is bandwidth. You want me on this stuff and not some developer I bring in to take coding tasks.
◆Gate 2 (~Sep 11): the end-to-end demo. A brand-new lead gets scored, briefed, called by a coached rep, followed up automatically, and - when they sign - receives a guided, fully-captured first visit that produces a reviewed home plan the next day. You watch it happen.
Planned
Phase 3 - Revenue, retention, rollout (Sep 14 → Oct 16). Inspection leave-behind report. Home health / QBR generation. Hardening, audits on cadence, playbooks, handoff.
◆Gate 3 (~Oct 16): keep/kill/scale on every workstream, go/no-go on the experiments, decision on the parked list.
The 60-day contractual checkpoint (~Sep 21) lands right after Gate 2 - which is exactly when you'll have enough evidence to decide whether to continue and expand.
Calls already made — override if wrong
1. Site chatbot + AI ad creative stay parked. The proposal doc had them as "controlled experiments." Erik's email said the chatbot is "not top of my list," so they stay out unless Erik flips them on. Not deleted - parked, revisit at Gate 3.
2. Photo triage: validate before building. Erik thinks Gemini may already cover it. Phase 1 includes a quick check... we only build if there's a real gap. It ships as suggestions to staff either way, never autonomous diagnosis.
3. QBR / home health reports are IN, Phase 3. The proposal pushed them to "later expansion," but they were one of Erik's nine highlights, so they're in - sequenced last because they consume the data spine everything else builds.
Non-negotiables
1. Recording consent review. Coaching runs on sales-call recordings and the ingestion engine runs on in-home audio, across 12 states - some of which are two-party-consent states. Before either expands, we get the disclosure language right (call scripts, membership agreement). One week of legal work now versus a real problem later.
2. The escalation process gets a name. Every alert chain needs a final human. My proposal: HM → Emily When something's been ignored twice, Erik's phone rings. If that name is wrong, give me the right one - but there must be one, or Eric’s showerhead problem isn't solved.
Team discussion from the Google Doc
EKErik KimelJul 21
Escalation should run GM → Emily, not to Erik. Asked Emily to confirm.
ESEmily ShnidermanJul 21
Agreed with the GM → Emily escalation path.
3. We have a plan for the people, not just the software. In every business, you will have staff who don't log notes and photos consistently, and a new app doesn't fix that by itself. So, for the ones who resist it: first we train them, then we pair them with an HM who's already using it day-to-day, and if that still doesn't take, using the app becomes a requirement (a visit doesn't count as done unless it was captured in the app). The app makes it easy to do it right... this makes it impossible to skip.
Who does what
Me + one dedicated developer - delivery, validation, handoff. (Same commercial terms as proposed: $15k/month… decide at the 60-day checkpoint.)
Jack - script, scoring rules, coaching rubric, sales adoption.
Amanda + Westport HMs - design partners and first users. Ride-alongs as needed.
Emily - overlap referee on everything, co-owner of alert policy, quality status view.
James + Wilmer - alerting build, query tool build. Their end-of-month roadmap gets reconciled against this at Gate 1. I can handle this as well if they are backed up.
Eric A, Erik K. - included on all planning, per Monday.
Cadence: weekly 30-minute check - shipped, next, blocked, one page. Plus the three gate demos.
Implementation evidence
This page is now the living plan. As each capability ships, its card will receive a status, test link, demo link, and supporting evidence.
Feature previews
Links added as pilots open
Acceptance tests
Results linked by gate
Production proof
Deployment + adoption evidence
Add a comment
Your name, section, and comment are required.