Gift Card Triage

Gift Card Triage

Triage pending gift-card reward requests from a rewards spreadsheet. Identifies new requests that need review, flags duplicates and prior rewards, and runs referral fraud checks to produce approve/deny/investigate verdicts.

Prerequisites

• A Google Workspace CLI that can read Sheets — either gog or gws. Check with which gog and which gws; if both are available, prefer gog.
• The referral-fraud-check skill — used to validate referrals.

Configuration

Set these in your .env (see .env.example):

• REWARDS_SHEET_ID — the spreadsheet ID backing the reward queue. This sheet contains PII (emails, names, tokens); keep it private.
• APPROVALS_CHANNEL_ID — optional Slack channel for posting the summary.

Workflow

Step 1: Fetch sheet data

Use the available Google Workspace CLI to fetch the rewards tab from $REWARDS_SHEET_ID as JSON, including the header row. Parse the first row as headers and locate columns by name (do not assume fixed positions). Typical columns: an email, a tier, a submission timestamp, a program name, a "Sent?" column (empty = not yet processed), a submitter name, and a token column (populated when sent).

Step 2: Separate pending vs. already-sent

• Pending: rows where "Sent?" is empty — these need triage.
• Already sent: rows where "Sent?" is non-empty — historical records.

Filter out redacted rows (where the email is blank or masked).

Step 3: Flag duplicates

Flag duplicate submissions in the pending set (same email + same tier); only one reward should be sent per email+tier.

Step 4: Check prior rewards

For each pending email, check whether it also appears in the already-sent set and note which tiers were already fulfilled, to avoid double-sending.

Step 5: Identify the program

Group pending requests by their program column (e.g. referral tiers vs. non-referral rewards like surveys or interviews). Referral tiers need a fraud check; non-referral rewards just need a real/active-user check.

Step 6: Run referral fraud checks

Collect the unique pending emails and run the referral-fraud-check skill (read that skill for the workflow — it spawns a cloud agent with warehouse access). Pass all emails in one batch; each returns APPROVE / DENY / INVESTIGATE.

Step 7: Present results

Summarize by verdict (DENY, INVESTIGATE, APPROVE). For each email include the program/tier, submission date, verdict + key reason, and any flags (duplicate, prior reward, name/email mismatch). Also note totals, duplicates skipped, and prior-reward conflicts.

Step 8: Send to Slack (optional)

Only if explicitly asked. Format as Slack mrkdwn and post using $BUZZ_SLACK_TOKEN to $APPROVALS_CHANNEL_ID.

Edge Cases

• No Google Workspace CLI available: ask the user to install gog or gws.
• CLI not authenticated / sheet access denied: guide the user through auth or suggest an account with access.
• Zero pending rows: report that all rewards are up to date.
• Redacted emails: skip rows with blank/masked emails.
• Same email, different programs: check each program separately.

Constraints

• Do NOT hardcode or log any tokens, sheet IDs, or PII.
• The referral-fraud-check skill handles all warehouse work — this skill stays local.