Stories from the field.
Not from marketing.

When we first walked into their main plant, the IT director pulled up a spreadsheet. Not a dashboard — a spreadsheet. 14,000 assets across three factories, and maintenance was "whatever the shift supervisor remembers to check." They were losing about $380,000 a month in unplanned downtime. The worst part? They knew it — they just didn't think ServiceNow could handle the complexity of their manufacturing environment.

We spent the first week just watching — sitting with maintenance crews, shadowing shift changes, understanding what actually happens vs what the process documents said. Then we built an Asset Management module that pulled real-time data from their PLCs through Integration Hub. The key decision: we didn't try to model every asset. We focused on the 20% of equipment that caused 80% of the downtime. Four weeks to configure, two weeks of testing with actual operators, two weeks of parallel run, then cutover.

This one was interesting. The bank wasn't failing — their IT team was actually pretty good for their size. But they were drowning in L1 tickets. Password resets, access requests, "my printer isn't working." Their three service desk agents handled about 180 tickets a day, and the average response time was creeping toward 6 hours because the volume kept growing as they added branches. They needed to deflect the simple stuff without spending a fortune on a complex ITSM deployment.

We built a ServiceNow ITSM instance but started with the employee portal and Virtual Agent — not the back end. Configured about 40 common requests as self-service catalog items with automated fulfillment (password resets, software installs, access provisioning). The Virtual Agent we trained on their actual ticket history — about 9,000 past tickets — so it could recognise the patterns their employees actually used, not just the ones IT wished they used.

Hospitals are complicated in ways manufacturing plants aren't. You can't just "shut down a line" to test something. This network had eight facilities, each with its own way of managing patient intake, bed allocation, and discharge workflows. The result: patients spent an average of 4.7 extra hours waiting because departments couldn't see each other's status. The CMO described it as "we know where the patient is, we just don't know who's ready for them."

Patient flow isn't a traditional ServiceNow use case, so we built it on App Engine with custom tables for bed status, department readiness, and patient transport. Connected it to their EHR through Integration Hub for read-only patient data (no PHI movement — compliance was non-negotiable). The dashboard showed every department a real-time view of patient status across the network. We built it iteratively — one facility at a time, four weeks each, starting with the one with the best data quality.

Field service was the bottleneck. 340 technicians handling about 2,800 work orders a week, all dispatched by a team of 12 people using — I wish I was joking — a whiteboard and phone calls. Average time from fault report to technician arrival: 8.4 hours. When we asked the dispatch manager what the ideal workflow looked like, he laughed and said "anything where I don't have to call someone."

FSM deployment with automated dispatching based on technician proximity, skills, and current workload. The integration with their existing workforce management system was the trickiest part — their API documentation was four years out of date. We ended up building a lightweight middleware connector that normalised the data before it hit ServiceNow. The dispatch team went from 12 people doing manual routing to 2 people handling exceptions the AI couldn't resolve.