sync: auto-sync from GURU-5070 at 2026-07-23 05:24:04
Author: Mike Swanson Machine: GURU-5070 Timestamp: 2026-07-23 05:24:04
This commit is contained in:
@@ -243,3 +243,4 @@
|
||||
- [GuruRMM build-server SSH key](reference_gururmm_build_server_ssh.md) — guru@172.16.3.30 key is ~/.ssh/gururmm-physical (not id_*); password fallback vault infrastructure/gururmm-server
|
||||
- [LAB-SVR is current](feedback_labsvr_retired.md) — Len's Auto LAB-SVR is the CURRENT server (replaced old LAB-SERVER); powered back on 2026-07-18
|
||||
- [Datto AV uses Bitdefender drivers](feedback_datto_av_bitdefender_drivers.md) — rtp1/rtp2/BdNet/BdSentry/netprotection_network_filter* are Datto AV's own drivers (Bitdefender SDK), NOT orphan Avira installs; check infocyte SDK dir before treating as orphans
|
||||
- [Prospect / call-list vetting criteria](feedback_prospect_list_vetting.md) — dedupe purchased lead lists against Syncro customers AND contacts by email domain; strip competitors, in-house-IT orgs, micro/consumer shops, HIPAA providers, non-AZ; location_type "Remote" = the contact, not the company
|
||||
|
||||
48
.claude/memory/feedback_prospect_list_vetting.md
Normal file
48
.claude/memory/feedback_prospect_list_vetting.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: Prospect / call-list vetting criteria for ACG
|
||||
description: When vetting a purchased lead list for an outside appointment-setting firm, dedupe against Syncro (customers AND contacts, by email domain) and strip five categories Mike does not want onboarded.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
Mike periodically buys a Tucson-area lead list and has it vetted before handing it to an
|
||||
outside sales / appointment-setting firm. Confirmed criteria (2026-07-22, on
|
||||
"Arizona Computer Guru New List.csv", 238 rows -> 168 callable / 70 excluded).
|
||||
|
||||
**Why:** the setting firm calls on ACG's behalf, so a call into a current client, a
|
||||
competitor, or a prospect ACG would refuse to onboard is an embarrassment ACG pays for.
|
||||
|
||||
**How to apply:**
|
||||
|
||||
1. **Dedupe against Syncro, not the wiki.** `wiki/clients/` holds ~75 articles; Syncro holds
|
||||
~3000 customers + 768 contacts. Match on **email domain** (customer `.email` AND
|
||||
`GET /contacts` — a lead is often a contact under a differently-named customer record),
|
||||
then normalized business name, then fuzzy. Domain matching found every real hit; name
|
||||
fuzzing at <0.86 produced only false positives. Exclude free-mail domains from the map.
|
||||
2. **Active vs former:** a Syncro record alone means nothing — many have zero tickets. Pull
|
||||
ticket + invoice counts and max dates per matched customer. Recent invoices = ACTIVE
|
||||
(exclude). Dormant = FORMER (keep on the list, flagged, as a warm re-approach).
|
||||
3. **Exclude these five categories:**
|
||||
- **IT/MSP competitors** — MSPs, IT consultancies, dev shops, ISPs, web/marketing-tech firms.
|
||||
- **Orgs with in-house IT** — the tell is the contact's own title (Sr Systems Engineer, Network
|
||||
Administrator, IT Coordinator), plus universities, federal labs, districts, utilities,
|
||||
hospitals, large law firms, public companies.
|
||||
- **Micro / consumer-facing shops** — salons, spas, restaurants/bars, fitness studios,
|
||||
single-chair practices, small retail. Low seat count, low IT spend.
|
||||
- **Healthcare / HIPAA-heavy** — providers, clinics, hospices, home care, surgery centers,
|
||||
diagnostic labs. NOTE: medical *device manufacturers* and *distributors* are fine — they
|
||||
are not covered entities. Keep those.
|
||||
- **Not Arizona** — verify HQ, do not trust the row's city/state.
|
||||
4. **`location_type` = "Remote" means the CONTACT is remote, not the company.** The row's
|
||||
city/state is the contact's location. A Tucson company routinely shows a contact in another
|
||||
state. Never drop for geography on that column alone — verify HQ (WebFetch the domain).
|
||||
Flag them `remote_contact` so the setter knows onsite scheduling is harder.
|
||||
5. **Check whether the file actually contains contact data.** These vendor exports often ship
|
||||
as previews: `work_email`, `work_phone`, `mobile`, `street1`, `company_revenue`,
|
||||
`company_employee_count`, `primary_industry` etc. hold the literal strings `Yes`/`No`
|
||||
(= "we have this field"), not values. Say so before Mike pays a setting firm to work a
|
||||
list with no phone numbers in it.
|
||||
|
||||
Output shape that worked: two CSVs in `~/Documents` — a tier-ranked `VETTED` call list
|
||||
(A = priority, B = fits, C = qualify first) and an `EXCLUDED` list with a reason per row so
|
||||
Mike can audit the cuts. See [[feedback-vault-every-credential]] for the unrelated-but-adjacent
|
||||
rule on anything credential-shaped that surfaces in these files.
|
||||
Reference in New Issue
Block a user