The 11pm Slack Question That Should Be a Scheduled Job

Why 11pm Questions Happen

DTC stacks are built tool-by-tool: Shopify, Klaviyo, Gorgias, Stripe, 3PL APIs. Each tool has its own truth. When data doesn't move between them on schedule, or when status is unclear, operators ask. Late-night questions are louder because urgency is higher - a campaign launches tomorrow, or a customer escalation needs resolution.

The real problem is not the question. It's that the question exists at all. If an operator must manually check whether Shopify synced to Klaviyo, or whether a batch of orders hit the 3PL, the stack has no operator layer - no scheduled job, no alert, no dashboard that answers the question automatically.

Anatomy of a Recurring Manual Query

A recurring manual query has three parts: a trigger (a time, an event, or a person's worry), a data source (one or more tools), and a decision or action (ship it, pause it, investigate it).

Trigger: 'We're about to send a campaign' or 'A customer complained' or 'It's been 4 hours since the last sync'
Data source: Shopify order count, Klaviyo segment size, Stripe payout status, 3PL inventory, Gorgias ticket queue
Decision: 'Is it safe to send?' 'Did the sync fail?' 'Are we behind on fulfillment?'

The Operator Layer: What It Does

An operator layer is a set of scheduled jobs, webhooks, and alerts that answer cross-tool questions without human input. It monitors, validates, and reports on data movement and status.

Examples:

Hourly job: Check Shopify order count vs. Klaviyo order count. Alert if delta > threshold.
Nightly job: Pull 3PL inventory, compare to Shopify stock levels. Flag mismatches.
On-order job: When Shopify order is created, verify it appears in fulfillment tool within 15 minutes. Escalate if not.
Pre-campaign job: Run segment in Klaviyo, cross-check against Shopify customer data. Report suppression rate and any anomalies.
Daily job: Aggregate Gorgias open tickets, Stripe failed charges, and 3PL exceptions. Send summary to Slack at 8am.

How to Identify Candidates for Automation

Track Slack questions for one week. Log the time, the asker, the tools involved, and the resolution. Then apply this filter:

Does the question recur? (Asked more than once in the past month.)
Is it cross-tool? (Requires checking two or more platforms.)
Is the answer deterministic? (A yes/no, a number, a list - not subjective.)
Does it drive a decision or action? (If the answer is 'no', the question is noise.)
Can it be answered by data? (Not 'What should we do?' but 'What happened?')

Building the Job: Scope and Threshold

Once a candidate is identified, define the job in three parts: scope, check, and alert.

Scope: What data will the job pull? From which tools? How far back? (Last 24 hours, last order, last sync window.)

Check: What comparison or calculation will it run? (Count delta, timestamp gap, field mismatch, missing record.)

Alert: If the check fails, what happens? (Slack message to #ops, PagerDuty alert, email to founder, auto-retry, or just log it.)

Example: Scope = Shopify orders created in last 2 hours. Check = Does each order exist in 3PL system within 15 minutes? Alert = If not, post to #fulfillment with order ID and last sync time.
Example: Scope = Klaviyo segment 'Active Customers' as of 6am. Check = Does segment size match Shopify customer count (filtered by last purchase < 90 days)? Alert = If delta > 5%, post to #marketing with both numbers.

Routing and Ownership

Not all alerts go to the same place. Route by severity and domain.

Critical (blocks revenue or fulfillment): PagerDuty or SMS to ops lead. Example: 3PL sync failed for 2+ hours.

High (impacts campaign or customer): Slack channel + daily summary. Example: Segment size anomaly, suppression rate spike.

Medium (informational, needs investigation): Slack thread or daily digest. Example: Sync lag, data discrepancy.

Low (audit trail): Log only, no alert. Example: Nightly reconciliation report.

Assign ownership: Who owns the job? Who fixes it if it fails? Who reviews the alerts? Document this in the job definition.

Checklist: From Question to Job

Use this checklist to move a recurring question into a scheduled job:

Log the question: When, who, what tools, what was the answer?
Verify recurrence: Has it been asked 2+ times in the past 30 days?
Define scope: What data? Which tools? Time window?
Define check: What comparison or calculation?
Set threshold: At what point does it alert? (e.g., delta > 10, lag > 30 min)
Choose alert method: Slack, email, PagerDuty, log?
Assign owner: Who monitors? Who fixes?
Build and test: Run the job manually first. Verify it catches the problem.
Deploy and monitor: Run it on schedule. Track false positives and false negatives for 2 weeks.
Iterate: Adjust threshold or alert method if needed.

Questions

FAQ

What if the job requires custom API work or data transformation?

That's normal. Most operator jobs need to pull from multiple APIs, transform data, and compare. Budget 4 - 8 hours of engineering per job. If the job recurs weekly and saves 30 minutes of manual work, it pays for itself in 2 - 3 months.

How do we know if a job is working?

Track two metrics: alert accuracy (what % of alerts are true positives?) and resolution time (how long from alert to fix?). If accuracy is below 80%, the threshold is too loose. If resolution time is > 2 hours, the alert routing is wrong.

Should every Slack question become a job?

No. Only questions that recur, are cross-tool, have a deterministic answer, and drive a decision. One-off questions, subjective questions, and questions that are answered by reading a dashboard are noise. Filter first.

What if we don't have engineering resources to build these jobs?

Start with the highest-leverage questions - the ones that block campaigns or fulfillment, or that are asked most often. Prioritize by frequency × impact. Use no-code tools (Zapier, Make) for simple jobs. For complex jobs, hire a contractor or allocate engineering time.

Want this on your account?

Thirty minutes. Bring the number that keeps you up.

Book a demo