Agreed pilot decisions

Small-team starting point

24 companies: 12 technology and 12 non-technology, reviewed in groups of 6. One primary contact per company.

Current priority labels: High priority · Relevant · Needs research · Keep warm · Outside target.

Numerical scoring is deferred. Older sample scores are historical experiments.

Open the prepared Week 1 review pack · Review the supplied meeting sample · Open the Week 1 fixture workspace

Sourcing evidence replaces decision 14

Rey reports a free-tier API experiment across 218 Azure-partner companies: 96 with a named contact and 85 with an email. These are reported external results, not a live run from this app or 85 approved buyers.

Domain-only discovery: Anymail Finder. Known-person enrichment: Apollo. Supplementary coverage: Hunter within the available quota. Review current role, employer and email status before selecting the primary contact.

The 218-company CSV is supplied and shared draft save/reload has been verified. New free-only provider adapters have been created because the earlier scripts are unavailable. Live testing still needs provider keys, endpoint access and confirmed free allowances. No paid upgrades are enabled. Our shared pilot master remains separate from Kabel’s operational master until reconciliation and cutover review.

1. Which non-tech sectors come first?

Adopted by Rey

Start with distribution/logistics and business/professional services. Treat them as pilot hypotheses and retain the balanced tech/non-tech mix.

Owner: Rey; Esther reviews

Implementation / remaining input: Apply sector filters to the next reviewed batch; public evidence must establish the category.

2. Which technology companies come first?

Adopted by Rey

Prioritise software/SaaS and implementation/technology-services companies. Separate internal DXP customer needs from delivery-partner and ecosystem opportunities.

Owner: Rey; Esther reviews

Implementation / remaining input: Research internal problems; partner status alone does not qualify a customer.

3. Which headcount applies?

Adopted by Rey

Use the Malaysian operating business headcount for non-tech eligibility; retain global headcount separately. Unknown local figures stay unknown. All technology companies are size-exempt.

Owner: Rey

Implementation / remaining input: Add explicit local/global evidence fields before applying the revised filter.

4. Who handles size exceptions?

Adopted by Rey

Esther reviews non-tech exceptions; TK decides unusual commercial cases. Record problem, sponsor and project-support evidence. Keep exceptions visible outside the standard cohort.

Owner: Esther; TK escalation

Implementation / remaining input: Capture the actual exception decision per company; the policy does not approve individual exceptions.

5. How do we score now?

Adopted by Rey

Use High priority, Relevant, Needs research, Keep warm and Outside target. Defer 80/20, numerical anchors, thresholds and referral points. Keep outreach priority separate from discovery readiness.

Owner: Rey

Implementation / remaining input: Replace active numeric qualification with evidence-backed labels; existing numeric results are historical experiments, not conversions to the new labels.

6. What volume should we target?

Adopted by Rey

Initial batch: 24 companies, approximately 12 tech and 12 non-tech, one primary contact each, reviewed in groups of six. After review, begin with 10–15 new companies per week and scale with capacity.

Owner: Rey; Esther reviews

Implementation / remaining input: Keep sourced companies, contacts and messages separate. The 218-company provider experiment is not the balanced 24-company outreach pilot.

7. Can a roundtable prospect have no known problem?

Adopted by Rey

Yes, with strong company/buyer fit and an honest event-relevance thesis. Record unknown problems and triggers. Direct DXP outreach requires a credible problem signal.

Owner: Rey; Esther reviews

Implementation / remaining input: Separate roundtable review from DXP opportunities; never invent urgency.

8. Where do senior HR enquiries go?

Adopted by Rey

Relevant DXP needs use the normal DXP route. Broader workforce-platform interest goes to Camelia for later follow-up; do not create a separate campaign yet.

Owner: Camelia; Rey routing

Implementation / remaining input: Record the enquiry and next action without treating recruiter-only contacts as primary DXP buyers.

9. When can we switch contacts?

Adopted by Rey

One active sequence per company. Switch after a referral or evidence of unsuitable role. After non-response, finish the sequence and let Esther review any alternative. Preserve company-wide refusals.

Owner: Esther; Rey controls

Implementation / remaining input: Do not let a new contact bypass a reply, rejection or company suppression.

10. Who approves each decision?

Adopted by Rey

Esther: leads and corrections. Camelia: relationship messages and substantive replies. TK: commercial claims, unusual exceptions and offer changes. Rey: platform/leads/delivery. Rafa: content/evidence/reporting. Use batch review and escalate exceptions.

Owner: Named role owners

Implementation / remaining input: Adopted by Rey; this is not evidence that each named person has accepted access or availability. Actual actions require recorded reviewer identity and revision.

11. What is the outreach sequence?

Adopted by Rey

One personalised introduction and up to two useful follow-ups, approximately five business days apart from actual sends. Camelia is the initial relationship sender. Any reply pauses generic follow-ups; opt-out stops marketing. Review replies within one business day.

Owner: Rey; Camelia reviews

Implementation / remaining input: Build and verify live reply/stop controls before activation. Newsletter permission stays separate; no-response ends in pause/review.

12. How does event follow-up work?

Adopted by Rey

One event record with approved invitation, date, attendance and follow-up rules. Attendees get discussion-relevant next steps; non-attendees may receive a recap or later opportunity; concrete needs go to discovery; preferences are respected.

Owner: Esther attendance; Camelia relationships; Rey execution

Implementation / remaining input: Supply the actual event brief and feed. Attendance alone is not buying intent.

13. Where is the authoritative master?

Adopted by Rey

Supabase is the target operational system of record; CSV/Sheets support import, export and reporting. Retain the current authoritative Kabel list until mapping and migration are verified. One writer, stable IDs, staging and audited approval.

Owner: Rey integration; Alex infrastructure coordination

Implementation / remaining input: Architecture decision adopted; live migration is not completed. No dual editable masters or automatic production migration.

14. Which sourcing tools should we use?

Adopted with sourcing amendment

Replace the old provider-selection proposal with the tested flow: company/domain → identify relevant people → enrich → find/verify email → reviewed CSV/staging. Use Anymail for domain-only discovery, Apollo for known-person enrichment, Hunter as quota-limited supplementary coverage. Retain public-web research for gaps.

Owner: Rey

Implementation / remaining input: Screenshots report external free-tier tests. Integrate actual scripts/output, confirm endpoint entitlement and remaining allowance, reconcile costs and retain role/email review. No subscriptions or budget ceiling were approved.

15. How should data be handled?

Adopted by Rey

Send only task-relevant data to approved providers; restrict raw transcripts, use excerpts when possible and separate private evidence from publishable claims. Preserve reviewed corrections.

Owner: Rey controls; Kabel data owner

Implementation / remaining input: Provider-specific processing permission, access and retention duration are still concrete inputs to supply, not implied by adopting this principle.

16. How should the system learn?

Adopted by Rey

Apply feedback to the current draft or record. Propose shared instruction changes separately, summarise them weekly and require review before activation. Keep versions and supporting examples.

Owner: Rafa learning; Rey targeting changes

Implementation / remaining input: No automatic global prompt rewrites or model retraining. Record-level correction is not a new universal rule.

17. What content and integrations come first?

Adopted by Rey

Two LinkedIn drafts and one outreach variant per week from approved evidence. Add carousel/video when useful. Start with one publishing channel, human publication approval and linked outcomes. Design for paid ads without activating spend.

Owner: Rafa content; Rey email

Implementation / remaining input: Account permissions, cleared source assets and actual publication approvals are needed. Live social/ads connectors are not implemented by this decision.

18. What happens after discovery?

Adopted by Rey

ReRa prepares a short summary and proposal draft. Camelia confirms the need; TK approves commercial terms. Use one approved template and preserve gaps in price/scope/support. Verbal yes is separate from signed.

Owner: Rafa workflow; Camelia/TK approvals; Rey delivery

Implementation / remaining input: Provide the real template/terms and confirm the exact scope revision before issue.

19. What makes the pilot successful?

Adopted by Rey

Review 20–30 companies, using 24 as the working batch. Every released lead has evidence, owner and next action. Require duplicate-send prevention, suppression, reply pauses and preserved corrections. Target about 30 review minutes/day and at least 80% needing no major company/contact correction.

Owner: Rey reliability; Rafa evidence; Kabel acceptance

Implementation / remaining input: Measure these targets; adoption does not mean they passed. Record useful replies/discovery/problems without claiming an ICP or guaranteed sales.

20. Who operates and supports it?

Adopted by Rey

Esther owns the daily queue; Camelia owns relationships. One daily summary covers reviews, replies and failures; urgent alerts are reserved for critical delivery/suppression uncertainty. Kabel owns production accounts; Rey/Rafa provide guides and training.

Owner: Esther; Camelia; Rey; Rafa

Implementation / remaining input: Name backups, verify access and agree ongoing support terms. Those identities and terms cannot be invented.