Weekly-Partner-Pipeline-SOP.md

07-Automation/Weekly-Partner-Pipeline-SOP.md

1. ---
2. type: workflow-sop
3. scope: 07-Automation
4. tags: [claude, outreach, automation, workflow]
5. created: 2026-07-22
6. last_modified: 2026-09-21
7. ---
9. # Weekly Partner Client Pipeline: SOP
11. The end-to-end weekly refresh that turns live Plinth order data into a partner client
12. classification, a spreadsheet, updated stubs + XML map, enrichment, and (on approval)
13. Bitrix deals. This note is both the human procedure and the script the scheduled task
14. runs. Config lives in [[partner-thresholds]]; the deterministic work lives in
15. `weekly_partner_pipeline.py`; the scheduler definition is in [[scheduled-task]].
17. > **Current autonomy: `through_vault`** (enabled 2026-07-23). The unattended Monday 06:00
18. > America/Chicago run goes all the way through the vault on its own (delta pull, classify,
19. > verify, **write and upgrade stubs, and refresh the XML census**), then reads Bitrix for
20. > the reconcile, route and outreach-audit stages. It does **not** enrich, write to Bitrix,
21. > or route anyone into an outreach pipeline; those stay human-gated. Change `autonomy` in
22. > [[partner-thresholds]] to widen or narrow this.
24. > **The pipeline is ARMED.** `min_orders_to_qualify` was the arming switch and is now set
25. > (`1`), and `mode: ltv_bands` carries the live program bands, so the write stages fire. If
26. > any threshold in the *active* mode is ever set back to `TBD`, stages A to D still run
27. > read-only and everything from E onward refuses.
29. > **The scheduler runs from a file outside this vault.** [[scheduled-task]] is a *copy*.
30. > The prompt that actually fires lives at
31. > `~/Documents/Claude/Scheduled/weekly-partner-client-pipeline/SKILL.md`, which no session
32. > can read or verify, and which has silently drifted from the vault copy before. Any change
33. > to paths or stage order here must be pasted into that file by hand, or Monday's run and
34. > this SOP will disagree. Tell: if the Monday summary reports one spreadsheet instead of
35. > two, or the audit Summary sheet says "INCOMPLETE RUN", the external file has drifted.
37. > **Two spreadsheets per run (2026-08-10).** The weekly run now produces
38. > **(1)** `Complete-Partner-Clients-List_updated-<date>.xlsx`, the Drive-swap partner
39. > roster (Stage F2), and **(2)** `Bitrix_Pipeline_Outreach_Audit_<date>.xlsx`, one sheet
40. > per outreach funnel showing who is in it, how to find them in Plinth, and when they were
41. > last actually contacted (Stage F5). (2) resolves Plinth identity out of (1), so **F5 must
42. > run after F2.** They are otherwise independent; neither overwrites the other.
44. ---
46. ## The chain at a glance
48. ```
49. A0 Baseline seed ONE TIME: Ines's roster workbook -> order_history.json (seed-baseline)
50. A Delta pull orders.fetch, trailing pull_window_days, DAY-sized slices,
51. offset+dedupe until a page adds 0 new ids -> ingest ─┐
52. B Compute lifetime = baseline + post-baseline history (local) │ deterministic
53. C Classify apply partner-thresholds.md │ (weekly_partner_pipeline.py)
54. D Export xlsx 05-Outputs/partner-runs/… + verify (no-shrink guardrail) ─┘
55. │ ── autonomy=through_vault → the unattended run continues from here ──
56. E Diff + write create missing stubs / upgrade existing (+ last_modified)
57. F XML refresh partner-client-master-list.xml (+ <last_modified>)
58. F2 Workbook refresh Complete-Partner-Clients-List_updated-<date>.xlsx (Drive-swap copy)
59. F3 Deal reconcile pull all deals in cats 24/26/36 → reconcile-deals → census blocks
60. F4 Route route → weekly candidate lists (winback import CSV + cat24/dormant)
61. F5 Outreach audit outreach-pull-list → pull stage history for what changed →
62. outreach-audit → Bitrix_Pipeline_Outreach_Audit_<date>.xlsx
63. G Enrich client-enrich skill on new/changed stubs
64. H Push partner-pipeline-push skill → Bitrix deals (human-approved)
65. │ ── every stage that changes the vault → append one LEDGER entry ──
66. ```
68. ---
70. ## Why incremental (read this before "improving" Stage A)
71. **Plinth `orders.fetch` silently truncates large result sets**: roughly 70 orders per
72. response, no "has more" flag, and `offset` does not skip by order rows, so pages overlap.
73. Verified 2026-07-22 on one long-standing account (Plinth customer 40115 in the sample's
74. numbering): one all-time call returned 70 of its 74 orders and dropped the newest ones,
75. which understated LTV **and** can make an active client look like a Winback candidate. Clients with the
76. longest histories (exactly the Rhodium/Iridium segment) are the ones the truncation hits.
77. Full story in [[DECISIONS]] (2026-07-22). The shipped sample reproduces the failure on
78. 2026-09-17: the first page for that day stops at 50 rows, and only the offset loop finds
79. the rest. Consequences:
80. - **Never** ask the API for an all-time total. Lifetime value lives in the local history
81. (`07-Automation/data/order_history.json`) = Ines's roster baseline + ingested deltas.
82. - **Never** trust one response to be complete. Page with offset + dedupe until a page
83. adds zero new ids (`ingest` prints `added=N`; stop at 0).
84. - **Never** demote a tier or route to Winback when a lifetime total *decreased*: history
85. only grows; a decrease means data loss. `verify` (exit 2) catches this.
87. ## Stage A0: Baseline seed *(one time, before first run)*
88. `seed-baseline --sheet <Ines's partner roster workbook> --tab <tab> --as-of <sheet cutoff date>`
89. (dry-run first; see the [[Activation-Runbook]] and the activation checklist in
90. [[partner-thresholds]]). Two passes: the **All Accounts** tab, then the **Complete Partner
91. Clients List** tab with `--force`. Per-customer lifetime aggregates keyed by Plinth
92. customer ID. The weekly delta counts only orders **after** `as_of`, so it must match the
93. sheet's actual cutoff.
95. ## Stage A: Weekly delta pull from Plinth
96. - Window: trailing `pull_window_days` (default 8: one day of overlap; dedupe makes
97. overlap free).
98. - Slice by **single day** (`since` = `until`, `yyyymmdd`), `limit` = `page_size`
99. (**hard cap 100**: the API rejects more).
100. - Per slice: pull → save raw JSON page → `ingest --orders <page>` → if `added > 0` OR
101. the page had ≥ `suspect_row_count` rows, pull again with a higher `offset` and repeat
102. **until `added=0`**. Offsets overlap; the dedupe on `order_ref` absorbs it.
103. - Plinth caps at **10 requests / 10 seconds** and throttles (slows, does not error). A 6 AM
104. unattended run does not care.
105. - Read-only. No identity exposure beyond what Matt already owns.
107. ## Stage B: Compute lifetime metrics (local, no API)
108. Per customer, from the history store:
109. - `ltv`: baseline LTV + sum of `amount_field` (`grand_total`) over **counted**
110. post-baseline orders.
111. - `total_orders_count`: baseline count + counted post-baseline orders.
112. - `repeat_revenue`: baseline repeat + post-baseline counted spend.
113. - `first_order_date` / `last_order_date`: baseline vs ingested, whichever bounds.
114. - Orders dated **on or before** `as_of` never re-count (already inside the baseline).
115. - Undated orders (not yet finished) count as recent.
116. - Customers seen in a delta with **no baseline row** compute from ingested orders alone
117. and surface with `has_baseline=False`; review these, and backfill via windowed pulls if
118. one looks like a long-tenured client.
119. - **Approved merges fold here (2026-08-06).** `data/merge_registry.json` maps absorbed
120. Plinth accounts to their surviving account. After per-account metrics are computed, each
121. absorbed account is folded into its survivor (sums; date bounds), so classification
122. sees one combined client. Absorbed accounts never classify, never get stubs, never
123. enter the XML census, and `refresh-xml` removes an absorbed `pl-<id>` chunk if one
124. exists (self-healing). Entries are added ONLY on Matt's explicit approval, one LEDGER
125. entry each; see [[DECISIONS]] 2026-08-06. A missing or malformed registry warns and
126. runs unmerged; it never halts the 06:00 run.
128. ## Stage C: Classify
129. Apply the active `mode` from [[partner-thresholds]]:
130. - `ltv_bands` → tier by lifetime spend band.
131. - `multi_factor` → weighted score, then band.
132. - `simple_gate` → single cutoff, partner client vs. not.
133. Customers below `min_orders_to_qualify` or the lowest band are marked **Not a partner client**.
134. A mailbox listed under `tier_overrides.emails` takes its override tier outright, before the
135. bands and before `min_orders_to_qualify` (the per-email relationship override, 2026-08-12;
136. scope is deliberately per-email, not per-domain).
137. If thresholds are `TBD`, tier = `UNCLASSIFIED: thresholds not set` and the run is flagged
138. read-only.
140. ## Stage D: Export spreadsheet + verify
141. - Written to `05-Outputs/partner-runs/partner-classification_<YYYY-MM-DD>.xlsx`.
142. - One row per customer: identity, computed metrics, assigned tier, store group (for
143. reconciliation), `has_baseline` / `post_baseline_orders`, and `stub_status`
144. (new / exists / exists-changed).
145. - A `Summary` sheet: counts per tier, new vs. existing, baseline `as_of`, last ingest,
146. and whether the run was read-only or armed.
147. - **Then run `verify`: mandatory.** It compares this run against the previous one and
148. exits 2 if any customer's lifetime total or order count shrank. On exit 2 the run
149. STOPS regardless of autonomy: report the flagged customers to Matt, change nothing.
150. - `autonomy: through_vault` → the unattended run continues past this point into E/F/F2 and
151. the read-only Bitrix stages F3 to F5. Only G (enrich) and H (push) wait for a human.
153. ## Stage E: Diff + write stubs *(human-approved)*
154. - Match each classified **partner client** against `03-Clients/client-stubs/*.md` by email,
155. then by `first_name + last_name`. All stubs live flat in `client-stubs/`.
156. - **Missing** → create a stub via `_create_stub()` in the driver, which is the canonical
157. shape. `_templates/client-stub.md` was rebuilt 2026-08-12 to mirror that function exactly,
158. so the template and the driver now agree; build any hand-made stub from the template.
159. `## Research` starts `[TBD]`; `## Human Notes` empty; `last_modified` set to run date.
160. - **Exists** → do **not** touch `## Human Notes` or `## Research`. Update computed
161. frontmatter (ltv, repeat_revenue, order counts, dates, user_group_correct) only where it
162. changed, and set/refresh `last_modified`. Record the client as `exists-changed`.
163. - Follow [[CLAUDE-clients]]: the scraping-dump contract still governs. Note the retired
164. fields listed there (`enrichment_status`, `email_one_status`, `email_two_status`,
165. `outreach_type`, `seniority`, `total_orders_usd`): do not reintroduce them.
167. ## Stage F: Refresh the XML map *(human-approved)*
168. - `03-Clients/partner-client-master-list.xml` (**schema 3.0**, root
169. `<partner_client_master_list>`; renamed from `crm_pipeline_mapping.xml`). Back up first
170. to `05-Outputs/partner-runs/`.
171. - Every `<client>` carries both a `<bitrix_id>` (CRM contact id) and a `<plinth_id>`
172. (Plinth backend user id). A blank `<bitrix_id />` means the client isn't in the CRM yet.
173. - **Full partner coverage:** the map is a complete census of the partner base. Every
174. classified partner client (Palladium and up) must have a `<client>` chunk, whether or
175. not they sit in a pipeline. `refresh-xml` does four things each run:
176. 1. **Stamp** `<last_modified>=TODAY` on every partner client already in the map
177. (pipeline-mapped Bitrix chunks and previously-added map-only chunks alike).
178. 2. **Add** a chunk for every partner client missing from the map: identity from the
179. stub, an auto-generated `<summary>`, a stub pointer, and an **empty pipeline section
180. `<pipelines count="0" />`** to be populated when they enter a Bitrix pipeline.
181. 3. **Key** each added chunk `id="pl-<Plinth user_id>"` (stable, collision-proof vs Bitrix
182. ids). Same-person duplicate Plinth accounts (same name + email) share one chunk;
183. colleagues on one company mailbox each get their own.
184. 4. **Remove** any chunk whose `pl-<id>` is an absorbed account in
185. `data/merge_registry.json`: a merged client is one chunk, keyed by the survivor.
186. - Idempotent: re-running only re-stamps; it never duplicates a chunk. `<summary>` is
187. auto-generated; never hand-edit it. Non-partner customers are not auto-added.
189. ## Stage F2: Refresh the Drive-swap workbook
190. `refresh-workbook --plan <plan.json>` regenerates the manual Google-Drive-swap workbook
191. `05-Outputs/partner-runs/Complete-Partner-Clients-List_updated-<date>.xlsx` so it matches
192. the run. The vault copy is **not** connected to Google Drive (Matt uploads it by hand), so
193. each run carries the human-maintained columns forward from the **previous** generated copy
194. (the base; `--base` overrides, else the latest `…_updated-*.xlsx` in `05-Outputs/partner-runs/`).
195. On the **Complete Partner Clients List** tab it refreshes only the Plinth-derived columns
196. (User Group, the dated `Plinth LTV MM/DD/YY` column with its header renamed to the run date,
197. Total Spent (Orders), # Orders, Repeat Revenue (Plinth), First/Last Order) matched by `Id`
198. (Plinth user_id), and **appends** newly-qualified partner clients not already present (new
199. rows get their computed tier in `Correct Group`). It rebuilds the **All Accounts** base to
200. every current customer. It **never** writes a human-maintained column on an existing row
201. (Correct Group, Comments, Contacted, contact dates, Times/Total Pipeline, Current Stage(s),
202. Pipeline Owner/Rep) and leaves the curated **2026 Partner Working List** tab
203. byte-identical. **Formatting matches the master exactly:** appended rows and the rebuilt
204. All Accounts tab clone the master's per-column style (currency `"$"#,##0.00`, `mm/dd/yyyy`
205. dates, Arial), and Plinth cells on existing rows are normalized to it too, so a diff against
206. the master shows only real data changes, never formatting drift. Human-column styles are
207. left alone. Read-only on the base; writes a new dated file (never overwrites the base).
209. ## Stage F3: Deal reconcile *(2026-08-06)*
210. Claude pulls every deal in cats 24/26/36 (per-stage `list_records`, date-window pagination
211. past 50) into a deals JSON, then `reconcile-deals --deals <json>` absorbs it into the
212. census: one block per (client, funnel) recording the newest deal, statuses
213. active/completed/**lost**, summaries + stub `outreach_pipelines` mirrored, backup first.
214. Name-matched; unmatched/ambiguous deals are reported, never guessed. Idempotent.
216. ## Stage F4: Route *(2026-08-06)*
217. `route` evaluates [[pipeline-routing-rules]] read-only and writes the weekly candidate
218. artifacts to `05-Outputs/partner-runs/`: routing-candidates_<date>.json, the Winback
219. import CSV (person-named; role-named to a review CSV), with cat24/dormant lists in the
220. JSON. **Suppression is absolute:** `data/suppression_list.json` (names, emails and whole
221. never-contact domains) + any Not-Interested closure → excluded from everything, with the
222. evidence unioned across identity twins. **Deal creation stays human-gated**: the run emits
223. lists; loading them into Bitrix is done by a human (or an explicitly instructed session).
225. ## Stage F5: Outreach audit *(2026-08-10)*
226. Produces the second weekly spreadsheet: `05-Outputs/Bitrix_Pipeline_Outreach_Audit_<date>.xlsx`,
227. one sheet per outreach funnel: **24** Partner Tier Upgrade · **26** Winback ·
228. **36** Quarterly Check-In · **16** Abandoned Carts. **Those four and only those four**
229. (scope set by Matt 2026-08-10; 7 Days Delivery Up-Keep and Cold Outreach are deliberately
230. out of scope. `AUDIT_FUNNELS` in the driver is the single place that defines this, and
231. adding to it is a decision, not a tweak). Each row is a client with the details Ines needs
232. to find them in Plinth (Plinth ID, email, phone, company, tier, LTV) plus **the date they
233. were last actually reached out to**. Read-only on Bitrix and on vault data.
235. **Two passes, because the full sweep is too expensive to repeat weekly.**
236. 1. `outreach-pull-list --deals <enumeration.json>` reads the weekly deal enumeration and
237. `data/outreach_touch_cache.json` and writes `outreach-pull-list_<date>.json` with
238. `need_history` (deals to re-pull) and `need_contact` (deals needing a `get_record`
239. contact lookup). A deal is served from cache only when its stage is **unchanged** since
240. the cache was written AND either (a) that stage is terminal, or (b) the cached touch count
241. is **zero**: it has never entered a send stage, so it cannot be sitting in one, and a send
242. would have moved it. (b) is what keeps the big parked cohorts cheap. Deals *with* touches
243. sitting in a send stage are always re-pulled, because a repeat send re-enters the same
244. stage (cat 26 Follow-Up Email does exactly this). **Measured 2026-08-10** (four funnels):
245. with the cache warm, the next run needed **a fraction of the first full run's history
246. pulls and contact lookups**. The sample shows the same shape: 54 histories fresh and 9
247. contact lookups on 2026-09-14, then 18 fresh, 36 from cache and 2 lookups on 2026-09-21.
248. 2. Claude pulls `get_stage_history` for the `need_history` ids and `get_record` for the
249. `need_contact` ids, attaches them to the enumeration, then `outreach-audit --deals
250. <that file>` computes the touches, resolves Plinth identity, writes the workbook, and
251. updates the cache.
253. **What counts as contact.** Only stage entries with a real outbound email, call or LinkedIn
254. DM behind them: the per-funnel `SEND_TOKENS` sets in `partner_pipeline/stages.py`. System
255. reactions (No - Reply, No Reply Nth Email (Auto), Email Defunct, Changed Companies, Not
256. Interested, Completed) are **not** contact. One trap is encoded there and must not be
257. "simplified": **cat 26 `FINAL_INVOICE` is called "Pre-Call Email" and IS a real send**,
258. while an out-of-scope funnel uses that identical label for its creation stage, which sends
259. nothing. Never key the rule on the stage *name*. Cat 26 `UC_L2JMHY` ("Activated") is left
260. out on purpose: it is the intake bucket, and nothing is sent on that move.
262. **Retired stages.** Six stage ids were deleted from their funnel config, so Bitrix returns a
263. bare token with no name and a naive audit silently drops them. They were identified on
264. 2026-08-10 by matching each stage-entry timestamp against the deal's outbound email timeline
265. (see [[DECISIONS]]): cat 24 `PREPARATION` / `UC_CEAGAV` / `UC_V6JARB` are sends,
266. `UC_N4JCMW` is a bulk move that is not; cat 26 `UC_PMLDJW` / `UC_GDHDJR` are the Feb 2026
267. feedback-survey send + reminder. `RETIRED_STAGE_NAMES` keeps them named. **Do not delete
268. them**: without them clients reached only through those stages read as never contacted.
270. **Touch count is best-effort, the date is not.** Same-minute workflow re-entries into one
271. stage collapse to a single send (`SAME_SEND_GAP_MIN`, 2 minutes); a bulk re-stage days apart
272. still counts. Read "Last reached out" as reliable and "Touches" as indicative. A last contact older
273. than `AUDIT_STALE_DAYS` (90) is shaded red on the sheet and counted on the Summary.
275. **Enumerating the big parked stages: solved 2026-08-11.** A whole-day `created_on` filter
276. truncates at 200 rows, which used to leave `C26:UC_JUUNES` ("Client") and `C16:NEW`
277. ("New Abandoned Cart"), both larger than that, partially listed (measured 2026-08-10).
278. Sub-day time bounds **do** work; they are not ignored. The bounds resolve against Bitrix's
279. own server offset, so pass `tz=Europe/Moscow` alongside the CDT wall-clock window and walk
280. narrow windows; a 15-minute window returns a complete, untruncated set (the connector
281. reports "showing N of N"). The identical call **without** `tz` returns "No matching deals". **Always verify
282. coverage** (the union of your windows must equal the stage's reported total) rather than
283. trusting a single call. The recipe is verified; the mechanism inside the connector is not.
285. **Gaps are recorded, not hidden.** The enumeration JSON still carries an `enumeration_gaps`
286. block. If a whole funnel goes missing the run warns loudly and stamps "INCOMPLETE RUN" on the
287. Summary sheet rather than shipping a clean-looking partial workbook.
289. **Anyone the audit cannot place in Plinth** lands in `outreach-unresolved_<date>.json`, and
290. the next `outreach-pull-list` adds them to `need_contact` so one `get_record` closes the gap
291. permanently: the contact email persists in the cache from then on.
293. ## Stage G: Enrich *(human-approved)*
294. - Run the **`client-enrich`** skill on the new + changed stubs. It appends only under
295. `## Research`, sources every claim, and logs its own LEDGER entry. Needs Apollo + Apify
296. connected.
298. ## Stage H: Push to Bitrix *(human-approved, always)*
299. - Run the **`partner-pipeline-push`** skill on the approved cohort. One deal per client,
300. deal name = `first_name + " " + last_name`, tagged by User Group, enrichment profile
301. posted as a deal comment. Needs Bitrix connected. **Never unattended.**
303. ---
305. ## Guardrails (non-negotiable)
306. 1. **Shared vault → LEDGER.** Any stage that creates/edits/moves a vault file appends one
307. batched entry to [[LEDGER]], attributed by session email (`hello@meridiandisplay.example`
308. = Matt, `accounts@meridiandisplay.example` = Hazel), timestamp from the system clock.
309. See [[CLAUDE]].
310. 2. **Human Notes are sacred.** Automation never writes `## Human Notes`. `## Research` is
311. only ever touched by `client-enrich`, never by the classifier.
312. 3. **Facts are sourced.** Enrichment claims carry a source URL or a `[TBD]` marker.
313. 4. **PII stays put.** Plinth returns live customer PII. It goes into the spreadsheet and
314. stubs, not into chat summaries or anywhere external.
315. 5. **Bitrix is human-gated** regardless of `autonomy`.
316. 6. **The outreach audit is read-only on Bitrix.** Stage F5 reads stage history and deal
317. records and writes nothing back. Reading Bitrix is not the same as routing into it:
318. the hold in [[pipeline-routing-rules]] is on *creating deals and moving stages*, which
319. stays human-gated. Never let the audit "fix" a stage it thinks is wrong.
320. 7. **No-shrink.** Lifetime history only grows. If `verify` exits 2, the run stops and a
321. human looks at it. No tier demotion, no Winback routing, no stub downgrades off a run
322. whose totals went backwards: that is the Plinth truncation bug's signature, not reality.
324. ## Run log
325. This table was never kept up. [[LEDGER]] is the reliable per-run record. The rows up to
326. 2026-08-10 record which runs happened on the full book; their figures are not carried into
327. this repo. The last two rows are the
328. shipped sample's replay (`07-Automation/sample/run_sample.py`), with the real numbers from
329. `05-Outputs/partner-runs/run-log_2026-09-14.txt` and `run-log_2026-09-21.txt`.
331. | Run date | Mode | Armed? | Partner Clients | New stubs | Changed | Pushed | Notes |
332. |----------|------|--------|----------|-----------|---------|--------|-------|
333. | 2026-07-23 | ltv_bands | yes | n/a | n/a | n/a | no | Partner backfill: the run that grew the vault from the founding cohorts to the whole partner base |
334. | 2026-07-27 | ltv_bands | yes | [TBD] | [TBD] | [TBD] | no | Artifacts existed; figures not recorded |
335. | 2026-08-03 | ltv_bands | yes | n/a | n/a | n/a | no | verify OK |
336. | 2026-08-10 | ltv_bands | yes | [TBD] | [TBD] | [TBD] | no | First run producing both spreadsheets (F2 + F5 audit) |
337. | 2026-09-14 | ltv_bands | yes | 128 | 128 | 0 | no | Sample, first run after the 2026-09-07 seed (381 accounts). 29 orders added; verify OK; tiers Palladium 85 · Platinum 28 · Iridium 8 · Rhodium 7; 1 FLAGGED messy name; XML 128 chunks added; reconcile 45 new blocks; route winback 50 (1 role-named held) / cat24 29 / dormant 4 / excluded 45; audit 54 deals, 26 touched, 3 unresolved, 54 histories fresh |
338. | 2026-09-21 | ltv_bands | yes | 130 | 2 | 128 upgraded | no | Sample. 93 orders added; 2026-09-17 truncated at 50 and paged to convergence (+50, +19, +0); 1 new customer (has_baseline=False); verify OK; tiers Palladium 86 · Platinum 29 · Iridium 8 · Rhodium 7; XML 128 stamped + 2 added = 130; reconcile 2 updated, 43 current; route winback 50 / cat24 31 / dormant 4 / excluded 45; audit 54 deals, 28 touched, 18 histories fresh, 36 from cache |