Buddy Program Manager

Buddy Program Manager defines a small peer-support workflow for new joiners. Its recommendation is to match by department and timezone and track a limited number of check-ins, without building a scoring system. Three check-ins over thirty days are suggested as a lightweight starting point; the actual setup follows confirmed context. The sequence covers a new joiner, buddy match, check-ins, feedback, and recognition.

The default output is a recommendation. Advice receives an answer, reviews check the supplied process, and artifacts are built when requested. Intake considers joiner volume, same-team or cross-team pairing, duration, cadence, feedback, buddy eligibility, time allocation, recognition, current practices, and desired output. Missing questions are asked one at a time and unknown answers remain unknown.

Use it for a buddy program, new-hire buddy process, or peer-onboarding tracker. It fits Scale stage in the Onboard layer. A request can be:

New joiners feel lost in week one and nobody notices.

It creates empty templates. It does not automatically assign buddies or send reminders without a connected tool, and provides no automation or synchronization. It does not calculate payroll, tax, leave, or KPIs. A match is a supported assignment, not a performance judgment.

The twelve fields are Buddy Pair, New Hire, Buddy, Department, Start Date, End Date, Check-ins Planned, Check-ins Done, Feedback Score, Status, Notes, and Buddy ID. New Hire and Buddy are relations, dates retain date types, and counts and Feedback Score are numeric. The score field does not change the recommendation against a scoring system. Pair statuses start with Not Started, Active, Paused, and Completed.

Requested CSV, SQL DDL, JSON Schema, and Notion mapping derive from one field list. Display names remain consistent across CSV and JSON, with normalized SQL identifiers documented. Excel-compatible CSV uses a UTF-8 byte order mark and needs date and number formatting after import. Workbooks require a specific request; examples must be requested and synthetic.

Matching guidance confirms consent, start date, timezone, language, accessibility needs, manager boundaries, and contact cadence. Keep match rationale separate from personal data and never infer compatibility from protected characteristics. Each check-in records date, channel, attendance, topics, agreed next step, and escalation owner. A missed check-in records the attempt and prompts a support question; it does not prove disengagement. Closing a match requires documented end dates for both participants or approved reassignment.

Conversation guidance covers goals, boundaries, privacy, attempted work, blockers, requested support, and agreed action without unnecessary sensitive stories. Event statuses include planned, scheduled, held, rescheduled, missed, escalated, and closed. Manager escalation needs permission unless an explicit safety or policy exception applies; record the exception and minimum necessary detail.

Notion output goes to notion-manual-import and requires relation targets before links resolve. Manual mappings need no connection. Live writes require verified access, target, authorization, and successful tool evidence.

Sensitive review inputs are minimized and templates remain empty. Consequential privacy, legal and disciplinary cases require qualified human review.