What ISM Services actually does.

ISM Services is an Archibus and facilities management software company. The company lives in a specific lane: enterprise operations, implementation work, support, customization, data, integrations, and the tooling around all of that.

That sounds less flashy than a normal startup pitch. It is also closer to the truth. The work is usually not one clean feature request. It is a customer with a real building portfolio, old process decisions, reporting habits, security requirements, database history, upgrade risk, and people who need the system to keep working after the project call ends.

ISM's public site describes the company around sales, implementation, development, and sustainment of Integrated Workplace Management System software. It also points directly at Archibus implementation, software design services, support, troubleshooting, and training. That is the official version. The practical version is simpler: ISM helps teams make Archibus and the surrounding facilities-management stack fit the way their organization actually operates.

Archibus work is high-context.

Archibus comes with real operational history. The database, workflow, permissions, drawings, requests, assets, leases, and reporting habits are part of the product. A small change in one area can affect how another team handles space, maintenance, assets, moves, keys, chargebacks, or compliance.

That is why this work rewards people who have seen the strange parts before. A generic team can write code. A useful Archibus team has to understand why the field exists, who relies on it, which reports break if it changes, what the integration expects, and what the upgrade path will tolerate.

A lot of the job is translation. Facilities teams explain how work happens. Technical teams explain what the system can safely support. Somewhere in the middle, the software has to become a reliable operating surface instead of a pile of exceptions.

The value is not just knowing how to customize the system. It is knowing which customization will still make sense after the first urgent support ticket.

The same work keeps coming back.

Implementation is the obvious part: setting up the system so it reflects the organization instead of forcing the organization to speak in someone else's defaults. That includes configuration, personalization, workflow, reporting, and all the small naming and process decisions that determine whether people trust the system.

Integration is where the shape of the organization shows up. Facilities software has to exchange data with finance systems, identity systems, HR systems, drawing tools, GIS, reporting tools, and whatever else already became a system of record before the project started. The technical part matters, but the real work is deciding what should be authoritative, what can be derived, and where bad data is allowed to stop.

Sustainment is the part people underestimate. Support, troubleshooting, upgrades, training, environment repair, QA, and operational evidence decide whether an implementation stays useful after the first release.

Tooling is what happens after the same support pattern or setup problem repeats enough times. You either keep paying the tax manually or you build something that makes the next round less fragile. A lot of my current work sits there: making environments easier to create, making developer and consultant workflows more repeatable, making usage and support easier to reason about, and reducing the amount of work that depends on one person's memory.

Where Archibot fits.

Archibot comes from that operating reality. It is the product version of lessons ISM kept relearning in the field.

The useful question is narrower than "add AI to facilities management software." Archibus work carries a lot of context: 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.

If an assistant cannot respect that context, it is noise. If it can help a consultant understand a view, inspect a pattern, reason about an upgrade, review a customization, or work inside a repeatable environment, then it starts to matter.

That is the line I care about. The AI work only matters because it is attached to the actual operating model. It has to live near the work: the repository, the environment, the logs, the data boundaries, the support process, and the person responsible for the outcome.

The soft pitch.

If you work in or around Archibus, ISM probably understands the weird parts faster than a generic software team will. That does not mean every answer is instant. It means the first conversation starts closer to the real problem.

ISM has the established service side: Archibus implementation, support, sustainment, training, integrations, and enough domain scar tissue to know where projects usually get stuck. It also has the newer product direction: hosted workspaces, repeatable delivery environments, usage visibility, and Archibot as a way to carry more of that operating knowledge into the work itself.

That is what ISM Services does in plain language. It helps organizations make facilities management software usable, supportable, and worth continuing to improve. Archibot is growing out of that same work for a practical reason: the old way of carrying all this context by hand does not scale very well.

Archibot's public beta is releasing soon. If you work with Archibus and want to try it early, reach out. I am especially interested in people who can test it against real implementation, upgrade, support, or consultant workflows instead of a generic demo script.

The product only matters if it makes the real work less fragile.