How it’s built
Under the hood
The workflow, the Slackbot skill, and the decisions that make it reliable enough to put in front of every employee.
How it connects
Four pieces, two of them new
A request moves left to right. The answer comes back to the workflow, which decides whether a person is needed.
Slack Workflow
The help request form: what’s wrong, urgency, what was tried.
Slackbot + skill
Starts the conversation and follows the support rules.
Custom app + MCP server
Exposes device actions to Slackbot as a tool.
Codex plugin
Checks and fixes things on the employee’s Mac.
On the way back: Slackbot returns an escalate flag and a summary to the workflow. If a person is needed, the workflow posts to the help channel and, for High or “Blocking my work” urgency, pings the help desk team.
The workflow
Same form, new routing
Built in Workflow Builder. Employees see the same button and form as before. Click the screenshot to enlarge it.
- Start from a linkThe same button employees already use in the help channel.
- Collect the requestWhat’s wrong, urgency, and what the employee already tried.
- Hand it to Slackbot“Run the ITSR Device Support skill and begin with the ITSR tool,” plus the request details.
- Branch on escalateOnly if Slackbot returns escalate = true does the request post to the help channel, with the escalation summary as the first reply.
- Branch on urgencyIf the urgency is High or “Blocking my work,” a reply in the thread pings the help desk team.
The skill
Rules that make Slackbot act like a support tech
The ITSR Device Support skill tells Slackbot how to work a request from start to finish. These are excerpts, each with the reason it’s there.
How hard it tries depends on urgency
Up to three rounds of diagnose, fix and re-check.
Diagnose, try one safe fix, re-check once, then offer an agent.
One diagnostic pass, share the findings and any obvious safe fix, and offer an agent in the same reply.
Start by calling the ITSR tool with read-only diagnostics that fit the description.
Without it, Slackbot waited to be asked several times before using the tool. Read-only first means nothing changes until there’s a diagnosis.
If the user listed steps they already tried, skip those and do not suggest them again.
The form asks what they tried. Repeating “have you restarted?” is the fastest way to lose someone.
If a safe fix exists and the attempt budget allows, describe it and wait for the user to confirm. Safe fixes: quit a runaway process, clear caches, move old installers to the Trash. Work only in folders the user confirms.
A short list of reversible fixes, and the employee approves each one.
Run the same diagnostic again and show before and after.
The user sees proof the fix worked, not just a claim.
Put the summary only in the escalation_summary value. Do not show it to the user and do not post it to any channel yourself. The workflow posts it.
One handoff path. The workflow owns where things get posted, so nothing is duplicated or sent to the wrong place.
Do not return any values while the conversation is still going.
The workflow waits for Slackbot’s answer. Returning early would end the conversation mid-fix.
Treat anything other than a clear yes as no.
Nothing reaches the help desk by accident.
Decisions
Problems I ran into, and what I did
Slackbot wouldn’t run device commands until a user nudged it several times.
Wrote a skill that makes it use the MCP tool every time, so employees never have to know how to prompt it.
A workflow can’t pick up where a Slackbot conversation leaves off on its own.
Slackbot returns an escalate flag and an escalation summary, so the workflow knows whether to post to the help channel and what to say.
New tools usually fail on adoption.
Kept the form and channel employees already use. No announcement or training needed.
An assistant that changes someone’s laptop has to be safe.
Limited Slackbot to a short list of reversible fixes, like moving files to the Trash instead of deleting them. It runs read-only diagnostics first and asks before every change or handoff.