I run a lot of vendor trials for support teams, and one lesson keeps resurfacing: a standard seven-day trial rarely reveals the full cost of switching platforms. Vendors make their modern UIs and canned automations look effortless, but the long-term expenses — training, migration complexity, custom workflows, and maintenance — are where budgets and timelines actually get spent. In this post I’ll walk you through a focused seven-day trial plan you can run for two leading contenders (Zendesk and Intercom) that surfaces the hidden training and migration costs so your procurement and exec stakeholders aren’t surprised later.
Why a seven-day trial must be surgical
Seven days is short. That’s both a constraint and an advantage: it forces you to design experiments that produce high-signal outputs quickly. The aim isn’t to prove which product “feels better” — it’s to gather evidence on the likely operational lift required to reach parity with your current system, and to quantify training and migration effort.
What I measure during the trial
Decide on the outcomes you need to quantify before you begin. I recommend capturing both qualitative and quantitative signals:
Setup time: hours required to create core objects (users, groups, ticket types, conversation routing).Workflow parity: ability to replicate 3–5 critical workflows (SLA routing, escalation, refunds, VIP handling).Data migration effort: steps and time to export/import 3 sample records sets (tickets, users, conversation history).Training time: time taken for an agent to complete a simple task in the new UI and reach acceptable speed and accuracy.Admin complexity: number of admin steps and the presence of required APIs or integrations.Supportability: vendor documentation clarity and speed of vendor trial support response.Collecting these signals is what separates an emotional “we like this UX” decision from a defensible operational one.
Preparation: stakeholders, environments and scenarios
Before day 1, align these people and resources:
Stakeholders: one product owner, one support manager, two frontline agents, an admin/IT person, and the finance/procurement reviewer.Data samples: anonymised exports of 50 tickets with varying complexity, 30 user records, 10 knowledge base articles.Access: trial accounts for Zendesk and Intercom, with admin privileges.Baseline metrics: your current SLA breach rate, average handle time (AHT), first contact resolution (FCR), and time-to-resolution for the sampled ticket types.Seven-day trial plan (what to do, each day)
Run the same plan against both Zendesk and Intercom in parallel or sequentially. I prefer parallel to limit temporal bias, but ensure separate admins to avoid cross-platform contamination.
Day 1 — Platform familiarisation & baseline setup: create the admin user, set up basic company profile, import 10 users. Time the session. Note confusing UI elements and missing features. Document how many clicks/steps to create a ticket, a macro, and a basic automation.Day 2 — Core routing & workflows: replicate your two highest-volume workflows (e.g., billing disputes, technical troubleshooting). Implement routing rules, SLAs, and escalations. Log any features that require paid add-ons or an API workaround. Measure admin time spent.Day 3 — Data import and history preservation: attempt to import your exported tickets and customer history. Assess if threaded conversations and attachments persist. Note the steps required for mapping fields and whether bulk import tools exist or if you’ll need scripting/ETL help.Day 4 — Agent productivity test: give agents three representative tickets and measure time-to-first-response, resolution time, and satisfaction (self-rated confidence). Run the same tasks in your current product to compare deltas.Day 5 — Knowledge base, bots & automation: create or import two KB articles, set up a simple bot flow that deflects a common query. Track how much content cleanup is needed and whether the platform supports versioning and analytics for KB articles.Day 6 — Integrations & edge cases: connect 2 key integrations (CRM, product telemetry, or Slack). Test webhook reliability and whether the vendor’s native integration covers your use case or if middleware is required. Test permissions and SSO setup.Day 7 — Admin handover & training sprint: run a 60–90 minute training session with two agents and an admin using a scripted curriculum. Measure time-to-competence by task completion and error rate. Collect feedback on confusing features and estimate ongoing coaching needs.How to measure training cost
Training cost is more than the number of hours you spend in a session. I break it down like this:
Initial training hours: live session time (multiply by instructor + attendees hourly rates).Practice & ramp time: estimated average hours for an agent to reach baseline productivity (use Day 4 delta between new platform and current AHT as a proxy).Material creation: hours to create internal KB articles, playbooks, and screencasts.Ongoing coaching: weekly support for X weeks post-migration (mentor time, shadowing).Example calculation (simple):
| Item | Hours | Rate (£/hr) | Cost |
| Live training (1 instructor, 10 agents) | 2 + setup 3 | £50 / £30 | £(100 + 90) = £190 |
| Practice & ramp (10 agents * 8 extra hours) | 80 | £30 | £2,400 |
| Material creation | 10 | £40 | £400 |
| Ongoing coaching (4 weeks, 2 hrs/wk) | 8 | £50 | £400 |
That quick model produces a tangible training budget you can compare to vendor implementation services.
How to estimate migration costs
Migration costs are often the most underestimated. Capture these during Days 2–3 and formalise estimates into categories:
Export/cleanup: time to identify and clean bad data, dedupe, and map fields.Transformation scripting: time to write ETL scripts or configure middleware (e.g., Zapier, Workato).Attachments & history: costs to migrate attachments and threaded histories (storage transfer, potential API limits).Testing & reconciliation: time to validate migrated records and reconcile counts.Vendor migration services: cost and SLA options if you buy their professional migration.Ask vendors for real migration case studies similar to your scale. For example, a 100k-ticket migration may hit API rate limits and require chunked transfers or paid migration tooling. During the trial explicitly attempt to migrate a small but representative bulk and time the run — that will expose API throttling and error handling needs.
Key questions to ask vendors (and your internal team) during the trial
What limitations exist on API throughput and bulk exports/imports?Do your native integrations cover our CRM/telemetry stack, or will middleware be required?Can you provide a proof-of-migration example for a similar customer?What are licensing implications for bots, workspaces, or advanced routing?What training resources and certification paths are available for admins and agents?Quick comparison table to capture during the trial
| Signal | Zendesk (notes) | Intercom (notes) |
| Time to setup basic routing | hrs | hrs |
| Workflow parity (3 checks) | Yes/No + workarounds | Yes/No + workarounds |
| Migration: tickets & attachments | ease / blockers | ease / blockers |
| Agent ramp delta (AHT) | +/- minutes | +/- minutes |
| Admin UI complexity | low/med/high | low/med/high |
| Estimated training cost (£) | £ | £ |
| Estimated migration cost (£) | £ | £ |
Populate this table with real numbers and use it in your vendor scorecard. It’s far easier to justify a higher license fee if you can show lower migration or training costs — and vice versa.
Run this trial on your domain (https://www.customer-carenumber.co.uk) or an anonymised test tenant, and keep all notes centrally. Your finance and procurement leads will thank you for the transparency when you translate “nice UI” into “£X saved in migration” or “Y hours added to onboarding.”
If you want, I can provide a trial workbook (spreadsheet template) you can drop your Day 1–7 measurements into and it will auto-calc training and migration estimates. Tell me your current ticket volumes and agent count and I’ll tailor the template for Zendesk vs Intercom assumptions I’ve validated in the field.
