Choosing a software partner for AI in operations
The questions an operator should ask a software partner before putting AI into daily operations, the answers that count, and how to run the first process.
A partner for AI in operations will work on your orders, your billing and the answers your customers get. You learn how that partner works by asking specific questions and checking each answer against something you can see: their own daily work, systems running at other operators, a real case from your queue. This article lists those questions, the answers that count, and how to run the first process together once you have decided.
The choice carries weight. In MIT NANDA’s 2025 research, based on interviews with 52 organisations, external partnerships with customised tools reached deployment about 67% of the time, compared with about 33% for internally built tools (MIT NANDA, 2025). The authors point out that the figures are self-reported and that the gap may reflect the organisations as much as the approach. They also describe the buyers who got results as the ones who held vendors accountable to business metrics. Take that stance into the first meeting.
Does your implementation team use AI every day?
Put this question to the engineers and project leads who will be assigned to your project. Ask them to show, on screen, a piece of their own work from the past week: how an engineer had an agent draft a change and how it was reviewed before it was merged, how a support colleague used an assistant to analyse a ticket, how they test an agent’s output before a release.
Ask which accounts they use. A team that works with AI daily has decided which tools and which data are allowed, uses company accounts, and can tell you what happens to your data when someone pastes a log file into an assistant. A vague answer here means your customer data may end up in a personal account during the project.
The answers that count:
- a recent, concrete example with the review step visible
- a clear rule for customer data, with the tools and accounts it applies to
- something they tried and stopped using, and the reason
Which solutions run productively at other operators?
Productive means running on live customer data, every day, beyond the pilot, with a named person responsible. Ask for the process, the start date, what the agent may read and write, and who checks its results. Ask what was switched off again and why. A partner who has run agents in production for some time will have such a case and will tell you about it.
Look for operators that resemble you: a similar number of subscribers, the same kind of wholesale access, similar products such as fibre with partner add-ons. A use case at a mobile operator with its own network tells you little about relocations on a third-party fibre network.
Which improvements can you measure?
Ask for before and after figures on measures operators already track: how long an order waits between steps, how often customers have to ask again about the same case, how many cases need manual correction, how many invoices are corrected after they went out. Then ask how each figure was measured, over which period and on how many cases. Timestamps from the order system and the ticketing tool hold up in that conversation; ask for them.
Ask what got worse, too. When an agent takes over the first check of an order, the work around it changes. Support staff see fewer simple cases and more difficult ones, and the average time per case can go up. A partner who measured carefully will know this and can explain it.
What does a reference customer say about errors, support and development?
Arrange a call with a reference customer, ideally without the partner on the line, and cover three topics.
On errors, ask about the last time an agent produced a wrong result. How was it noticed, by whom, how long did the fix take, and what changed afterwards? A reference who cannot name a single incident has either just started or is being polite.
On support, ask what happens on a Saturday morning when activations fail: who answers, how quickly, and who decides whether to stop the agent.
On development, ask which of their requests the partner has built since the start, how updates are announced and tested, and whether an update has ever broken a running process.
Walk one real customer case together
Take a real case from your own queue, anonymised, and walk through it with the partner. A relocation works well because it touches every system. For example: the customer moves to an address served by a different wholesale fibre network, keeps their phone number, wants the old line to end on the day the new one starts, and has a VPN add-on that has to move with them.
Ask the partner to show:
- which systems take part: CRM, order management, the wholesale partner’s interface, network inventory, billing, ticketing
- where each piece of data comes from, and which system leads for the address, the activation date and the tariff
- which accesses the agent would have, for example read access to order status and wholesale feedback and no write access to billing
- how a member of staff and the agent reach the same information, each within their own rights
Then go through the error cases. The wholesale confirmation never arrives. The new address has a typo in the house number. The agent’s call to the order system times out halfway. For each one, ask what happens: does the process stop, retry or hand over to a person, is there a record of where it stopped, and can someone continue from there without starting over? Ask the partner to remove an agent’s access and to stop a running job while you watch. Ask to see all of it in a running system, including the log entry for each step.
Start with one manageable process
Once you have chosen, start with one process. Checking open relocations is a good first candidate. The agent reads the open relocation orders, compares their status with the technical feedback from the network side and lists missing details for customer service. At first it only reads and prepares suggestions. Write access, for example to create a follow-up task or send the customer a reminder, comes after its results have been checked for several weeks.
Agree on the following in writing before the start:
- how long a relocation may wait between steps before it is flagged, based on your current figures
- how often customers may have to ask again about the same relocation, and how you count it
- who in customer service checks the agent’s lists, and how often
- who fixes errors: the partner for the software, your team for the data, and who decides when it is unclear which applies
- who decides on the next step, such as granting write access or adding a second process
Microsoft’s 2026 Work Trend Index lists one of the questions every organisation working with agents will need to answer as “Who reviews agent performance?” (Microsoft, 2026). In its survey of 20,000 knowledge workers who use AI at work in 10 markets, quality control of AI output topped the list of human skills that matter more as AI takes on more work, named by 50% of respondents. Put a name next to each process before the first run.
Review the first weeks with customer service and tech
Meet every week during the first weeks, with someone from customer service, someone from the technical side and the partner. Look at the cases where the process got stuck and sort each one: the data was wrong or missing, the agent misread correct data, or the rule itself was unclear. The first group goes to your team, the second to the partner, the third to whoever owns the process.
Customer service and tech need to sit at the same table because the causes cross their boundaries. A relocation can stall because the wholesale feedback lands in a shared mailbox nobody checks on Fridays, and neither team sees that alone.
Extend the use once the flow has run reliably for a while: write access for the first process, or a second process such as checking port-ins. These weeks also show how the partner handles responsibility after the start: who turns up to the review, how quickly fixes arrive, and whether they raise problems before you find them.
Where METAVSHN stands
METAVSHN grew out of an ISP. The founders bring 30+ years in telecom from running Ticinocom, and Ticinocom runs on the METAVSHN platform today. Relocations, activations and partner add-ons at Ticinocom go through the same platform we offer to other operators, so when a step fails, it shows up in our own support queue as well. When Ticinocom added NordVPN as a partner add-on, it took under 2 weeks from kickoff to the first NordVPN activation. Ask us the questions in this article; we answer them with our own team and show the answers in the running system.
Bring one real case from your queue, a relocation or a port-in, and book a 30-minute walkthrough. We go through it with you on screen, including the error case.
Sources
All sources accessed on 31 October 2026.
- Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, MIT NANDA, “The GenAI Divide: State of AI in Business 2025”, July 2025. mlq.ai
- Microsoft WorkLab, “2026 Work Trend Index Annual Report: Agents, human agency, and the opportunity for every organization”, 5 May 2026. microsoft.com
Frequently asked questions
- What should an operator ask an AI software partner first?
- Ask the implementation team to show, on screen, how they use AI in their own daily work, including how they review results and which accounts they use for customer data. Then ask which solutions run productively at other operators and who checks their results.
- What is a good first AI process for a regional ISP?
- Checking open relocations. An agent reads the open orders, compares their status with the technical feedback and lists missing details for customer service, with read access only until its results have been checked over several weeks.
- How can an operator test how a partner handles errors?
- Walk one real customer case through with the partner, including failures such as missing wholesale feedback or a timeout halfway through a step. Ask to see where the process stops, what is logged and how a person picks it up, and ask a reference customer about their last incident.
