Operations automation pilot
Tracked workflows instead of status email chains
Client
~60 people across delivery and sales, mostly Australia with a few offshore contractors. No dedicated internal IT—ops manager owned tooling decisions.
How we engaged
Websi-led delivery, day-to-day with the ops lead and one sales coordinator. Weekly check-ins with the GM.
Stack & tooling
- Monday.com (boards, automations, mirrored views)
- Airtable (structured line items + linked records)
- Native email notifications + Slack webhook for failures
- Documented runbook in Notion
A mid-sized services firm was running job delivery through shared inboxes and ad-hoc spreadsheets. We mapped the real handoffs, stood up Monday.com as the operational spine, and used Airtable for one structured data slice—with alerts when automations failed.
Starting point
Every new engagement kicked off in email. Delivery status lived in a mix of the CRM, personal task lists, and a shared spreadsheet that half the team didn’t trust. When someone went on leave, handovers were verbal. The GM could see revenue in the CRM but not whether jobs were stuck waiting on client sign-off or internal QA.
Challenge
The team didn’t want “another platform” without a clear win. Previous attempts at templates had died because nobody maintained them. Leadership needed visibility without adding data entry that reps would skip under pressure.
Approach
We started by shadowing two real jobs end-to-end—messy edge cases included—before touching configuration. Status names were agreed in a workshop (verbs and stages the whole team could say out loud). Monday.com held the workflow; Airtable held one domain that needed relational data. Automations were deliberately narrow at first: notify on stage change, daily digest to the GM, and a hard stop if an integration returned an error so nothing silently failed.
Outcomes
- ✓One board became the reference for “where is this job?”—including a read-only view for leadership
- ✓Status-update email threads dropped sharply once the digest and stage automations were live
- ✓Runbook covered how to pause automations during busy season and replay missed steps
- ✓Clear backlog for v2 (CRM sync) once v1 behaviour was stable for a month
Constraints & non-negotiables
Limits shape what ships now vs later — these were ours on this job.
- · No budget for enterprise integration middleware in phase one
- · Some staff only checked email on mobile—notification copy had to be short and actionable
- · CRM remained system of record for opportunities; we didn’t fight that in v1
Phases
Order and emphasis change by client — this is how this one ran.
- 1
Weeks 1–2 · Discovery
Interviews, process sketch on a wall, agreement on definitions of “in progress”, “blocked”, and “done” for their context.
- 2
Weeks 3–6 · Build
Board structure, permissions, first automations, Airtable schema tied to Monday items, test with two pilot teams.
- 3
Weeks 7–8 · Rollout & tuning
Wider go-live, fix naming confusion, tighten notifications after feedback, record Loom walkthroughs for new starters.
- 4
Weeks 9–10 · Handover
Runbook, named owners for each automation, and a 30-minute session with the ops lead on safe changes.
What actually worked
Shipping a thin v1 that matched how people actually talked about work—not the ideal process diagram from a slide deck. Saying no to CRM sync until behaviour was stable saved weeks of rework.
Real delivery patterns; names and details blended for confidentiality. Happy to walk through a comparable scope.