The plain answer
What ISM Services actually does.
ISM works where Archibus gets difficult: implementation, support, data, integrations, environments, and tools built after the same problems come back.
ISM Services implements, supports, and extends Archibus and facilities management software. The work covers enterprise operations, customization, data, integrations, and the tools around them.
That isn't much of a startup pitch. It is a better description of the job. Customers rarely arrive with one clean feature request. They have a real building portfolio, old process decisions, reporting habits, security requirements, database history, upgrade risk, and people who need the system working after the project call ends.
ISM's public site says the company sells, implements, develops, and sustains Integrated Workplace Management System software. It names Archibus implementation, software design, support, troubleshooting, and training. In practice, ISM helps teams fit Archibus and the surrounding facilities management software to the way their organization operates.
Archibus comes with history.
Archibus carries a lot of operational history. The database, workflow, permissions, drawings, requests, assets, leases, and reporting habits all matter. A small change in one area can affect how another team handles space, maintenance, assets, moves, keys, chargebacks, or compliance.
Experience with the strange parts saves time. Writing code isn't enough. An Archibus team has to know why a field exists, who relies on it, which reports break if it changes, what an integration expects, and what the upgrade path will tolerate.
Much of the job is translation. Facilities teams explain how work happens. Technical teams explain what the system can safely support. The software has to hold those answers without turning into a pile of exceptions.
Writing the customization is only the start. The harder question is whether it will still make sense after the first urgent support ticket.
The same work keeps coming back.
Implementation sets up the system around the organization instead of forcing the organization into someone else's defaults. Configuration, personalization, workflow, reporting, naming, and process choices all affect whether people trust it.
Facilities software exchanges data with finance, identity, and HR systems. It also has to work with drawing tools, GIS, reporting tools, and other systems of record. The code matters. Someone still has to decide which source is authoritative, what can be derived, and where bad data stops.
People underestimate sustainment. Support, troubleshooting, upgrades, training, environment repair, QA, and operational evidence determine whether an implementation stays useful after its first release.
Tooling starts after a support pattern or setup problem repeats enough times. You can keep paying the manual tax. I would rather build something that makes the next round less fragile. Much of my current work starts there: easier environment creation, repeatable developer and consultant workflows, clearer usage and support, and less work trapped in one person's memory.
Where ArchiBot fits.
ArchiBot came from doing this work over and over.
"Add AI to facilities management software" is too broad to be useful. Archibus work depends on schema knowledge, view behavior, upgrade history, customer-specific workflows, support habits, environment details, and code patterns that are hard to keep in one person's head.
An assistant that ignores that context is noise. It becomes useful when it helps a consultant understand a view, inspect a pattern, reason about an upgrade, review a customization, or work inside a repeatable environment.
The AI has to stay attached to the way the work runs. That puts it near the repository, environment, logs, data boundaries, support process, and the person responsible for the outcome.
Start closer to the problem.
If you work in or around Archibus, ISM will probably recognize the weird parts faster than a general software team. Answers still take work. The first conversation just starts closer to the problem.
ISM already handles Archibus implementation, support, sustainment, training, and integrations. That work has left enough domain scar tissue to know where projects usually get stuck. The newer product work includes hosted workspaces, repeatable delivery environments, usage visibility, and ArchiBot. ArchiBot carries more of that operating knowledge into the work itself.
ArchiBot is one attempt to stop carrying all that context by hand. It comes from the same work ISM does to run, support, and keep improving Archibus and facilities management software.
ArchiBot is being tested against real implementation, upgrade, support, and consultant workflows. If you work with Archibus and want to pressure-test it against work you actually do, reach out.
If ArchiBot doesn't make this work less fragile, it doesn't matter.