Center of Excellence + Salesforce — scope, sequence, funding, capacity and ownership for 2027–2028
Outward Bound USA has several Salesforce efforts underway or proposed for 2027 and 2028. They are currently discussed as separate projects with separate budget lines, which makes them look more expensive, more numerous and less connected than they are. This brief pulls them into a single view so the Leadership Team can see what each project is, how they depend on one another, what they cost, who would own them, and what changes for Schools as a result.
It is a decision document, not a status report. Section 17 lists the choices that need to be made. Everything before it exists to support those choices.
Each School runs its own Salesforce system, built and customized independently over roughly a decade. That independence is not the problem in itself. The problem is that the Schools and the national office cannot reliably answer shared questions — how many students come back for a second course, where group sales are stalling, how enrollment is tracking across the network — because the underlying data is structured differently in every system, and in some cases is not collected at all. We have also committed to funders, specifically through the Character Compass grant, that we will be able to report on repeat participation across the network.
The work breaks into three layers. Shared foundation is the plumbing: agreed data definitions, a governance agreement, and the Data Pipeline that moves information between School systems and the national office. Business capabilities is where value shows up: better group sales processes, a shared enrollment capability, and recovering revenue currently lost to cancellations. Use and deployment is what happens inside Schools, including bringing every School to a workable minimum standard.
Two Schools have already spent, or are about to spend, their own money on Salesforce work that overlaps with what is proposed here, and both have asked whether OBUSA can help pay for it. A third has deferred its own Salesforce investment while waiting for clarity from us. Section 07 lays this out. It is not a recommendation to reimburse anyone; it is a live dynamic the Leadership Team should decide how to handle before it is decided for us.
The five things worth knowing before the discussion:
How to read this if you have ten minutes: Section 03 defines each project in plain terms. Section 11 shows the money. Section 12 shows a proposed order of work. Section 17 lists the decisions.
These efforts are usually listed side by side, as if they were equivalent. They are not. One layer is shared infrastructure, one is where revenue and mission value appear, and one is what happens inside Schools. Reading them as layers makes both the order of work and the budget questions clearer.
Agreement on the minimum fields, names and definitions every School uses, what moves between systems and what stays local. A standard model already exists as a starting point.
Prerequisite for everything elseThe mechanism that moves course, application, contact and program data between School systems and the national system. Turned on one data type at a time. Replaces Nintex.
Restart · partly built alreadyA written agreement on how shared data may be used — reporting and operations now, no fundraising prospecting without a separate network decision.
Unresolved · affects School trustCommon approach to handling inquiries and leads for group programs, so Schools can see where deals stall and compare performance meaningfully.
Underway · CoE-ledA shared enrollment capability, starting with group programs. Open enrollment already runs on the same underlying mechanism. The name Schools and EDs will recognize.
Largest build · 2027Recapturing open enrollment revenue currently lost when students cancel for reasons we can influence, and working waitlists more systematically.
Small · quick paybackBeing able to see when a student returns — a day program, then an expedition, then something longer. Mostly a reporting and data-completeness question once group data flows.
Grant commitmentBringing Schools without program tracking up to a workable minimum, and reusing what advanced Schools have already built instead of rebuilding it.
Gates the value of everything aboveFundraising systems and donor records. Genuine demand from School development leaders, and the most sensitive subject in the portfolio.
Decision gate, not a 2027 buildThe short descriptions above are deliberately compressed. This section gives each project a fuller definition so there is no ambiguity about what is being proposed, what it excludes, and what a School would actually notice.
| Project | Layer | Complexity | School effort | Status | Single-sentence goal |
|---|---|---|---|---|---|
| Data Standards & Baseline | 1 | Low | Medium | Not started | Agree the minimum every School records the same way |
| Data Governance | 1 | Medium | Low | Unresolved | Put permitted use of shared data in writing |
| Data Pipeline | 1 | High | Medium | Paused, partly built | Move group data between Schools and national on a repeatable template |
| Sales Activation | 2 | Medium | High | Underway | Common group sales approach with visible pipeline |
| Enrollment Platform | 2 | High | High | Scoping | A shared enrollment capability Schools adopt rather than rebuild |
| Waitlist & Cancellation | 2 | Low | Low | In prior scope | Retain enrollment revenue currently lost to cancellation |
| Repeat Participation | 3 | Medium | Medium | Not started | Report repeat participation to Lilly without caveats |
| School Baseline Parity | 3 | Medium | High | Not started | Bring every School to a workable minimum |
| Dashboards & Reporting | 3 | Low | Low | Not started | Network performance visible without manual assembly |
| Development / Donor | 3 | High | High | Held | A recommendation and a decision gate, not a build |
Complexity and School effort are planning estimates based on the August scoping session and prior platform experience, not figures stated in a source document.
Several projects need the same conversations, the same Schools, the same consultant and much of the same build. Budgeting them separately counts shared costs more than once and makes the total look larger than it is.
| Shared element | Projects that depend on it | What happens if built separately |
|---|---|---|
| School discovery conversations | Sales Activation · Enrollment Platform · Data Pipeline · Repeat Participation · Parity | Five separate requests reach the same one or two technical people at each School |
| Minimum field and stage definitions | Sales Activation · Enrollment Platform · Data Pipeline · Reporting | Rework, and data that cannot be combined across Schools |
| Group program data capture | Repeat Participation · Enrollment Platform · Reporting · Parity | Lilly reporting carries permanent caveats |
| The pipeline mechanism | Enrollment Platform · Repeat Participation · Reporting · Dashboards · future Donor | Continued Nintex spend on a tool that is not a long-term answer |
| Consultant and engineer availability | All technical projects | Scheduling collisions and paid-for capacity sitting idle |
| Change management with Schools | Sales Activation · Enrollment Platform · Governance · Parity | Change fatigue, and a sense that scope is expanding without consent |
The September 2026 Character Compass subgrant reports asked each School directly about tracking students across multiple program experiences. The answers fall into three groups. Network capabilities cannot produce felt impact until the lower group reaches a workable baseline, because combined reporting inherits the weakest inputs.
| Group | School | Stated position | What it means for the portfolio |
|---|---|---|---|
| Advanced | CSIOBS Cathleen Stone Island |
A Salesforce-based Participant Management Database tracks individual students across programs and years, including repeat participation and progression through pathways; focus is now on refining reporting | Strongest candidate source model for progression tracking |
| Advanced | OBCA Outward Bound California |
Salesforce reporting tracks participation across OBCA programs and progressive touchpoints; explicitly lacks visibility beyond its own School and has asked for a shared tracking tool | Clear demand signal for the network layer; extend rather than replace |
| Building | NYCOBS NYC Outward Bound Schools |
Salesforce restructure underway and being integrated with sales process work; still using spreadsheets for multiple touchpoints; has asked to see models from other Schools | Align now, while the build is still in progress |
| Building | POBS Philadelphia |
Working with RYTE and OBUSA on more efficient tracking; current process is a manual count | Local instance that another School has already built upon |
| Building | VOBS Voyageur |
Students identified in spreadsheets; no Salesforce tracking system yet; a task force is meeting monthly through year end to determine whether contract help is needed | Remediation candidate with internal momentum already formed |
| Blocked | COBS Colorado |
Tracking students across their engagement journey is not currently possible; has deferred its own Salesforce and advertising investments pending clarity on Center of Excellence scope | Our delay is directly suppressing School investment |
| Blocked | NCOBS North Carolina |
No significant progress beyond returning cohorts; states the primary need is the ability to connect student experiences in Salesforce, which it does not have | Direct dependency on the shared capability |
| Blocked | HIOBS Hurricane Island |
No analysis performed to date; expresses confidence in tracking within its own programs, with work planned for the autumn | Stated confidence may understate the work required |
| Blocked | CBOBS Chesapeake Bay |
Response centred on a research partnership rather than CRM capability; Salesforce position not established | Discovery needed before scoping |
Positions are drawn from the September 2026 subgrant reports covering all nine Schools. Group labels are an interpretive grouping for planning purposes. The two national Salesforce systems — OBUSA and OBSG — complete the count of eleven.
Several Schools have constructed versions of what the network needs. Philadelphia built a local Salesforce instance that Outward Bound California subsequently built upon. Hurricane Island has built sales pipeline functionality with support from the network engineer. Cathleen Stone Island built participant tracking that already answers the progression question. The practical question for 2027 is not whether to build an enrollment capability from nothing, but which existing build to harden, template and deploy.
The Hurricane Island attribution derives from a meeting transcript and is worth confirming directly before it is presented externally.
This is the part of the picture least visible in budget conversations. While the network-level work has been in planning, individual Schools have moved ahead on their own, at their own cost, on work that overlaps directly with what is proposed here. Two have asked whether OBUSA can contribute. A third has done the opposite and paused its spending while waiting for us.
| School | What they have done or are doing | Cost and funding position | What it means for this portfolio |
|---|---|---|---|
| CSIOBS | Runs group programs only, with no open enrollment. Uses Raiser's Edge for donor data and has been evaluating a migration to Salesforce, partly driven by the network move to a common donation platform. New development leadership is motivated to move fundraising into Salesforce. Already operates advanced participant tracking on the program side. | Estimated the migration at $30,000–$40,000 and formally asked whether OBUSA could assist with what it described as an unbudgeted expense | An explicit, documented funding request already on record. Also the strongest existing progression-tracking model in the network. |
| NYCOBS | Only overnight programming at one site is recorded in Salesforce today. Other outdoor programs collect course outcome surveys but the data is not entered; some climbing program forms are still on paper. Previously used Salesforce for both sales and fundraising before moving to separate tools. Has now contracted an external developer to upgrade Salesforce so programme and fundraising data sit in one architecture. Separately engaged an IT consultant on privacy and security. | Identified a developer at approximately $30,000 and proceeded after OBUSA indicated the School would be responsible for costs | Considerable further work is still needed on capturing all programme data, courses, enrollment and lead tracking. Alignment now avoids rework later. |
| COBS | Deferred planned Salesforce enhancements and related advertising investment while awaiting clarity on Center of Excellence scope | Spending withheld rather than committed | Demonstrates the cost of ambiguity: our planning delay is suppressing School investment |
Judged as a standalone project, the pipeline produces a modest saving. Judged as infrastructure, it changes what the organisation can do next. Most of the capabilities below only become available once there is a single connection point to network data.
Possible connections across 11 Salesforce systems — nine Schools plus two national orgs. Every new tool must be negotiated, built and maintained against each one separately. Processes become more error-prone and new technology gets slower to introduce.
Each system connects once to the national system, which holds the shared view. The website and the Customer Engagement Platform connect to the hub rather than to every School individually.
Vendor documentation prepared before the Northwest school closed describes twelve Salesforce systems. Current planning should use eleven.
| What it unlocks | What becomes possible | Who benefits |
|---|---|---|
| One connection point for future technology | New tools connect once to network data instead of being negotiated across every School. As technology changes, the cost of adopting or replacing a tool falls substantially. Some capabilities are only available to organisations that can offer a single connection point. | OBUSA and Schools — cheaper, faster adoption of whatever comes next |
| Self-serve dashboards | Enrollment, group, demographic and potentially course outcome reporting drawn from governed data rather than assembled by hand. Removes dependence on one person or team being available to produce network numbers. | Boards, Leadership Team, School leadership |
| Marketing tools for non-marketers | Salesforce flows and Campaign connections into Braze put basic marketing within reach of Schools that have no marketing staff, without specialist tooling at each location. | Schools without dedicated marketing capacity |
| Richer School records | A School's records can be enriched with network context — for example, a group student from one School who later enrolls in an open enrollment course elsewhere. | Schools — better customer knowledge and re-engagement |
| Retiring legacy tooling | Nintex is replaced rather than extended, ending its $15,000 annual fee. Once the pipeline is carrying data between systems directly, it also opens a path to retiring the CDP layer, currently around $50,000 a year. | OBUSA — direct cost reduction, with a larger second step available later |
| Room to innovate in ways not yet defined | Centralised, governed access is a precondition for capabilities the network has not yet identified. The value is real but cannot be estimated in advance. | The network — future optionality |
"Technical debt" here means the accumulated cost of systems that were built quickly, customized independently, and now have to be maintained separately. Retiring it was named in the original 2024 advisory objectives alongside consolidating and standardizing systems. Documentation from that work describes the architecture that addresses it, and records that substantial parts are already complete.
| Component | What it does | Recorded status |
|---|---|---|
| Centralized development | Functionality used across School systems is managed from one central configuration rather than maintained separately in each | Ready for deployment |
| Standard data model enforcement | A shared data model held in place by configuration, requiring matching definitions while still letting Schools add their own customization above it | Ready for deployment |
| Configurable collection and distribution | The mechanism for gathering School data centrally and sending governed data back out | Ready for deployment |
| Website integration with course data | Course information surfaced through the public site | Needs finalizing |
| CEP and Snowflake integration | Braze connected through Snowflake rather than School by School | Needs finalizing |
| Segment CDP receiving pipeline data | Unified profile data flowing from the national system | Needs finalizing |
| Project | Q4 2026 | Q1 2027 | Q2 2027 | Q3 2027 | Q4 2027 | 2028 |
|---|---|---|---|---|---|---|
| Unified School discovery | ||||||
| Data Standards & Baseline | ||||||
| Data Governance | ||||||
| School Baseline Parity | ||||||
| Sales Activation | ||||||
| Data Pipeline restart | ||||||
| Enrollment Platform | ||||||
| Repeat Participation | ||||||
| Dashboards & Reporting | ||||||
| Waitlist & Cancellation | ||||||
| Development / Donor |
Shaped by two anchors from the August scoping session: discovery completing through the end of 2026 with technical work sequenced across 2027, and an expectation that the group build takes roughly half the 14 months the original open enrollment platform required, because existing components are being extended rather than built from nothing. The Center of Excellence group sales roadmap runs on a compatible track, with network-wide reporting targeted for December 2027.
| Source | Amount | Year | Currently associated with |
|---|---|---|---|
| Salesforce Improvement Support | $200,000 | 2027 | Salesforce and sales journey work — automation, change management, School roadmaps |
| Sales & Salesforce consultant | $50,000 | 2027 | Consultant to drive the work |
| Lilly / Character Compass technology | $275,000 | Unspent | Data pipeline and related technology; none drawn to date |
| Group sales data & reporting | $35,000 | 2027 | Dashboards, pipeline visibility, forecasting |
| Total identified | $560,000 | 2027–28 | Across AAO and Lilly |
Earlier planning correspondence proposed moving pipeline implementation to 2027, reducing it to roughly $150,000, and reserving the remainder — about $125,000 — for supporting Schools directly. That split has not been confirmed, but it is the closest thing to an existing position on how much could go to School-level work, and it bears directly on the investment question in Section 06.
| Engagement | Amount | Duration | Note |
|---|---|---|---|
| Strategic advisory: foundational assessment | $28,000 | 8 weeks | Negotiated down from $36,400. System health scans, consolidation roadmap, technical debt strategy |
| System improvements | $164,200 | 15 weeks | Negotiated down from $189,400. Split across two fiscal years |
| Data pipeline and student experience — initial | $200,000 | — | Original proposal |
| Data pipeline and student experience — revised | $171,000 | 18 weeks | Reduced by shortening the timeline, with Nintex retirement added to scope. $9,500 per week |
Approximately $30,000 was subsequently carved out of the pipeline scope to make room for the network Salesforce engineer's time within the same grant funding.
The order below follows dependency logic rather than preference. Projects that prevent rework elsewhere come first, infrastructure follows, and the most sensitive work is deliberately held. Figures are planning allocations against identified funding, not approved budget lines.
| Tier | Project | Indicative | Likely source | Why here |
|---|---|---|---|---|
| 1 | Data Standards & Baseline | $25,000 | AAO consultant | Lowest cost, shortest duration, prevents rework everywhere else. A standard model already exists to build from |
| 1 | Data Governance | Staff time | — | Precondition for Schools sharing group data. Without it every other project carries a trust cost |
| 1 | Sales Activation | $200,000 | AAO / SF Improvement | Already underway, owned and budgeted; directly serves the sales enablement mandate |
| 2 | Data Pipeline restart | $175,000 | Lilly technology | Infrastructure for group data, Lilly reporting, dashboards and Nintex retirement. Known scope, known vendor, partly complete |
| 2 | School Baseline Parity | $50,000 | Lilly technology | Schools furthest behind cannot contribute usable data without help, which caps the value of everything above |
| 2 | Enrollment Platform | $75,000 | Lilly technology | Makes the infrastructure legible to Schools and EDs. Extends existing builds rather than starting over |
| 3 | Dashboards & Reporting | $35,000 | Group sales line | Low effort, high visibility. Produces the view that makes the whole portfolio legible to Boards and EDs |
| 3 | Repeat Participation | Within tier 2 | Lilly technology | Rides on pipeline and parity work; remaining cost is fixing gaps at Schools with incomplete data |
| 3 | Waitlist & Cancellation | Within tier 2 | Lilly technology | Already inside the prior pipeline scope; folding it in avoids a separate engagement |
| 4 | Development / Donor | $0 in 2027 | 2028 decision | Highest complexity and sensitivity. Conversation continues, decision point is published, nothing is built |
Indicative allocations total $560,000 against identified funding. They do not include any provision for the School investment question in Section 06, which would draw on the same pool.
The most likely failure here is not funding or technology. It is that one Center of Excellence role absorbs delivery, coordination, School engagement and vendor management at once, and the sales enablement mandate suffers. The consultant agreement adds to this by requiring a named internal lead committing at least half their time for the duration of the engagement. Five structural options are available, and they combine.
The consultant requires a named Product Owner with final say over what gets built in what order, committing at least half-time. If that is also the person responsible for sales enablement, School engagement and go-to-market work, the mandate cannot hold. A dedicated hire, a contracted role, or an existing staff member whose portfolio is reshaped would convert a full-time overload into a defined contribution.
Effect: removes the single largest time commitment from the CoE portfolio. Cost: a partial role, potentially fundable from grant personnel underspend.
The vendor model includes a delivery lead who manages schedule, anticipates risk, oversees resources and owns project communications, alongside a senior consultant providing oversight. Used as designed, internal coordination load drops substantially. The risk is paying for project management and then duplicating it internally out of habit.
Effect: moves sequencing and communications overhead outside the organisation. Cost: already included in engagement pricing.
Assign the shared infrastructure layer to a technology owner, the School-facing capability layer to the Center of Excellence, grant reporting to Learning and Evaluation, and the open enrollment components to Program Sales. Each owner holds one coherent domain rather than slices of several, and nobody is accountable for both building a capability and persuading Schools to adopt it.
Effect: reduces any one portfolio to roughly two or three projects. Cost: none, but requires deliberate assignment rather than default.
Standards and governance in the first half of 2027, group capability in the second, parity work running alongside as School-facing rather than build-facing activity. The roadmap already implies this; making it an explicit constraint stops scope arriving in parallel.
Effect: smooths peak load rather than reducing total load. Cost: a slower schedule, potentially extending into 2028.
Schools with advanced systems have offered to share what they built, and Schools building now have asked to see it. A small group of School-side power users, convened through the Center of Excellence and the business development forum, can carry peer coaching and much of the feedback gathering. This turns nine individual relationships into a facilitated group.
Effect: reduces one-to-one engagement load and improves adoption. Cost: modest convening and facilitation time.
| Role | Without structural change | With options applied |
|---|---|---|
| Center of Excellence | Product Owner, Sales Activation, Enrollment Platform, standards, reporting, School engagement, parity | Sales Activation and School-facing adoption, supported by a champion group |
| Dedicated Product Owner | Not assigned; responsibility defaults to the CoE | Named role holding backlog prioritization and the vendor relationship at half-time or more |
| Technology owner | Shared informally across several people | Pipeline, standards, architecture, dashboards, vendor scope |
| Learning & Evaluation | Consulted on Lilly requirements | Owns repeat participation reporting and the evaluation questions outright |
| Program Sales | Consulted | Owns waitlist and cancellation work; contributes prior platform knowledge |
| Consultant | Build execution | Build execution plus project management, sequencing and decision capture |
| Project | Manager | Owner | Consulted | Helper | Approver |
|---|---|---|---|---|---|
| Portfolio and roadmap | Mike Pigg | Ben Worden | Theresa, Meg, Katie, Mycah | DX Foundation | LT |
| Product Owner (vendor interface) | Ben Worden | To be named | Theresa, Meg, Katie | DX Foundation delivery lead | LT |
| Data Standards & Baseline | Ben Worden | Ben Worden | Theresa, Meg, Katie, School technical leads | Karen Zelevinsky, DX Foundation | LT |
| Data Governance | Mike Pigg | Ben Worden | Meg, Katie, EDs, Lach Zemp | Operations team | LT / Charter body |
| Sales Activation | Ben Worden | Theresa Salus | Meg, Sales, Marketing | CoE working group, champion group | Theresa Salus |
| Data Pipeline | Ben Worden | Ben Worden | Theresa, Katie, School technical leads | DX Foundation, Karen Zelevinsky | LT |
| School Baseline Parity | Ben Worden | Katie Dalbey | Theresa, Julia, School data leads | Karen Zelevinsky, RYTE | Katie Dalbey |
| Enrollment Platform | Ben Worden | Theresa Salus | Meg, Katie | DX Foundation, Karen Zelevinsky | Ben Worden |
| Repeat Participation | Mike Pigg | Katie Dalbey | Ben, Theresa, RYTE | DX Foundation, School data leads | Katie Dalbey |
| Dashboards & Reporting | Ben Worden | Ben Worden | Theresa, Meg, Katie, Finance | Marketing analytics, Karen Zelevinsky | LT |
| Waitlist & Cancellation | Ben Worden | Meg Peterson | Program Sales, customer success team | DX Foundation, Karen Zelevinsky | Meg Peterson |
| Development / Donor | Mike Pigg | Julia Farmer | Ben, School development leads | Karen Zelevinsky, Donately | LT |
| School investment position | Mike Pigg | Mycah Berryman | Ben, Katie, Julia, EDs | Finance | LT |
MOCHA ownership is distributed across six people rather than concentrated in one, consistent with the capacity options above. This is a starting proposal for the Leadership Team to confirm or revise.
A lesson from the earlier engagement: vendors should not enter School conversations before internal decisions are settled. Schools hear from OBUSA. The vendor receives a defined scope.
Owns the discovery questions, the School conversations, sales journey facilitation, change management and School-specific roadmaps. Runs one unified discovery rather than several. Schools should experience a single coordinated request from OBUSA, not parallel asks from separate projects.
Implements defined requirements: automations, objects, integrations, reports. Has built and advanced Salesforce across most of the network and already holds access across systems, which makes execution faster and cheaper than routing everything through the consultancy. Does not decide the business model, so the quality of what we specify remains our responsibility. Named in the knowledge transfer documentation as an expert on the pipeline architecture, and already supporting individual Schools directly.
The translation layer between business need and system design, which has been identified internally as a gap. Runs the delivery cycle, sequences work, maintains the decisions board and backlog, and hands suitable execution to the network engineer — a working relationship that already exists from prior engagements. Requires a named Product Owner committing at least half-time.
Holds the roadmap, the vendor relationships, the scope handed to the consultant, the cross-grant budget conversation and the governance question. Keeps vendors out of unstructured School conversations, and holds the value model, which spans enrollment, fundraising, technology cost and grant compliance.
Owns the Character Compass evaluation questions: what helps or hinders building a high-quality participant tracking system, and whether data quality improves as tracking improves. Confirms the build meets grant commitments and flags where School data gaps would undermine reporting. RYTE provides capacity-building support for the internally led evaluation.
Student data privacy has already been raised as a concern by at least one School, specifically around third-party access and obligations under its own agreements with a public school district. Any governance agreement and any third-party access arrangement needs this review built in rather than added afterwards.
Holds the earlier platform scope of work and discovery materials. The contribution is compressing the learning curve — the original build ran 14 months from a standing start, and the value is in not rediscovering what has already been paid for.
This is what moves the conversation from defending a budget line to weighing a portfolio against the revenue, capacity and savings it unlocks. The measures below are proposed methods; the baselines still need to be built.
| Project | How value is created | How to calculate it | Where it lands |
|---|---|---|---|
| Sales Activation | Better group conversion | Additional conversions × average group program value | School earned revenue |
| Enrollment Platform — groups | Staff time and conversion | Hours saved × loaded staff cost, plus additional bookings | School capacity and revenue |
| Enrollment Platform — OE | Higher fill rates | Additional filled places × average net revenue per student | Schools and OBUSA |
| Repeat Participation | Students returning | Additional repeat participants × average value of a subsequent enrollment | School revenue and grant compliance |
| Development / Donor | Donor retention and reactivation | Improvement in retention rate × average donor value | School contributed revenue |
| Data Pipeline — direct | Technology and labour saving | Retired licensing, starting with $15,000 annually for Nintex and potentially a further $50,000 for the CDP layer, less the cost of re-instrumenting, plus avoided integration and support hours | OBUSA and School technology cost |
| Data Pipeline — enabling | Cheaper future integration | Cost of connecting a tool once versus across every system, multiplied by expected future integrations | Network technology capacity |
| Dashboards & Reporting | Less manual reporting, less key-person risk | Staff hours currently spent assembling network reporting × loaded cost | OBUSA, Boards, School leadership |
| Marketing for non-marketers | Capability without headcount | Campaign activity enabled at Schools with no marketing staff | Schools with limited capacity |
| Data Standards & Baseline | Avoided build cost | Cost of independent School builds − cost of shared deployment. Recent School estimates for comparable work have run $30,000–$40,000 | School capital avoidance |
| School Baseline Parity | Unlocks value elsewhere | Share of network value currently unreachable because inputs are incomplete | The whole portfolio |
| Aligned programme and impact data | Access to funding | Grant dollars enabled or protected by shared reporting capability | Network funding |