Choose Against Your Requirements, Not the Vendor's Demo
Platform selection and implementation oversight evaluated against your actual use cases, not a sales pitch.
Where this usually breaks down
A vendor demo is built to make the platform look good, not to reveal how it performs against your edge cases - sales engineers know which scenarios to show and which to route around. That gap gets expensive fast: contracts are annual, and switching a year in means re-running the whole selection process while unwinding whatever got built on the wrong foundation.
What this service actually solves
Requirements get defined before any vendor conversation starts, based on actual use cases from the teams who'll use the platform daily. Vendors get evaluated against those requirements, proof-of-concept work stress-tests the scenarios that matter to your business, and implementation gets overseen through go-live.
How we run it
We treat requirements definition as the highest-leverage step in the process, since a flawed requirement list makes every later decision worse. Proof-of-concept periods get structured around your actual edge cases rather than the vendor's script, and we stay through implementation so the handoff doesn't quietly drop anything.
Capabilities & deliverables
Requirements Definition
- Use case gathering across every team that will touch the platform
- Prioritised requirements list before any vendor outreach begins
Vendor Evaluation & Shortlisting
- Structured evaluation against your requirements, not marketing materials
- Reference checks with comparable companies where available
Proof-of-Concept Structuring
- Trial scenarios built around your actual edge cases
- Clear pass/fail criteria defined before the trial starts
Implementation Oversight
- Project management through build and configuration
- Checks that delivered functionality matches what was sold
Post-Implementation Adoption Review
- Assessment of actual usage against intended workflows after launch
- Adjustment recommendations based on real early usage patterns
How an engagement runs
Requirements Gathering
We interview every team that will use the platform to capture real use cases, not assumed ones.
Vendor Outreach & Shortlisting
Vendors are approached with your actual requirements, and a shortlist is built against fit, not brand recognition.
Proof-of-Concept Structuring
Trials are designed around your specific edge cases with clear criteria for what counts as a pass.
Selection & Negotiation Support
The final decision is made against evaluation results, with contract and pricing negotiation informed by what was actually tested.
Implementation Oversight
We track the build against what was scoped, flagging gaps between what was sold and what gets delivered.
Post-Implementation Review
Once live, actual usage gets checked against intended workflows, and adjustments get recommended based on real behaviour.
Who needs this
Teams choosing between multiple marketing technology vendors
If a shortlist already exists but the requirements behind it were never written down, that gap tends to resurface during implementation.
Teams that got burned by a platform that looked great in the demo
A requirements-first process is specifically designed to catch what a demo is built to hide.
Related work
We're still building out published proof for this specific service - ask us directly and we'll walk through relevant examples.
How to engage us for this
Project-based
A defined outcome with a start and end date - an audit, a migration, a campaign build, a tracking overhaul. Fixed scope, fixed price, agreed upfront.
Ongoing retainer
Continuous management and optimization once the initial build is live - campaigns, SEO, reporting, and iteration run every month under one accountable team.
Advisory
Strategy and oversight without full delivery - we review what's already running, unblock decisions, and point an in-house or existing team in the right direction.
Common questions
No - we don't take referral fees or reseller commissions from any platform vendor. The evaluation is built around your requirements, and we have no financial incentive to steer it toward a particular outcome.
No - even a well-run selection process can't eliminate every risk, since some issues only surface at real production scale. What we can guarantee is that the decision is based on your actual requirements and a real proof-of-concept, not a sales pitch.
Requirements and vendor evaluation typically take four to eight weeks depending on how many stakeholders are involved. Implementation timelines vary by platform and are set once a vendor is chosen.
We provide project oversight and hold the vendor or implementation partner accountable to what was scoped. Whether we or an internal/vendor team does the hands-on technical build depends on the platform and your existing resources.
That's a legitimate outcome, and it's better to learn it during evaluation than after signing a contract. Sometimes the honest recommendation is to adjust the requirement, delay the purchase, or reconsider whether a new platform is needed at all.
For any platform that's a significant investment or touches core workflows, yes - a demo cannot substitute for testing against your actual data and edge cases. For smaller, lower-risk tools, a lighter evaluation is sometimes proportionate.
Not sure a platform demo told you the whole story?
We'll define requirements and structure a real evaluation before you commit to a contract.
Ready to get started?
We usually reply within 24 hours.
Platform Selection & Implementation, in detail
Platform selection and implementation is defining what a marketing technology platform actually needs to do for your business before evaluating vendors, then overseeing the buying and build process so the delivered system matches the requirement, not the demo.
Scope, area by area
| Area | What we deliver |
|---|---|
| Requirements | Documented, prioritised use cases gathered before vendor outreach |
| Vendor Evaluation | Shortlist and structured comparison against your specific requirements |
| Proof-of-Concept | Trial structure with defined pass/fail criteria tied to real use cases |
| Implementation | Project oversight through build, configuration, and go-live |
How this compares
| Requirements-Led Selection | Demo-Led Selection |
|---|---|
| Vendors evaluated against documented use cases | Vendors evaluated against a curated sales demo |
| Proof-of-concept tests your actual edge cases | Trial period follows the vendor's suggested script |
| Implementation checked against what was promised | Gaps between sales promises and delivery surface after signing |
The most expensive mistake in platform buying isn't picking the wrong vendor - it's never finding out what you actually needed before evaluating any of them.
What this changes for the business
- Platform decisions get made against documented requirements instead of whichever demo was most polished
- Contract and pricing negotiations happen with real proof-of-concept results in hand, not just a sales pitch
- The gap between what was sold and what gets built gets caught during implementation, not discovered a year into the contract