The demonstration works. A ticket appears in the second system, its status comes back, and the buying team can see the connection. Before signing off, ask a different question: who will own this service when it stops working on an ordinary Tuesday?
Managed integration should have an answer that extends beyond the software licence. The buyer needs clarity about monitoring, investigation, recovery, changes and communication. A connector can move information successfully while responsibility for an incomplete business process remains unclear.
This guide is for organisations buying ITSM integration across internal teams and external providers. Use it to turn a promising technical demonstration into an operating agreement. It is a buyer’s checklist, not a proposed contract or a promise of a particular provider’s response times.
Describe the service before comparing suppliers
Write one representative journey in business terms. For example: a customer reports an issue to the service desk; engineering receives the necessary information; the service desk receives an appropriate resolution update; the customer’s issue is closed after the agreed confirmation.
Then identify the systems, fields and people involved. A service that includes internal notes, attachments and status transitions is different from one that only creates a new ticket. The same is true when the integration must serve multiple legal entities, languages or support arrangements.
Check whether an existing native connector meets that defined need before buying another layer. Xurrent, for example, publishes a catalogue of standard integrations. The existence of a catalogue entry is a reason to investigate fit; it is not proof that every business rule, permission boundary and operating responsibility is covered.
Make ownership visible in a table
Ask the supplier and your internal owners to complete an ownership table together. A column labelled “shared” is useful only if it also says who acts first and how the handoff works. You should not have to coordinate three support queues to discover who will acknowledge an incident.
| Operating question | What a useful answer includes |
|---|---|
| Who detects a missed update? | The monitored condition, coverage window and first responding team |
| Who investigates? | Access to relevant evidence and responsibility for working across suppliers |
| Who approves recovery? | Permitted routine actions and the owner of higher-impact decisions |
| Who communicates? | A customer contact route, update expectations and escalation path |
| Who maintains the integration? | Named responsibility for API, field, permission and configuration changes |
| Who owns the records and configuration? | Access, export, retention and handover arrangements |
Test the table with a scenario in which both connected applications appear healthy but an expected update is missing. That condition exposes the gap between infrastructure monitoring and monitoring the integration’s actual job.
Ask how recovery will work
Request an example of a failed update being investigated and repaired in a test environment. The supplier should be able to identify the original request, explain what has already changed and describe how another attempt avoids unwanted duplication.
Ask what happens when the problem cannot be repaired automatically. A clearly owned exception is more useful than a hidden retry that continues indefinitely. Clarify how the team handles conflicting edits, deleted records and a request that is no longer valid by the time the destination recovers.
The bidirectional ticket integration test matrix offers concrete acceptance cases. Keep failed and untested cases visible in the handover. They are operating obligations to resolve, not presentation details to remove before launch.
Understand the change boundary
Every integration exists inside changing systems. A team may rename a field, introduce a new status, replace an approval group or change an API permission. Ask which changes are included in routine maintenance, which require a separate request and how either route is approved.
Use a realistic example: your service desk adds a mandatory cost centre to new requests. Who checks the impact, updates the mapping, tests existing records and coordinates the release? If the answer is a new project, understand its commercial and scheduling implications before the service depends on that field.
Clarify ownership of integration identities and credentials. The agreement should identify who grants access, who rotates credentials and how continuity is maintained when an employee or supplier contact leaves. Avoid an operating model that relies on one consultant’s personal account.
Compare commercial scope with operational scope
A monthly price is only comparable when its inclusions are clear. Ask how charges relate to environments, flows, support coverage, changes and usage, using the supplier’s actual commercial model. Do not assume that a fixed platform licence includes unlimited engineering or that every incident caused by another application is excluded from coordination.
Autom Mate’s public onITnow case study describes Managed Integration as a Service as part of the provider’s customer offering, including work across ITSM and business applications. It also explains why cost predictability matters to that model. This is an example of service ownership around integration; it does not establish the price, scope or service level available to another buyer.
Plan a usable exit from the beginning
Ask what you receive if the service changes provider or returns in-house. A diagram without field mappings, account ownership and recovery instructions may be insufficient. Agree how configuration, request relationships, outstanding incidents and relevant documentation will be handed over.
Include the order of transition. The outgoing integration should not keep processing events after its replacement starts unless that overlap has been deliberately designed and tested. Equally, removing access before outstanding work is reconciled can leave records stranded between systems.
Use the service integration evaluation guide to compare options on this full lifecycle. If you are exploring an Autom Mate Enterprise integration, bring one service journey, the systems involved and your ownership questions. A useful proposal should explain how the service will be operated after the demonstration ends.
