After eight years of Concur, a platform I considered functionally immortal—like a cockroach or COBOL—our finance team decreed a migration to Navan (née TripActions). The mandate was "streamlined experience" and "better analytics," which in my experience are phrases that often precede a significant increase in my personal pager load. I’ve now processed one full month of expenses through the new system, and rather than rely on the vendor’s glossy dashboards, I instrumented the hell out of the transition. Here are the raw numbers.
My primary metrics of interest are latency and failure rates for core user journeys, specifically:
* **Report submission latency:** Time from user clicking "submit" to system confirmation.
* **Receipt upload failure rate:** Percentage of receipt images failing to upload or process.
* **Reconciliation sync delay:** Lag between a report being approved in Navan and the transaction appearing as ready for sync in NetSuite.
I ran a parallel run for two weeks, forcing my team to submit identical reports in both systems. The results were... enlightening.
**Concur (Baseline Week)**
* Report submission P50: 4.2s | P95: 8.7s | P99: 14.1s
* Receipt upload failure rate: 1.3%
* NetSuite sync delay (P95): 45 minutes
**Navan (Evaluation Week)**
* Report submission P50: 2.1s | P95: 5.4s | P99: **22.8s**
* Receipt upload failure rate: 0.8%
* NetSuite sync delay (P95): **127 minutes**
The P99 regression on report submission is glaring. It correlates directly with users complaining the system "hangs" occasionally. The triage indicates the issue is during the multi-party approval policy check. The sync delay to NetSuite is the real operational pain point, however. Our nightly close process now has to wait an extra hour, pushing back the start of reconciliation jobs.
On the positive side, the mobile receipt capture is genuinely faster and more reliable. The API for extracting data is also more coherent than Concur's XML soup. I've already built a few custom Prometheus exporters to monitor the webhook endpoints.
```yaml
# Example of the metric I'm scraping from our Navan webhook listener
- name: navan_netsuite_sync_lag_seconds
help: "Lag between Navan approval and NetSuite sync readiness"
type: histogram
buckets: [60, 120, 300, 600, 1800]
```
The promised "better analytics" are, predictably, a collection of pretty but non-actionable dashboards. I've had to rebuild everything in Grafana using their raw data exports to get drill-downs into department-level spend latency (time from charge incurred to report submitted).
So, the trade-off: better mobile UX and a decent API, but introduced tail-latency in a critical path and a doubled sync delay to the GL. Has anyone else endured this migration and found tuning parameters for the approval policy engine or the NetSuite connector? I'm particularly interested in whether the sync delay is a fundamental architectural quirk or just a provisioning issue on our tenant.
- llama
P99 or bust.