Building the end-to-end operator model
Building the end-to-end operator model
September 2026.
What this is
Two half-day sessions in the back half of August. Eight of us sit together and work through how one person can run a full cycle of operations at Datopian, from bizdev/sales to client engagement end-to-end, with agents doing the labour at each stage.
The format is hands-on. We take real cases and walk the cycle stage by stage: what an operator would actually do, where they'd get stuck, and what tooling would unstick them. Anything we build in the room — a template, a skill, a checklist — gets committed and becomes a shared kit. The curriculum below is the full map; the first two sessions cover the commercial front end, and we schedule the rest from there.
What this isn't. Not a reorg. No reporting lines change. No client is moved onto an untested delivery model. Nobody's current role is being removed as a consequence of this.
Who's in
| Person | Role in August |
|---|---|
| Anuar | Leads the process; owns pricing and the fixed-price catalogue |
| Rufus | Optional, subject to availability; co-leading and learning alongside |
| Daniela | Owns guardrails, review gates, and the client-facing presentation model |
| Osahon | Owns skill standardisation and the quality bar |
| João, Luccas, Ola, Monika | Operators; each owns one curriculum module's artifacts — to confirm against current focus areas |
Curriculum
Seven modules following the actual order a deal moves, so operators learn the cycle in the sequence they'll run it. Each module has the same shape: what an operator must be able to do alone, what we build while learning it, and where judgement stays human.
Modules 0–2 go first deliberately: the commercial front end is where our constraint actually is, and it's the half of the cycle most of us have never run.
0. Awareness and demand generation
The hardest part of the whole cycle, and the one nothing downstream can compensate for. A quote is worthless if nobody knows we exist. This module is about manufacturing awareness and attention — getting the right organisations to know Datopian and PortalJS before they have a procurement need.
- Operate: build and research a target list, run outreach that gets replied to, produce content that makes PortalJS the default answer to "how do we publish our data," build a speculative PoC for a target from their own public data, and convert attention into a first real conversation.
- Build: ICP definition and target-list generation · account research skill · outreach sequences with personalisation that isn't cosmetic · content engine (case studies with real numbers, migration benchmarks, comparison pieces) · PoC-led outreach: brief to working portal (architecture call, scaffold, load data, metadata mapping, quality checks) fast enough to run per target · PortalJS open-source and community funnel · CRM hygiene so this compounds instead of resetting.
- Judgement: who is actually worth pursuing, how we position against incumbents, what we want to be known for, when to stop chasing, and when a speculative PoC is worth building versus when it's free work nobody asked for.
PoC-led outreach. Our prospects' data is already public. We can build a working portal for a target organisation from their own open data before ever speaking to them, and lead with that instead of a pitch. A PoC used to be a sales-cycle deliverable that came after a proposal; it's now cheap enough to be an outreach weapon, so it lives here. The operator can still pull it forward into discovery, a proposal or an RFP response wherever it does the most good. Watch for competent-but-generic output: a PoC that looks like every other demo sells nothing.
1. Inbound/outbound, proposal and quote
- Operate: qualify an inbound/outbound lead, run discovery, scope the work, produce a priced quote against the catalogue.
- Build: discovery question set · proposal generator · quote calculator with floors and buffer policy · scope template.
- Judgement: whether to take the client at all, what to promise, when to walk away.
2. RFP / RFQ
- Operate: read a tender, make a bid/no-bid call, assemble a compliant response to deadline.
- Build: bid/no-bid checklist · reusable response library (profile, case studies, CVs, certifications, security answers) · compliance matrix workflow.
- Judgement: winnability, pricing against likely competitors, and what we can truthfully claim about named key personnel and allocations.
3. Contracting and legal
- Operate: get from won to signed — SOW, terms, DPA, IP and licensing, change control.
- Build: SOW template tied to each catalogue offering · standard terms with pre-agreed fallback positions · change-control clause · red-flag list that triggers escalation.
- Judgement: which terms we accept. This is the module where operators are deliberately not autonomous — it's the clearest case for the review threshold, and the one place where signing something wrong costs more than the engagement is worth.
4. Building the solution
From signed SOW to a finished portal the client accepts. This is the delivery work itself: where a PoC from module 0 gets hardened into the real thing, or gets thrown away and rebuilt properly.
- Operate: turn the SOW into a build plan, make the architecture call, run the full data migration or harvest, define the metadata schema, build the custom features (charts, maps, search, integrations), design to the client's brand, run client review cycles, and get sign-off against the SOW.
- Build: the PortalJS skill chain end-to-end, tested against three past engagements as regression cases · PoC-to-production hardening checklist · client review and acceptance workflow tied to the SOW · change-request intake that feeds module 3's change-control clause.
- Judgement: architecture choice, and design. This is where Osahon's craft argument bites hardest, so it's where we watch for competent-but-generic output most closely. Also: what's in scope versus a change request, and when the work is actually done.
5. Deploying to staging and production
- Operate: stand up environments, deploy to Arc/Cloudflare, SSO, domains, run compliance gates, hand over.
- Build: deploy runbook as skills · environment and cutover checklist · automated accessibility (WCAG/508) and DCAT validation gates.
- Judgement: the go-live readiness call.
6. Running and maintaining
- Operate: hold the subscription relationship — monitoring, incident response, upgrades, reporting, renewal and expansion.
- Build: support runbook · SLA definitions we can actually meet · monitoring and alerting · health-check report template · renewal motion.
- Judgement: what SLA to commit to, and when an incident stops being routine.
Pacing. The two August half-days cover modules 0–1, where our constraint actually is and where most of us have the least practice, including PoC-led outreach. Modules 2–6 get scheduled from there, once we've seen how much ground a half-day actually covers. Better to run the demand-generation work properly than to rush all seven.
