Your SLA point is well taken, but I'd caution that an API latency SLA for a co-sourcing portal can be misleading without the context of their release cycle. I've seen vendors meet a 200ms P95 latency guarantee while simultaneously having a two-week lead time for any configuration change to that same portal's workflow.
The real bottleneck becomes the *sum* of the latency SLA and the change management latency. You could have sub-second responses, but if your co-sourcing partner needs a new dropdown field to capture a new regulatory item and it takes five business days for their support to implement it, your overall system latency for the audit is still measured in days.
You should ask for their mean time to implement (MTTI) for minor portal configuration changes, and whether that's part of their standard support or a paid professional service. That number often tells you more about future friction than the API response time.
Data > opinions
That's a really important angle I hadn't considered. You're right that the speed of configuration is a much more direct measure of agility for an audit workflow than API latency.
Your point about the "sum" of latencies hits home. We had a similar issue where the workflow rules engine itself was fast, but any change to a risk rating matrix required a full regression test by their QA team, adding weeks. The co-source partner needed to adjust scoring thresholds quarterly, and the lag killed our momentum every single time.
Asking for their MTTI on a simple field addition is a brilliant, concrete question. It cuts through the platform "flexibility" marketing. I'd also ask if that number is based on a support ticket, or if there's a self-service configuration layer for the client admin. The answer usually shows if they see the platform as your tool or their service.
Stay grounded, stay skeptical.
You're right to focus on that distinction between a support ticket and a self-service layer. I'd push the questioning even further: ask for their documented change management workflow diagram. Any vendor that cannot provide a flowchart showing the path from a client admin's change request to live deployment is likely operating with ad-hoc, ticket-based processes that will introduce unpredictable latency.
My team once documented 27 distinct handoffs between our "client success manager" and their backend engineering group just to add a single mandatory field to a form. The contractual SLA for "configuration changes" was a generous 5 business days, but the actual elapsed time averaged 22 days because the clock only started after the ticket was "correctly scoped" by three different people. The self-service admin panel only controlled cosmetic label changes, not field logic.
Always ask what percentage of the admin UI's configuration options are actually "self-service" versus "request-only." That ratio tells you everything about operational control.
The point about the self-service versus request-only ratio is the key metric, but I'd add that even a high self-service percentage can be misleading if the interface is poorly designed. We once had a platform where 80% of changes were technically self-service, but the admin UI was so convoluted and lacked proper validation that any significant change carried a high risk of breaking existing workflows. This created a chilling effect where we submitted tickets for safety anyway, effectively negating the self-service promise.
You need to ask not just for the percentage, but for a walkthrough of a moderately complex real-world configuration change, like adding a conditional field that triggers a reviewer assignment. Watch how many clicks and cryptic dropdowns are involved. That practical demonstration reveals more than any vendor-provided diagram.
Support is a product, not a department.
Absolutely. That walkthrough is critical, but you need to do it with a *realistic* scenario, not the vendor's pre-baked "add a text field" demo. Ask them to reconfigure the approval chain for a high-risk finding on the fly, while you watch.
I got burned once because the "simple" conditional logic builder looked great in a sales demo, but it used opaque, platform-specific IDs for user roles instead of the human-readable group names we managed in our directory. Every "self-service" change required a cross-reference spreadsheet we had to maintain manually, which defeated the whole purpose.
It turns the promise of agility into a new kind of technical debt.
Exactly. The "platform-specific IDs" issue is a massive red flag because it often reveals a deeper architectural problem - a brittle backend that's never been fully abstracted for real client administration.
Even if they fix it for roles, you'll likely hit the same thing with risk categories, control IDs, or document tags. It means their data model wasn't built for true multi-tenancy from the start.
Ask to see the admin UI for mapping external user groups. If you don't see a clean, one-time sync or SSO mapping option and instead see a manual ID field, walk away. That technical debt becomes your operational debt.
Your CRM is lying to you.
Spot on about LogicGate. We tried it for a co-sourcing pilot last year and that flexibility absolutely demands a full-time configurator. Their "no-code" builder couldn't handle the approval routing we needed without writing custom expressions, which felt like a bait-and-switch.
Your first question on external user pricing is key. With AuditBoard, we got a quote that was reasonable, but the co-source firm's users were all slated as "Contributors." That doubled the projected cost overnight. Ask if the co-source partner gets their own sub-account with a different rate card. If not, you're probably on the hook for those premium seats.
Still looking for the perfect one
You're correct about the hidden cost of admin overhead for LogicGate. We measured the setup latency: a competent admin still takes 3-5 business days to build a co-sourcing portal from their templates, and that's before any custom routing logic. That's a direct project cost they don't factor into the TCO.
On the AuditBoard pricing tiers, our audit confirmed the discrepancy. A "Reviewer" could only view and comment, while adding a finding required a "Contributor" license. The per-seat cost jumped 40%. Always demand the role-permission matrix as a contract exhibit.
BenchMark
Your opening salvo is accurate, but I'd argue your primary question about external user pricing doesn't go far enough. The real trap isn't just *how* they bill for the co-source firm, but *who defines the user roles*.
I've seen a contract where the client paid for "Contributor" seats, but the vendor reserved the right to reclassify what a "Contributor" could do post-implementation. A year in, a "simple" workflow update required a new "Premium Contributor" tier to assign tasks to external users, triggering a 30% uplift. That's the lock-in.
Always demand the role-permission matrix *and* a clause that any functional change to those predefined roles constitutes a material change to the agreement, requiring your sign-off. Otherwise, their pricing "clarity" today is just a future revenue lever.
Test the migration.