--- title: "Founding Partners for Higher Education | SquareCampus" description: "A governed operating layer that runs alongside a university's existing ERP, LMS, payment and identity systems. One bounded workflow, a written baseline and a 60–90 day evidence model." canonical: https://squarecampus.com/launch-partners/higher-education/ describedby: https://squarecampus.com/llms.txt --- Founding institutional partners · Higher education # Your systems are not the problem. The space between them is. Private universities and multi-school groups rarely lack software. They run an ERP, an LMS, one or more payment portals, an identity provider and several communication channels — and lose weeks in the gaps between them, where a case is stalled, unowned, and visible to nobody until someone escalates. SquareCampus is the governed layer across that space. [Request a partnership diagnosis](https://squarecampus.com/demo/?intent=founding-partner) See where a pilot starts Runs alongside your existing ERP, LMS, payment and identity systems · One bounded workflow · Paid, scoped pilot The 60–90 day evidence model One bounded workflow, a written baseline, and a decision taken against evidence. **Scope** One workflow or one non-clinical department **Window** 60–90 days **Sponsor** One named executive owner **Close** Convert, extend or stop What this is, precisely ## Not a university ERP. A governed operating layer over the one you have. It is worth being exact about this before anything else, because the wrong expectation wastes both sides' time. What it is not - Not a replacement for your student information system or ERP of record - Not a learning management system, and not a competitor to the one you run - Not a payment gateway, an identity provider, or a finance ledger - Not a clinical, hospital or patient-care system, and not proposed for one What it is - A governed layer that watches the workflow across those systems - An exception queue with a named owner and a due position for every open case - An append-only record of who decided what, when, and on what basis - A leadership view of a bounded operational workflow that is current without an export Where a pilot starts ## Five wedges that produce evidence inside one term. Each one is bounded, already measurable today, and does not require switching off anything the institution depends on. ### Admissions-to-enrolment exception ownership Applications that clear one stage and stall at the next — document verification, fee confirmation, seat allocation, registration. The exception gets an owner and a position instead of living in an inbox. ### Payment-success-to-ERP reconciliation Payments that succeed at the gateway and do not land cleanly against the record. The mismatch is raised as an exception, routed, and closed with a recorded reason rather than reconciled by hand at month end. ### Interdepartmental approvals and stalled cases Requests that cross academic, finance, registry and administrative boundaries and lose their owner at each handover. Latency becomes visible while it is still recoverable. ### Leadership visibility across one bounded workflow A current view of one workflow — what is open, who owns it, what is overdue and what was decided — without a department preparing a deck for it. ### Evidence collection and accountable closure Administrative and operational workflows outside clinical and hospital systems, where a decision needs a recorded reason and an auditable close. Explicitly out of scope Clinical and hospital information systems are outside the suggested pilot scope. Where an institution operates a teaching hospital, the pilot is scoped to non-clinical administrative workflows only, and SquareCampus makes no medical, patient-care, accreditation or regulatory claim. How it sits ## Above or alongside. Nothing is switched off to find out whether this works. During the pilot the institution's ERP, LMS, payment portals, forms and identity provider stay exactly where they are and stay authoritative. SquareCampus governs the workflow that runs across them. ### Systems of record stay in place The ERP or SIS remains the record. SquareCampus does not ask to become it, and does not require a migration to start. ### The workflow is governed across them A case is tracked from the event that starts it to the decision that closes it, regardless of how many systems it touches on the way. ### Ownership is explicit, not implied Every open exception has a named accountable owner and a position. Nothing sits in a shared mailbox waiting to be noticed. ### The decision is recorded Approvals, overrides and refusals land on an append-only timeline with the reason attached, scoped to the role that took them. A later rollout may replace selected fragmented tools, when and if the institution decides to. That is a separate decision, taken after the evidence exists — never a precondition of the pilot. The 60–90 day evidence model ## The same discipline as every founding pilot, scoped to a university. The same sequencing, migration discipline and parallel validation described on the rollout page, scoped to one university workflow. ### One bounded scope One workflow, or one non-clinical constituent school or department. Not the institution, and not a phased programme dressed up as a pilot. ### One written baseline The current position — volumes, delays, ownership gaps — written down before implementation, so the result is measured rather than argued. ### One named executive sponsor A Registrar, Dean, Finance lead, COO or CIO who owns the outcome internally and can convene the people the workflow crosses. ### Parallel validation where needed Anything finance or registry teams must trust runs alongside the existing process until the numbers agree. ### Convert, extend or stop Judged against the measure agreed at the start. Stopping is a published outcome, not a failure state we argue you out of. Paid, scoped engagement Founding pilots are paid, scoped commercial engagements. Scope, success measures, fees and conversion terms are agreed in writing before implementation begins. [How the licence is composed](https://squarecampus.com/pricing/) and [how a rollout runs](https://squarecampus.com/rollout/). Who this has to convince ## Five people, five different questions. A pilot at a university needs several people to agree. They are not agreeing to the same thing. President / Vice Chancellor ### What does this change at my level? One bounded workflow stops arriving as an escalation and starts arriving as a current position. The pilot is small enough to stop and specific enough to judge. Registrar ### Does this add another system for my office to run? It governs the ones you already run. The registry keeps its system of record; what changes is that a stalled case has an owner and a position instead of a follow-up email. Dean / Academic leader ### Will this reach into academic judgement? No. The scope is administrative and operational workflow — where a case is, who owns it, and whether a decision was recorded. Academic decisions stay with the people who make them. Finance leader ### What happens to reconciliation? Mismatches between payment success and the record become routed exceptions with a recorded closure, and run in parallel with the existing process until finance trusts the numbers. CIO / IT leader ### What is the integration and data burden? Scoped to the workflow in the pilot, agreed in writing before implementation, and read-oriented where the existing system stays authoritative. Access is role-scoped and exports are available in standard formats throughout. One position ## One university Founding Institutional Partner position exists. There are exactly two Founding Institutional Partner positions, ever: one school or eligible school institution, and one university. Once both positions are allocated, the programme closes permanently. A Founding Institutional Partner is not an ordinary customer. The position involves a strategic capital commitment under a separately executed agreement, material participation in product validation, and structured roadmap input. **Defined roadmap influence** Structured, written consideration of the partner's operating requirements in roadmap planning, as defined in the executed agreement. **Protected 40% Enterprise discount** A protected 40% discount on Enterprise commercial terms, as set out in the executed agreement. **White-labelled mobile apps** The SquareCampus parent and staff apps published under the institution's own branding and store listings, without the standard white-label charge. **Other agreed founding privileges** Any further privileges are those explicitly agreed in the executed agreement, and no others. The first conversation ## Bring one bottleneck. We will map the governed path around it. A 30-minute diagnosis of one workflow: where it stalls, who should own it, what a bounded pilot would cover, and whether the university Founding Partner position is the right fit at all. No commitment · 30-minute institutional diagnosis [Request a partnership diagnosis](https://squarecampus.com/demo/?intent=founding-partner) · [The full founding partner programme](https://squarecampus.com/launch-partners/) · [Review the trust posture](https://squarecampus.com/security/)