Lesson 1: The Platform Selection Framework
By the end of this lesson, you will be able to:
- Turn the platform reading you did in Unit 2 into a structured score against your own project, using one continuous investigative habit rather than two separate checklists (K8, S27)
- Apply each of the five dimensions to a platform decision with specific, evidenced reasoning (K8, S27)
- Recognise data sensitivity as the dimension that can eliminate options outright (K8, K2)
- Separate what a platform can do from what you can legally access and realistically sustain (K8, S27)
- Use your Evidence Companion to draft a first-pass assessment for your project, then judge and correct it rather than accepting it (K9, S27)
One thing to hold clear before we start. In Module 1 you used a five-dimension framework — the Process Suitability Framework — to decide which processes were worth automating in the first place. This lesson introduces a different tool for a different job: the Platform Selection Framework, which chooses which platform to build a chosen automation on. Same habit — score a candidate across a handful of dimensions — but a different subject and different dimensions. Module 1 chose the what; this chooses the where. If the two ever blur, come back to that distinction.
From reading a platform to scoring it against your project
In Unit 2 you built a habit of reading any platform on its own terms: its capability, its limitations, its risk profile, its pricing, and its organisational fit. That reading told you what each platform is. It did not, on its own, tell you which one to choose.
This unit turns that same investigative habit into a decision. The five selection dimensions below are not a new list to memorise alongside the reading questions — they are the same interrogation, now pointed at a target. You read a platform once to understand it; you score it against the five dimensions every time you consider it for a specific project. The sharper question has shifted from "what is this platform?" to "does this platform fit my project?", and because the answer depends on your project, the same platform can score differently for two different projects.
So hold this as one evolving lens, not two competing fives. What you learned to notice about a platform in Unit 2 is exactly what you now weigh against your own data, systems, support, and cost reality.
Capability is not the same as access
Before the dimensions, one distinction that runs underneath all of them and that trips up capable practitioners more than any other: what a platform can do is a separate question from whether you can actually use it.
A platform can be the most capable option on the market and still be the wrong choice, because two of the five dimensions are not about capability at all. They are about access. Dimension 1 asks whether you may legally use the platform for your data. Dimension 4 asks whether your team can realistically sustain it. A platform you are not permitted to feed your data into, or that no one on your team can maintain, is not a capable option with a drawback — it is not an option. Capability you cannot access is not capability you have.
🔑 Separate capability from accessibility: A platform's raw capability tells you what it could do. Whether you can legally process your data on it (Dimension 1) and realistically maintain it (Dimension 4) tells you what it can do for you. Assess accessibility before you are seduced by capability, because the most impressive platform you cannot use is worth less than an ordinary one you can.
The five dimensions
The Platform Selection Framework assesses any shortlisted platform against five dimensions. Together they turn a list of candidates into a defensible selection.
Dimension 1: Data sensitivity and compliance
What it asks. What type of data does the automation process? Is it personal, regulated, or special category? Does the platform's hosting model and its data processing agreements meet the relevant compliance requirements?
Why it matters most. This is the highest-stakes dimension, and it behaves differently from the other four. The others rank platforms from better to worse fit. This one can eliminate a platform outright. A platform that cannot legally process the data your project handles is not a weak option to be weighed against its strengths; it is not an option at all. For this reason, assess this dimension first. There is no point scoring a platform highly on cost and ecosystem fit if its data handling rules it out before those strengths ever come into play.
Worked example. A project processing client financial data assesses a cloud-hosted platform whose data processing agreement does not offer the data residency the firm's compliance team requires. However cheap, well-integrated, and easy to use that platform is, it scores a hard fail on Dimension 1, and the assessment stops there for that candidate.
🔑 Dimension 1 is an eliminator, not a ranker: A platform that cannot meet your data and compliance requirements is removed from the shortlist, regardless of how well it scores on the other four dimensions. Assess it first, because it can save you the effort of assessing the rest.
Dimension 2: Ecosystem fit
What it asks. Which applications, data sources, and services does the automation need to connect to? Does the platform have native connectors to those systems, or would you need generic API integration to bridge the gap?
Why it matters. Depth of integration into the systems you already run significantly affects how much configuration and maintenance the project will demand. A platform with a native connector to your finance system will be quicker to build and easier to maintain than one where you hand-build the integration through a generic API call and then own that integration forever.
Worked example. Two platforms both technically support connecting to a CRM. One has a maintained native connector; the other requires a custom API integration the team would build and maintain themselves. For an organisation already stretched on technical capacity, the native-connector platform scores meaningfully higher on Dimension 2, even if the two are equal elsewhere.
Dimension 3: Automation complexity
What it asks. Does the use case require agentic behaviour, where the tool decides what to do based on what it finds? Or is it a fixed or AI-augmented workflow, where the steps are specified in advance? This is the project shape you worked out in Unit 1, now used as a selection criterion.
Why it matters. Matching complexity to the platform's architecture avoids over-engineering. Not every use case needs an agent. A fixed workflow or an AI-augmented workflow running reliably on a workflow-first platform is a better outcome than the same process forced onto an agentic platform that adds cost, audit difficulty, and maintenance burden for capability the project never uses.
Worked example. A project whose process is fully specified in advance (a fixed workflow) is assessed against an agentic automation platform and a workflow-first platform. The agentic platform is more capable. The workflow-first platform is the better fit, because the additional capability of the agentic platform is capability this project will never call on, and the learner would be paying for and maintaining complexity for no return.
Dimension 3 is where the project-shape work from Unit 1 pays off. If you named your project as a fixed workflow but find yourself assessing only agentic platforms, that is a mismatch worth surfacing. Ask yourself directly: what in your use case requires the tool to decide its own sequence? If you cannot answer, your complexity dimension is pointing you at the wrong family.
Dimension 4: Technical support available
What it asks. What level of expertise does the organisation have to configure, maintain, and troubleshoot the platform? Not what expertise exists in theory, but what is realistically available to this project, on an ongoing basis, after you have moved on.
Why it matters. The best technical choice that nobody on the team can maintain is not the best practical choice. A platform that requires fluent custom scripting, chosen by a team with no one able to write it, produces an automation that breaks and stays broken. This is the accessibility half of the capability-versus-access distinction: capability you cannot sustain is not capability you have.
Worked example. A self-hosted platform offers maximum control and the lowest running cost. The team has no one able to maintain server infrastructure. On Dimension 4, that platform scores poorly for this organisation despite its technical merits, because the capability depends on support the team does not have and is not going to acquire in the project's timeframe.
Dimension 5: Cost and scale
What it asks. What is the platform's pricing model, and at what volume does cost become a significant constraint? What does a realistic bill look like at your project's actual and projected usage, rather than at the entry price?
Why it matters. As Unit 2 showed, pricing models differ so much between families that the cheapest option at low volume can become the most expensive at scale. The right choice depends on your expected usage pattern and your organisation's cost tolerance, assessed at both current and projected scale rather than at today's pilot volume.
Worked example. A platform on per-operation pricing looks inexpensive for a pilot running a handful of times a day. Projected to the full rollout volume of thousands of runs daily, each making several internal operations, its monthly cost overtakes a per-user platform that looked more expensive at pilot scale. On Dimension 5, the assessment has to use projected volume, not pilot volume, to avoid a decision that is correct today and wrong in six months.
Draft your five-dimension assessment with your Companion
You now have the framework. You also have something you built in Unit 2: an Evidence Companion loaded with your real project's context — its definition, its current-state process, the systems and data it touches — and a working constraint you wrote at the end of the sector-and-context lesson. That is precisely the raw material a five-dimension assessment runs on. So put the Companion to work drafting one, then do the part that actually matters: judge it.
The concept this demonstrates is the eliminator. Dimension 1 can remove a platform outright, so you commit your own verdict on it before you read the Companion's. If any candidate fails Dimension 1 for your project, you should be able to say so yourself; the Companion's job is to pressure-test that view and fill in the ranking dimensions, not to make the call for you.
How to run it:
- First, and without the Companion, name your two or three candidate platforms and write one sentence on Dimension 1 for each: does its data handling meet your project's compliance constraint, or is it a hard fail? (Capture this in the first field below.)
- Open your Evidence Companion — the Claude Cowork or Copilot agent you built and loaded with your project materials.
- Paste the request below. Fill any
[bracket]the Companion could not already know from its knowledge base. - Read its draft against your own Dimension 1 verdict. Where it disagrees, work out which is right and why — and be ready to overrule it.
- Treat every compliance and pricing claim as unverified until you have checked it against primary documentation (the skill you will sharpen in Lesson 3).
Using the project context you already hold, help me draft a five-dimension
selection assessment for the two or three candidate platforms below:
[list your candidates].
Assess each platform against these five dimensions, in this order, showing your
reasoning for each:
1. Data sensitivity and compliance — can this platform legally process my
project's data, given its hosting and data-processing terms? Treat this as a
PASS/FAIL gate, not a score, and assess it first.
2. Ecosystem fit — does it connect natively to the systems my project runs, or
would I hand-build and own the integration?
3. Automation complexity — does it match my project's shape, or is it more (or
less) than the use case actually needs?
4. Technical support — can my team realistically configure and maintain it after
the project, given the expertise we actually have?
5. Cost and scale — what does a realistic bill look like at my PROJECTED volume,
not my pilot volume?
For any dimension where you do not hold enough of my project's detail to answer,
flag it as an information gap and tell me what you would need, rather than
guessing. Do not give me a single "use this platform" verdict — surface the
scores and the gaps so I make the decision myself.
The Companion is fast and fluent, which is exactly why it is dangerous on Dimension 1. It will happily declare a platform "compliant" in a confident tone on the strength of a marketing page it half-remembers. That is why you commit your own eliminator verdict first, and why every compliance claim it makes is a claim to verify, not a fact to record. Use it to draft the ranking and to surface gaps you had not spotted — not to settle the one dimension that can end the decision.
[DECIDE IT — 15 minutes] Draft the assessment with your Companion, then record your own judgement on it.
Five-Dimension Assessment — Your Project
Draft a five-dimension assessment for your candidate platforms with your Companion, then correct it with your own judgement. This is the analytical core of your Unit 3 recommendation — keep it. Complete it in one go and save as a md file. Save the md file within the same source folder you've given Evidence Companion access.
💬 Reflection prompt: Of the five dimensions, which is currently the hardest for you to answer with evidence for your own project? What single piece of information would turn that guess into an evidenced answer, and where would you find it?
⏭️ Up next - Lesson 2: You have scored your candidates. The next lesson turns scores into a decision — why the most capable platform is rarely the right one, how to handle the information gaps every real assessment contains, and committing to a platform for your project.