Scaling AI adoption at work is not primarily a software-access problem. It is a capability-building problem. Pair hands-on learning with a pipeline of real, repeatable workflows, named owners, proportionate guardrails, and measures of operational outcomes. Start with work that has visible friction, a stable source of truth, and a person who can judge whether the result is useful.
Zapier’s account of AI transformation at Jobber provides a case-informed starting point, not a technical specification. This guide separates what Zapier reports from what those figures establish, then develops a transferable operating model and an illustrative design for the reported onboarding use case. The proposed schemas, controls, and workflow steps are recommendations, not a reconstruction of Jobber’s private configuration.
What Jobber’s story reports, and what it does not establish
Zapier identifies Ethan Schwandt as Jobber’s Senior Manager, Talent Acceleration. Its customer story reports a leadership hackathon involving 55 directors, a hands-on session involving 161 employees, and a 122% increase in Jobber’s active Zapier builder population during the first 30 days of the adoption push. Zapier also says Jobber was running hundreds of active workflows by summer, that those workflows connected 28 business-system apps, and that Jobber teams were using Zapier MCP across 20 apps. The Zapier speaker profile provides additional context about Schwandt’s role.
These are figures reported by Zapier, not independently audited results. The source does not define the active-builder population, its baseline, its ending count, or the measurement method. It also does not define whether the workflow count excludes tests, paused workflows, or other non-production activity. Participation, workflow, app, and MCP counts are therefore adoption signals. They do not by themselves demonstrate productivity, financial return, time savings, or sustained adoption.
The transferable lesson is the combination of leadership participation, hands-on learning, office hours, curated resources, onboarding, team rituals, and governance. Jobber’s reported approach aimed to help employees build useful workflows themselves rather than relying on a small central automation team. The model below adapts that principle without claiming to reproduce Jobber’s internal process.
Build the conditions for useful workflow adoption
Begin with recurring work, not an open-ended hunt for places to use AI. Prioritize a process with a clear owner, visible waiting or rework, a stable source of truth, and a defined destination. Use ordinary automation for predictable checks and writes. Reserve AI for interpreting unstructured text, grouping themes, summarizing supplied material, or drafting language that a person can validate.
Make adoption part of how teams learn and operate. Give employees a practical building session, a support path for questions and exceptions, and clear rules for testing and publishing. Every production workflow should have an owner responsible for access, maintenance, exception handling, and reviewing whether the workflow remains useful. Organizations that need help designing or maintaining these automations can review Zapier automation services.
A bounded design for the reported onboarding workflow
Zapier reports that Katy Kowalczuk’s onboarding team connects Livestorm registration data to a live sheet, uses the information to generate presentation materials in Claude, and sends output to Slack. It also describes a separate workflow that tracks attendance and summarizes chat feedback. Zapier says these workflows reduced the need for manual recaps and improved visibility into activity, but it does not provide a quantified baseline or technical implementation.
The following is an illustrative implementation design. The source does not publish the sheet schema, prompt, Claude connection path, output format, Slack review behavior, or complete Zap configuration. Zapier documents Livestorm’s New Registrant trigger and separate attendance-related triggers. Its related official template captures Livestorm registrants in Google Sheets, adds them to a HubSpot list, and notifies Slack. It is a related registration pattern, not Jobber’s complete workflow. Zapier also documents an Anthropic (Claude) Send Message action requiring Anthropic API access and an API key, but the Jobber story does not identify that as the connection method.
Registration to a reviewed presentation draft
- Receive and filter: Use Livestorm’s New Registrant trigger and filter for the intended event or session. Require a stable registrant identifier, event ID, and session ID before continuing.
- Write the source record: Store the registration in a defined sheet or other system of record. Document the schema, destination owner, access rules, and retention period. Keep only fields needed for the presentation task.
- Assemble approved context: Combine the session title and approved presentation material with the registration records. Registration is not evidence of attendance, satisfaction, or customer performance.
- Draft and validate: Ask the AI to produce a bounded title and outline. Reject empty required fields, check any totals against source records, and route unsupported or inconsistent content to the onboarding-operations owner.
- Approve and publish: Save the draft, its source references, generation time, and approval status. Route sensitive or leadership-facing material to a human reviewer before posting the approved result or link to Slack.
A proposed output contract could look like this. It is an illustrative contract, not Jobber’s published schema:
{
"source_system": "livestorm",
"event_id": "event-illustrative-27",
"session_id": "session-illustrative-03",
"presentation_title": "Customer onboarding: session overview",
"presentation_outline": [
"Session goals",
"Approved topics and examples"
],
"source_record_ids": [
"registration-illustrative-1042"
],
"input_snapshot_at": "2026-11-12T14:05:00Z",
"generated_at": "2026-11-12T14:06:00Z",
"needs_human_review": true,
"approval_status": "pending",
"output_version": "1"
}The record above represents one session-level draft linked to its input records. It should not be used as a registration, attendance, CRM contact, or deal event. For a separate attendance and chat recap, keep attendance counting deterministic and use AI only to group or summarize supplied chat messages. Store the recap as a versioned session-level output, with source message and attendance record IDs. If attendance data is missing or a count does not match the source records, hold the recap for the events or onboarding-operations owner.
Keep registration, attendance, and recap data separate
Define what one record means before building the workflow. A registration row represents one registrant in one session. Attendance is a separate attendance event or final status for that registrant-session. A chat message is one message if message-level records are retained. A recap is one version of a summary for a session and reporting period. Keeping these grains separate makes duplicates and misleading totals easier to detect.
- Registration: Prefer a stable vendor registration or registrant ID plus session ID. A proposed key is
source_system + registrant_id + session_id. - Attendance: Use an attendance event ID when available. If storing a final state, key it by
source_system + registrant_id + session_id + attendance_event_typeand update that state deliberately. - Chat message: If retained, use
source_system + session_id + chat_message_idso two messages from the same participant remain distinct. - Recap: Use
source_system + session_id + reporting_period + recap_version, or a unique run ID when multiple generated versions may exist.
Do not use email alone as a unique key. One person may register for several sessions, register again, or change an address. When a vendor does not provide a stable source ID, use a composite key that distinguishes the session and event type. Preserve the input snapshot time, source record IDs, prompt or model identifier, generation time, reviewer, and approval status so a recap can be traced to its inputs.
A lookup followed by a create can still produce duplicate rows when two runs search before either writes. Trigger-level deduplication does not guarantee downstream uniqueness. When concurrent processing is possible, use a destination-enforced unique key, a transactional upsert, or a serialized queue. See Zapier’s duplicate-handling documentation.
Separate deterministic rules from AI judgment
Use deterministic logic for event and session filtering, required-field checks, identity matching, attendance-state normalization, duplicate handling, destination routing, permissions, and record writes. Put validation immediately after any step that can return variable or unstructured data, before that data updates a record or sends a message.
Use AI for bounded interpretation, such as grouping open-text feedback or drafting presentation language from approved material. Define required fields and allowed formats, then validate the content against the source. Structured output is useful for checking shape, but it is not proof that the content is supported by its inputs. Zapier documents structured output and per-tool approval controls for AI by Zapier, but the Jobber story does not say Jobber used those features. Teams considering broader AI-enabled workflows can review AI agent services.
For this onboarding example, do not ask the model to decide who attended or calculate a definitive attendance rate. Use attendance records and deterministic logic for those facts. The model can summarize supplied chat themes, while a person resolves missing or conflicting data and approves material that could mislead a customer or leadership audience.
Two related workflow patterns
Registration to presentation draft: Livestorm New Registrant triggers the workflow, an event or session filter narrows the scope, and a registration record is written to a defined destination. Approved session context is passed to the AI for a title and outline. Required identifiers, fields, and source-supported claims are checked before a reviewer approves a Slack post.
Attendance and chat recap: A documented Livestorm attendance event or final attendance state is stored separately from registration. Chat messages remain message-level inputs where auditability matters. Deterministic logic counts attendance, while AI clusters supplied messages into themes. The recap is stored as a versioned session-level record and held for review when attendance counts, source IDs, or input completeness do not pass validation.
Measure lasting capability and business impact
Keep three measurement levels separate. Define the population, time period, and inclusion rules before comparing results.
- Employee capability: Count unique employees who published or materially edited a production workflow in a defined period. Exclude people who only attended training or tested a draft.
- Workflow activity: Count workflows with successful production runs in that period. Do not count a workflow merely because it exists.
- Process outcome: For onboarding recaps, measure preparation time, time from session end to approved recap, correction rate, or the percentage of recaps requiring manual reconstruction. These are proposed measures, not reported Jobber results.
This distinction matters because capability spread and workflow volume are not the same thing. A company can add workflows without giving more employees the ability to identify, build, govern, and maintain useful automations. Conversely, more builders matter only when their work improves a defined process.
Start with one owner-led process. Record the current steps and baseline, pilot with a small group, inspect failures and exceptions, and expand only when the workflow can be supported. If adoption rises but preparation time or quality does not improve, investigate the process design instead of treating more workflows as proof of value.
- A process owner and an exception owner are named.
- Each record has a defined grain and stable identifier.
- The system of record, access rules, and necessary fields are documented.
- Each AI step has a bounded task, output contract, and validation rule.
- A review route exists for missing, inconsistent, sensitive, or unsupported output.
- A baseline and at least one process outcome measure are recorded.
Jobber’s reported story is useful because it connects employee enablement with real workflow building. The practical operating model is straightforward: make useful work discoverable, teach people by building against that work, and give every production workflow an owner, a support path, a data model, and a measurable purpose.