Allen HouchinsandMike Thomas
7f07651f97
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** N/A # Checklist for submitter This PR adds one markdown file under `articles/` (a customer case study) — no product code, so most of the template below doesn't apply. ## What changed Adds `articles/hawx.md`, a case study on Hawx Pest Control. **The story:** Hawx is a technology-first pest control company whose field technicians can't be dispatched without a provisioned phone. Hiring ramps up hard every summer, so onboarding and offboarding run constantly. With Jamf, phones sat on the MDM screen until the technician logged in, nobody remembered their credentials, and the helpdesk got flooded from personal phones every season. Identifying which device belonged to which technician took 5 to 10 minutes per call, 5 to 10 calls a day. Hawx now drives Fleet entirely through the API, paired with Tines and Okta, so a device lands in the right fleet with the correct profiles, policies, and apps the moment the technician verifies their identity. Offboarding wipes or locks based on role. Migration took a month. **Source:** the 2026-07-20 customer interview with Loren Farr, IT Manager at Hawx. Loren confirmed on the call that Fleet may use the company name and his name and title, and was told nothing publishes without his approval. **Format:** drafted against the proposed `fleet-case-study-formatting` skill in #49917 and the `content-style` skill: - Three-act narrative (the challenge → why Fleet → the solution → the results), headings in sentence case. - Four `attribution-quote` divs spaced through the narrative rather than clustered. - A `checklist` div for the headline results. - Full endmatter including the build-enforced `summaryChallenge` / `summarySolution` / `summaryKeyResults` (semicolon-separated) plus the company and hero-quote tags. - "About Hawx" lives in `companyInfo` / `companyInfoLineTwo` rather than the body, matching every published case study. ## Why Hawx is a strong story in a segment Fleet's published case studies don't yet cover: iOS-only, a small IT team (3 people, ~500 devices), a seasonal workforce, and an API-only usage pattern where the customer never touches the Fleet UI. It's also a clean Jamf migration narrative with a quantified helpdesk result. ## ⚠️ Blockers before this can be published This is a **draft PR on purpose**. Two items must be resolved first: 1. **The quotes are not verbatim yet.** The interview record is bullet notes, not a transcript, so the four quotes are faithful reconstructions of what Loren described, not transcribed speech. The case-study skill's rule is that quotes are verbatim and never reconstructed. **Loren needs to approve these as his words before merge.** Reviewers should not treat them as citable until he has. 2. **Both image assets are missing.** There is no Hawx logo and no Loren Farr headshot in `website/assets/images/`. `companyLogoFilename` and `quoteAuthorImageFilename` are deliberately stubbed with `TODO-` prefixes so the website build fails loudly rather than shipping broken image references. Real files are needed following the `{descriptor}-{css-width}x{css-height}@2x.{ext}` convention. ## Open questions for reviewers - **The "more than 90%" figure was dropped.** An earlier draft said credentials were forgotten in more than 90% of cases. That number isn't in the interview notes (the notes say "nobody knew their username or password"), so it's omitted. If Loren sourced it, it can go back in. - **The warehoused-device problem is omitted.** The notes describe devices offline more than 30 days needing a reset, currently a 30-minute call, listed as a *current* problem. That would fit a "Looking ahead" section if Fleet is the plan for it, but it doesn't belong in results as an achieved outcome. - **Hero quote choice.** `quoteContent` uses the "slam dunk ... control over the phone itself" quote because it names the differentiator. Loren's closer, "As long as you're not shy about getting into the code, this is a fantastic platform," is arguably the more trustworthy line for Fleet's audience. Easy swap if marketing prefers it. - **Follow-up, not in this PR:** the pull quote could be added to `handbook/company/testimonials.yml` for the `/customers` carousel. Left alone since that file is curated by marketing. - [ ] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. — N/A, website content only, not a product change ## Testing - [ ] Added/updated automated tests — N/A, markdown content only - [x] QA'd manually: cross-checked the structure, custom div syntax, and required meta tags against the published case studies (`articles/fastly.md`, `articles/primo.md`) and against the validation logic in `website/scripts/build-static-content.js`; confirmed `summaryKeyResults` is semicolon-separated; confirmed `articleTitle` matches the H1 exactly; grepped `website/assets/images/` and confirmed both referenced image files are absent (hence the `TODO-` stubs). --------- Co-authored-by: Mike Thomas <78363703+mike-j-thomas@users.noreply.github.com>
7.5 KiB
How Hawx gets field technicians productive on hour one with Fleet
The challenge
For Hawx, a technology-first pest control company, a field technician's phone isn't an accessory. It's how the job gets done. A technician who can't get their device provisioned can't be dispatched, log a service, or generate billable work. So when device onboarding stalls, it isn't an IT inconvenience, it's lost service capacity.
That made Hawx's seasonality the crux of the problem. Hiring ramps up hard in the warm months, bringing in droves of contract technicians, then slows in winter, which means a constant roller coaster of device onboarding and offboarding. With Jamf, these workflows hit a wall.
The MDM screen held up every new technician during onboarding. You couldn't do anything with the phone until the person receiving it logged in, and nobody knew their username or password. We'd get calls from their personal phones blowing up the helpdesk. At the start of the summer season, all we did was troubleshoot phones.
The friction wasn't limited to onboarding. Even routine support calls were slow, because simply identifying who was holding a given device was difficult. In Jamf, associating users with devices meant CSV uploads and manual matching.
With a renewal on the horizon, the team had a reason to look for something better.
When a field technician calls in, they previously had to read off their phone number or dig the serial number out of settings. Often, we had to walk them through where to find their serial number in settings. That's five or ten minutes a call, determining which device and user we're working with before even starting to troubleshoot their issue, and we take five to ten of those a day all season long. With Fleet, all we need is their name.
Why Fleet
Hawx evaluated two other vendors alongside Fleet. Fleet's open-source code base and managed cloud option were influential, but they weren't the deciding factors.
The slam dunk for us was that Fleet gave us control over the phone itself. We can run the device the way we want. Nobody else we looked at could offer that.
That control, paired with reliable end-user association, was what made it possible to automate the seasonal enrollment and offboarding that had been the team's biggest time commitment. There was no waiting on a vendor to build a trigger Hawx needed. Pairing Fleet with the automation platform Tines, Hawx tailors onboarding to each individual field technician or corporate employee, then leans on its identity provider to do the rest. Hawx drives all of it through Fleet's API rather than the Fleet UI.
The solution
Onboarding that runs itself. The old process required an IT admin to log in to the console, find the device, associate the correct user, and manually move it into the right group. The new flow is hands-off. A device automatically drops into a default fleet. Once the technician follows the instructions in their welcome email and connects through Okta, Hawx pulls their user association and Fleet handles the rest. When the device moves into the appropriate fleet, it receives the required profiles and policies, and Fleet installs the apps. No console babysitting required.
Offboarding without the scramble. The exit path is just as automated. When a termination notice comes through, Fleet and Tines locate the phone and act on it with logic tuned to the device owner's role.
When a termination notice comes through, Fleet and Tines go find that phone and wipe it. It stays associated with the user and in its fleet until we assign someone new. For senior roles like a GM, we lock it instead of wiping it just in case we need to retrieve anything from that device.
The results
The migration took about a month. The payoff showed up immediately where it had hurt most: start-of-season onboarding support requests are gone.
The everyday support math improved too. The five to ten minutes once lost to identifying a caller's device before troubleshooting could even begin, across five to ten calls a day, is now down to seconds.
With Fleet, Hawx has:
New technicians productive from hour one during peak hiring season
Onboarding and offboarding that run automatically, wiping or locking devices based on role
Up to ten minutes saved on every support call, with device and user identification down to seconds
A full migration off Jamf completed in one month
For Loren, success is measured in silence.
The way we know Fleet is working well and that we made the right choice is that leadership isn't hearing from branch general managers that technology is a blocker to technician onboarding. No news is good news, and that's the peace Fleet brings me.
The worry that used to define the start of every season, technician onboarding and offboarding, simply isn't a worry anymore.