Choosing systems your team will actually use
Operations platforms are usually chosen by people who will never use them for a full day. A steering group reads the responses to the RFP. Heads of department sit through demos. Procurement negotiates the seat count and the term. Six months after go-live, the analysts are running half their work from a spreadsheet parked next to the new system.
Adoption gets decided later than that, on an ordinary Tuesday, by an analyst with forty cases in the queue who finds the new screen slower than the old way of doing it. If you want to know whether a system will be used, test it with that person, on that kind of day, before the contract is signed. Feature matrices are little help here. Serious vendors tick most of the boxes, and no box on the sheet describes how long it takes to close a case.
One number tells you more than the matrix does: how many other systems an analyst still has to open to finish a case. If the new case management tool shows the dispute, and the analyst still needs the processor portal for the reason code and the CRM for the customer's last complaint, the tool has added a tab and removed nothing. That count is easy to collect during a pilot and hard to argue with afterwards.
What to test in a pilot
Vendor sandboxes are built to show the product at its best, with tidy data and one happy path. A pilot should look like a normal week of your work instead, which takes some preparation on your side and a few weeks of an analyst's time. Budget for that, and agree the cover with the team lead before you start.
-
Run last month's real cases through it
Take a sample from your own queues and include the ugly ones: the partial refund on a split shipment, the dispute with four attachments, the onboarding case where the address on the utility bill does not match the application. Clean demo data only tells you the product works when nothing is wrong.
-
Put the daily users in the room
Include two or three analysts, a team lead and whoever covers the late shift. Time a case end to end against today's baseline, and ask each of them what they would still do outside the system. That list is the start of your workaround inventory.
-
Price the integration against your own systems
List every system that has to feed the platform or read from it: the ledger, the processor, the CRM, the KYC provider. For each one, find out whether there is a working API, a file transfer, or a line in the proposal that says professional services, and ask who maintains the mapping when the processor next changes its file format.
-
Count the administration
Someone has to add users, maintain roles so that maker-checker still holds, update templates, read release notes and test each upgrade in a sandbox. Ask the vendor what that takes at a firm your size, then ask one of their customers the same question, and put the answer in the business case.
A vendor who will not support a pilot on your own data is telling you something about how the implementation will go. So is a vendor who insists their consultants run the pilot for you.
Configuration versus customization
The distinction sounds like vendor vocabulary until you need a change. Configuration is a change your own administrator makes through the product's settings: a new queue, a new field, an approval rule, a different SLA timer. It survives upgrades and needs no developer. Customization is anything that needs code, scripts or the vendor's services team. It tends to break at upgrade time, and it puts every future change on somebody else's calendar.
Operations teams change their rules constantly. Fee tables move, a partner adds a return reason, compliance wants a second approver above a new limit, and a new market needs a queue of its own. If each of those needs a change request and a quote, the team stops asking and starts working around the system, which is where the spreadsheet beside it comes from. We wrote last year about what that spreadsheet turns into, and a new platform does not make it go away on its own.
So during the pilot, name three changes you know you will need in the first year and have your own administrator make them, with the vendor in the room and away from the keyboard. Time each one. If a new approval rule takes your administrator twenty minutes, that is configuration. If it takes a ticket, a scoping call and a statement of work, you have learned what the next five years look like, while you can still price it into the contract.
Write the pass criteria down before the first demo: cases per hour against today's baseline, the number of other systems still opened per case, the time your administrator needs for a routine change, and the integrations that have to work on your data before anyone signs. Agree them with the analysts who will do the testing, and let those people score the pilot. Add one more criterion while you are at it, because it is easiest to negotiate now: what you get back, in what format, if you leave in year three. It is much harder to be charmed by a polished demo when the people who will live with the result already know what they are measuring.
Discuss your operations
