Bellevue 10X
A 90-day technology turnaround strategy to protect instructional capacity, reduce administrative friction, improve student throughput, and build a stronger evidence system for program decisions.
Conclusions first
Bellevue College should exhaust measurable technology-enabled revenue growth, process improvement, and program-redesign options before sacrificing instructional capacity.
- The opportunity is large enough to justify immediate testing. A preliminary scenario model identifies approximately $3.3M–$8.8M in potential recurring net annual institutional value. The midpoint/base scenario is $5.7M. These are testable estimates—not audited savings—and should be replaced with Bellevue internal operating data during the first 30 days.
- Bellevue’s own public record suggests the problem is not simply “too few students.” Spring 2026 headcount rose year over year, annual FTE was almost exactly on forecast, and stronger-than-expected Running Start revenue improved the year-end financial outlook even while budget reductions were underway.
- The first technology target should be institutional friction, not faculty headcount. Status chasing, duplicate entry, scheduling mismatch, unresolved student cases, procurement delay, grant discovery, reporting overhead, and fragmented decision data are all measurable before deeper academic reductions are considered.
- Program decisions need a futures simulator, not a closure spreadsheet. Before any reduction, the college should model growth, redesign, modality change, cross-listing, shared delivery, employer underwriting, credential conversion, consolidation, and only then reduction or closure.
- The 90-day effort should be jointly governed. Faculty, classified staff, student services, ITS, students, and administration should participate from Day 1. Fast prototyping should begin with aggregate, synthetic, or de-identified data; production student data enters only through approved security and privacy controls.
- If Bellevue proves the model locally, modernization itself can become an asset. Shared services, grant-funded implementations, statewide collaboration, employer-supported modules, and reusable public-college software could extend the return well beyond Bellevue.
Important: “Institutional value” combines categories that must remain separate in financial reporting: cash savings, avoided cost, recovered capacity, new revenue, and external funding. The model below keeps those categories explicit and is designed for validation, not promotion.
1. Why this is a technology opportunity
Public Bellevue College records show both strength and strain. In spring 2026, headcount reached 14,819 students, up 606 from spring 2025, while annual FTE was reported at 12,037 against a 12,047 forecast. Bellevue also reported a stronger year-end financial position than previously expected, helped by Running Start performance and budget-reduction measures already taken.
At the same time, faculty, staff, students, and governance bodies raised concerns about the clarity, data quality, consultation, and timing of the program-viability process. By May, the administration had acknowledged that the earlier process did not yield all of the information needed for informed decisions and committed to a revised process and metrics.
That combination matters: Bellevue is not starting from an absence of demand. It is operating under financial pressure while also trying to improve the quality of institutional decision-making. Better information systems can attack both problems at once.
2. Preliminary economic model
This model is deliberately transparent. It does not claim that Bellevue has already realized these amounts. Each line is a hypothesis that can be accepted, reduced, or rejected after Bellevue supplies actual operating data.
| Value pool | Low | Base | High | Financial category | Validation data |
|---|---|---|---|---|---|
| Administrative workflow automation | $0.8M | $1.4M | $2.2M | Recovered capacity / avoided cost / possible cash | Workflow volumes, cycle time, staffing, loaded labor cost, overtime, vacancies |
| Retention + enrollment recovery | $0.9M | $1.5M | $2.4M | New / protected revenue | Stop-out causes, yield, registration losses, aid delays, tuition/FTE economics |
| Course scheduling + section optimization | $0.7M | $1.1M | $1.6M | New revenue / avoided instructional inefficiency | Fill rates, waitlists, cancellations, modality, section cost, unmet demand |
| Grants, sponsorships + employer partnerships | $0.8M | $1.3M | $1.8M | External funding / restricted revenue | Historical submissions, win rate, eligible programs, sponsor pipeline |
| Procurement + shared-service efficiency | $0.5M | $0.7M | $1.0M | Cash saving / avoided cost | Vendor spend, contract duplication, purchase cycle time, exceptions |
| Microcredentials + continuing education pilots | $0.3M | $0.6M | $1.0M | New revenue | Price, cohort size, delivery cost, employer demand, contribution margin |
| Gross annual value hypothesis | $4.0M | $6.6M | $10.0M | ||
| Ongoing product / security / analytics / cloud cost | ($0.7M) | ($0.9M) | ($1.2M) | Operating expense | Actual architecture and staffing plan |
| Recurring net annual value hypothesis | $3.3M | $5.7M | $8.8M |
Three-year scenario
A base-case three-year model can exceed $17M in cumulative net institutional value if benefits ramp successfully and the recurring operating model remains near the estimated range. That figure is a scenario output, not a forecast. The first 30 days should build a Bellevue-specific model from actual data and either validate or replace it.
3. Bellevue Pulse: a live institutional nervous system
Each academic program should have a live operating view: enrollment, FTE, fill, waitlists, cost structure, completion, prerequisite dependencies, shared courses, modality, transfer role, employer demand, grants, community partnerships, and historic trends.
The system must preserve context. Faculty can explain why a low-enrollment course is essential to three other programs. Student services can flag prerequisite or aid bottlenecks. Deans can identify accreditation or employer dependencies. AI can identify anomalies and assemble evidence; accountable humans decide what those facts mean.
4. Program Futures Simulator
Before an academic reduction becomes a recommendation, test alternatives. The simulator should answer:
- What happens to students and completion timelines if this program changes?
- Which other programs depend on its courses or faculty?
- What revenue is lost as well as what cost is removed?
- Could scheduling, modality, cross-listing, shared administration, or alternating-quarter delivery improve the economics?
- Could an employer, grant, foundation, or community partnership underwrite part of the program?
- Could the program become a certificate, microcredential, continuing-education offering, or shared regional program?
- What happens under growth, redesign, consolidation, reduction, and closure scenarios?
Rule: reduction is one scenario in the model, not the premise of the model.
5. Student Case: make unresolved problems visible
High-impact student problems should become trackable cases with an owner, dependency chain, service target, and escalation path. Students should not have to learn Bellevue's internal organizational structure by being sent from office to office.
| Case | Financial-aid review blocking another student process |
|---|---|
| Owner | Named responsible unit |
| Dependency | Visible upstream task |
| Student action | Required / not required |
| Clock | Time since last substantive action |
| Escalation | Rules based on severity and elapsed business days |
Aggregate data from these cases then becomes operational intelligence: which process fails most often, where students wait longest, what issues correlate with stop-out, and what office-to-office handoffs create the most friction.
6. Course-demand sensing
Before schedules become fixed, students should be able to signal degree-critical demand, preferred modality, and scheduling constraints. The system then combines intended demand with historic registration and program requirements.
A scheduler should be able to see a decision in economic and student terms: existing capacity, registered seats, waitlist, unserved degree-critical demand, estimated incremental section cost, potential tuition/FTE value, and likely effect on time-to-completion.
7. Opportunity Engine
Every program should have a machine-assisted pipeline for grants, workforce funds, sponsored credentials, employer partnerships, equipment donations, apprenticeships, research collaborations, and foundation opportunities.
The strategic question becomes: What does the program cost, what public value does it create, and what outside capital can it attract?
8. 30-day program turnaround experiments
Programs with recoverable demand should be allowed to test their assumptions rapidly before irreversible decisions. Experiments can include employer commitments, revised modality, direct prospective-student outreach, alumni campaigns, new certificates, community partnerships, Running Start pathways, and targeted recruitment.
The standard should be measurable evidence: leads generated, employer commitments, applications, deposits or registrations, contribution margin, and time-to-launch.
9. How Bellevue can ship fast without bypassing governance
Fast does not mean uncontrolled. Bellevue's own Information and Data Security policy requires protection of confidentiality, integrity, and availability and explicitly aligns college security practices with WaTech. Bellevue's IT Security Office states that it is responsible for regulatory and security compliance, including FERPA and WaTech requirements. Bellevue's FERPA procedures protect student education records, while WaTech application-security standards require risk assessment for new applications and vulnerability management before production deployment.
| Stage | What can move fast | Control |
|---|---|---|
| Prototype | Synthetic, public, aggregate, or de-identified data; mock APIs; workflow maps | No production student-record access required |
| Pilot | Read-only approved datasets and narrow user groups | ITS security review, least privilege, logging, documented data purpose |
| Production | Approved systems and integrations | FERPA, WaTech-aligned controls, accessibility, retention, risk assessment, vulnerability remediation |
| Decision use | Dashboards, simulations, recommendations | Named human decision owner; no autonomous academic or financial-aid decisions |
Shared-governance design
The implementation lab should have representation from faculty, classified staff, student-facing operations, ITS/security, institutional research, students, and administration. Where collective-bargaining subjects are implicated, the college should use the existing labor process rather than treating a technology pilot as a way around it.
This is especially important because Bellevue's own 2026 Board record documents faculty and governance concern about data, consultation, and the program-viability process. The technology program should be presented as infrastructure for better shared evidence—not as a substitute for shared governance.
10. The joint implementation lab
Create a small cross-functional team with authority to build approved prototypes and measure results. Students can participate in bounded, supervised work using synthetic, de-identified, aggregate, or specifically authorized data. Production privileges remain with authorized personnel.
Possible contributions: IT students build test interfaces; cybersecurity students conduct scoped testing in approved environments; business students model adoption and unit economics; design students improve accessibility and usability; accounting students validate cost logic; communication students test messaging; faculty supervise domain quality.
11. The 90-day sequence
| Period | Work | Evidence gate |
|---|---|---|
| Days 1–10 | Appoint joint team; choose 3 student workflows and 5 program cases; define economic ledger; inventory data; establish security/privacy boundaries. | Named owners, baselines, approved data classes, success metrics. |
| Days 11–30 | Build Student Case prototype, aggregate course-demand model, first program economics dashboard, and administrative-friction map. | Real workflow timings; verified data; no claim of savings without baseline. |
| Days 31–60 | Run Program Futures simulations; launch Opportunity Engine; automate one or two low-risk workflows; pilot demand forecasting. | At least one decision improved and one measurable cycle-time reduction. |
| Days 61–90 | Scale successful pilots; stop weak ones; validate financial model; launch program turnaround experiments. | Auditable value ledger and decision on Phase II. |
12. Value accounting: never call everything “savings”
| Category | Definition | Example | CFO treatment |
|---|---|---|---|
| Cash saving | Expense actually removed | Eliminated duplicate software contract | Budget reduction |
| Avoided cost | Future spending no longer required | Avoided new position because workload fell | Future budget avoidance |
| Recovered capacity | Paid time redirected to higher-value work | Staff spend fewer hours routing forms | Operational productivity, not cash unless converted |
| New revenue | Incremental tuition or program receipts | New employer-backed certificate | Revenue net of delivery cost |
| External funding | Restricted or unrestricted outside funding | Grant or sponsorship | Tracked by funding terms |
13. Economic-model appendix
| Hypothesis | Formula | Required Bellevue inputs | Current confidence |
|---|---|---|---|
| Workflow automation | Volume × minutes saved × loaded labor rate × realizable factor | Case volume, task time, staffing cost, vacancy/overtime data | Low until measured |
| Retention recovery | Incremental retained students × net tuition/FTE contribution | Stop-out attribution, tuition mix, state allocation mechanics, marginal cost | Low–medium |
| Section optimization | Incremental enrollments × net contribution − incremental instruction cost | Waitlists, fill rates, course criticality, faculty cost, modality | Medium if data available |
| Grant engine | Qualified pipeline × submission rate × win rate × average net award | Historic applications, wins, proposal staffing, allowable indirects | Low until baseline |
| Procurement efficiency | Addressable spend × validated savings rate | Vendor ledger, contracts, categories, renewals | Low–medium |
| New credentials | Participants × price / funding value − direct delivery cost | Demand, tuition/fee rules, instructor cost, marketing, space | Low until pilots |
14. What would justify Phase II
The 90-day effort should continue only if the evidence supports it. Suggested gates:
- At least two high-volume workflows show a verified cycle-time reduction of 25% or more.
- At least one student-service pilot shows a measurable reduction in unresolved cases or handoff delay.
- The Program Futures Simulator identifies at least one viable alternative to a simple cut, or demonstrates why an alternative is not economically credible.
- The Opportunity Engine produces a qualified, owner-assigned external-funding pipeline.
- The CFO/finance team accepts the value-accounting methodology.
- ITS/security accepts the architecture for any expansion beyond aggregate/de-identified pilots.
15. Research foundation
- Bellevue College Board of Trustees — May 27, 2026. Enrollment, budget outlook, faculty statements on program cuts, and administration acknowledgment that the then-current program-viability process did not yield sufficient information for informed decisions. Primary source.
- Bellevue College Board of Trustees — March 18, 2026. Documented concerns regarding data, clarity, consultation, timing, student impact, and potential program changes. Primary source.
- Bellevue College Board of Trustees — June 24, 2026. 2026–27 budget action and closed-session collective bargaining context. Primary source.
- Bellevue College Policy 5250 — Information and Data Security. Requires information-security controls and alignment with WaTech policies; places oversight responsibility with the ITS vice president. Primary source.
- Bellevue College IT Security. States responsibility for protecting digital assets and compliance with requirements including FERPA and WaTech. Primary source.
- Bellevue College Procedure 2600P — FERPA. Establishes college procedures for protecting education records and personally identifiable information. Primary source.
- WaTech Application Security Standard. Requires risk assessment for new applications and controls around vulnerabilities and secure development. Primary source.
16. External fact-check ledger
| Claim | Status | External reviewer should test |
|---|---|---|
| Spring 2026 enrollment and FTE figures | Sourced fact | Board materials and institutional enrollment report. |
| Program-viability concerns and administration response | Sourced fact / attributed positions | March and May Board records. |
| Security / FERPA / WaTech constraints | Sourced fact | BC Policies 5250 and 2600P; WaTech application-security standard. |
| $3.3M–$8.8M recurring net value | Scenario hypothesis | Rebuild from Bellevue operational and financial data. |
| $5.7M base case | Scenario hypothesis | Test each component independently; do not assume all benefits are cashable. |
| $17M+ three-year scenario | Derived scenario | Validate ramp rate, implementation cost, recurring cost, benefit persistence, and double counting. |
| Digital twin / case management / demand sensing outcomes | Testable product hypotheses | Run 30–90 day controlled pilots against pre-defined baselines. |
The proposal is not “trust the model.” The proposal is “give Bellevue 90 days to measure whether the model is real.” If the opportunity is smaller, the evidence will show it. If it is several million dollars, Bellevue will have found a way to protect institutional capacity by improving the operating system before removing more of the institution itself.