Twenty Tickets a Day

Quick note before we start: this is a knife blog, and once again this post has nothing to do with knives.

Last time we explained the AI data center shakeout with kitchens. This time we zoom in on one person in that kitchen crew: the project manager, and the pile of tickets on their desk.

Step 1: What a PM actually does

Every data center job has three people in it. Here they are, in their own words.

Step 2: How a ticket travels today

Here's the twist that makes this interesting: there are two ticket systems.

• The customer uses ServiceNow. It's big, expensive, and it belongs to them.
• The staffing company uses Freshservice. It's cheaper, and it belongs to them.

And the bridge between those two systems? That's our contractor (not contractor, totally a W2 guy). He picks up the ticket in the customer's ServiceNow and uploads it into Freshservice by hand.

Then the PM takes it from there. For every ticket, the PM roughly does this:

1. Read it. What's broken, where, how urgent, how long until the deadline (the "SLA")?
2. Fix the missing stuff. Half the tickets are missing a rack number, a serial number or an access window. Go ask.
3. Get the alert. A tech grabbed the ticket. Now it's the PM's. Who is it, and are they the right fit for this job?
4. Write the dispatch. Site, cage, rack, what to do, what to bring, what photos to take.
5. Chase. "Are you on site?" "What's your ETA?" "Did you get badged in?"
6. Update the customer. In both systems. Again.
7. Remote in when something goes sideways.
8. Check the work. Are the photos right? Does the serial number match?
9. Close it. Write the close note, mark it done, in both systems.

Multiply that by 20 and you get this:

Step 3: Which parts can a robot do?

Look at that list again. Only one step, remoting in when something breaks, actually needs a skilled human brain on the problem. Most of the rest is reading, sorting, writing, chasing and checking. That's exactly the kind of work AI agents are good at.

So the PM's job changes from doing every step to approving most steps and handling the weird ones.

The PM stops being a copy-paste machine and becomes the person who says "yep" or "wait, no."

If approving a ticket takes 5 minutes instead of 25, the same PM handles 50 or 60 a day instead of 20. And once the most routine ticket types (say, drive swaps at a site you visit every week) prove themselves, those can skip the approval step entirely.

Step 4: The sandbox (how to keep customer secrets secret)

This is the part security people care about, and they're right to. A data center ticket can have door codes, rack locations, IP addresses and the names of very big companies on it. Here's how to set up the robots so nothing leaks.

1. One playpen per customer. Each customer gets its own separate space for the AI: its own memory, its own logs, its own settings. Freshservice has a feature built for exactly this, called workspaces, which keeps each workspace's data separate. Customer A's door code can never wander into Customer B's ticket because the robot working for Customer B has never seen it.

2. The robot never holds the keys. The AI doesn't get a password to anything. It can only ask for a short list of actions: "read this ticket," "write this note," "text this tech." Every request goes through a gatekeeper (a small program the staffing company owns) that holds the real passwords, checks the request against the rules, and writes it down.

3. Hide the secrets before the robot sees them. The gatekeeper swaps door codes, passwords and IP addresses for placeholders like [DOOR CODE 1]. The robot writes "Use [DOOR CODE 1] at the cage." The gatekeeper puts the real code back in only at the very end, in the text to the tech.

4. Techs see only their own job. Our contractor (not contractor, totally a W2 guy) gets the site, rack, task and time window. Not the whole ticket history, and not anybody else's tickets.

5. Business-grade AI only. Use an AI service under a business contract that keeps no copy of your data and doesn't train on it. Claude through Anthropic's business API works, or through Amazon's or Google's cloud, so the data stays inside the staffing company's own account. Never paste tickets into a free chat app.

6. Write everything down. Every read, every draft, every approval, who approved it, and when. When a customer's security team asks "what did your AI do with our data?", you hand them the log.

7. An off switch. One button turns the robots off for a customer, instantly. You'll probably never need it. You'll sleep better knowing it's there.

Step 5: What API access would it take?

An API is just a door that lets one program talk to another. To make all of this work, you need the right doors open on both systems.

Freshservice (the staffing company's side): mostly ready

Good news: this is the staffing company's own system, so nobody has to ask permission.

• The API exists. Freshservice has a full API for reading and updating tickets, notes and attachments (photos).
• Make a robot account. A Freshservice API key acts exactly like the person who made it, with no way to narrow it down. So don't use the PM's key. Make a separate "integration" account with a custom role that can only see one customer's workspace, and give each customer's robot its own account.
• Turn on instant alerts. Freshservice's Workflow Automator can "trigger a webhook," which means pinging the robot the moment a ticket comes in or changes, instead of the robot checking every minute.
• Watch the speed limit. Freshservice caps how many API calls you can make per minute, and the cap depends on your plan (third-party guides list about 100 a minute on the cheapest plan, up to about 500 on the top one). Fine for hundreds of tickets a day, but worth checking.
• Or use the built-in AI. Freshworks launched its own "Freddy AI Agent Studio" for Freshservice in 2026. Worth a demo, but a custom setup gives you tighter control over the playpens and the gatekeeper.

ServiceNow (the customer's side): this is the hard part

This system belongs to the customer, so the staffing company only gets what the customer allows. There are three ways to connect it, easiest first:

Start with email, because it needs nobody's permission. Ask the biggest customers for option 3 once the pilot has numbers to show.

The other doors you'll need

• A real tech roster. Skills, certifications and track record. If this lives in a spreadsheet today, it needs to live in a real database the robot can check when a tech grabs a ticket.
• A texting service (like Twilio) so the robot can send dispatches and collect ETAs.
• A checklist for each ticket type. What steps, what tools, what photos prove the job is done. This is the secret sauce. The robot is only as good as the checklist.
• The gatekeeper and the log from Step 4.

Step 6: How to start without breaking anything

1. Weeks 1–2, watch only. One customer, one PM. The robot drafts everything but sends nothing. The PM works normally. Compare: would the robot's drafts have been right?
2. Weeks 3–6, tap to approve. The PM approves each draft with one tap. Track tickets per PM per day, missed deadlines, and redo work.
3. After that, let the boring ones fly. The two or three most routine ticket types go out on their own. A human still approves anything strange and every close-out.

The whole thing in four sentences

A data center PM spends most of the day copying, chasing and checking, not fixing. AI agents can draft almost all of that, leaving the PM to approve and to handle the weird stuff, which could take one PM from 20 tickets a day to 50 or more. Keep it safe with one locked playpen per customer, a gatekeeper that holds every key and hides every secret, and a log of everything. Freshservice is ready to go today, and the customer's ServiceNow can start with plain email and graduate to a full link later.

And our contractor (not contractor, totally a W2 guy) never has to copy and paste a ticket again.

The to-do list (how we'd tackle it)

1. Get API access. In Freshservice, make one robot account per customer workspace. With each customer, start with email, then ask for a webhook, and later a full vendor account.
2. Build the ticket bridge. Tickets flow from the customer's ServiceNow into Freshservice, and updates flow back, automatically. The contractor (not contractor, totally a W2 guy) stops copy-pasting.
3. Lock down the data. Read each customer's contract. Sign up for business-grade AI that keeps no copy of your data.
4. Build the sandbox. One playpen per customer, the gatekeeper that holds the keys, the secret-hiding, the log and the off switch.
5. Write the checklists. One per ticket type: steps, tools, and which photos prove it's done.
6. Coordinate the AI agents. Give each one a single job: sort new tickets, check the tech who grabbed it, write the dispatch, chase ETAs, check the close-out photos. One "lead" agent per customer passes the ticket down the line and pings the PM only when a human is needed.
7. Hook up the extras. The tech roster in a real database, and a texting service for dispatches and check-ins.
8. Run the pilot. One customer, one PM. Two weeks watch-only, then four weeks tap-to-approve.
9. Measure and grow. Tickets per PM per day, missed deadlines, redo work. Let the boring ticket types run on their own, then add the next customer.