The boundaries are the work

In a shared ServiceNow project, most problems happen at the seams: where one firm’s configuration becomes the other’s input, where two sets of requirements overlap, where a defect could belong to either side. We spend a good share of early effort on those seams. Before build begins, we agree:

• Scope ownership. Which firm owns each workstream, such as service management processes, portal, CMDB, integrations or reporting, and what is explicitly outside it.
• Hand-off criteria. What “ready” means when work passes between teams, including documentation and test evidence.
• Decision rights. Who decides what, and how disagreements are escalated.
• Change handling. How a change request is assessed and approved when it touches both parties’ work.

Adding AI to a ServiceNow workflow

A growing number of ServiceNow engagements include an AI element, for example assisting with ticket classification, summarising case history or helping agents find the right knowledge article. These features touch data, process and platform at once, so they are well suited to co-delivery. We typically take the AI part: choosing the use case, checking the data behind it, deciding what a human must review and setting up evaluation. The partner keeps the ServiceNow configuration. We agree in advance who is accountable if an AI suggestion is wrong.

One voice to the customer

Customers should not have to work out which firm to ask. We agree in advance who speaks for the project on each topic and how joint updates are prepared.

Shared visibility and disagreement

Both firms work from the same plan and the same status view. We keep a simple decision log so any agreement can be found later. Disagreements are handled through a written escalation path with time limits at each step, so nothing quietly stalls the project.

After go-live

We agree who supports which components afterwards, how issues are triaged between the firms and how knowledge is documented so the customer’s team can operate the result.