What a Founding Institutional Partner Pilot Actually Involves

A founding pilot is paid work, agreed in writing

Here is the sentence some vendors save for the proposal call, and we would rather you read it first: a Founding Institutional Partner pilot is a paid, scoped commercial engagement. Scope, success measures, fees and conversion terms are agreed in writing before implementation begins. It is not a free trial. It is not an unlimited custom-development programme. It is a bounded piece of work with a written finish line, and money changes hands. No figure appears in this post or anywhere on our site, because the number depends on scope — but the fact of it should never be a surprise.

We put this first for a practical reason. ‘Founding partner’ and ‘help shape the roadmap’ can reasonably sound like a free or subsidised arrangement. A trustee who forms that impression and then discovers otherwise on the first call trusts everything else we say a little less — and a pilot runs on trust from its opening week. Discovering the commercial reality here, in a blog post, costs nothing. Discovering it in front of your board costs the relationship its footing.

The written agreement is also where the honesty runs in both directions. SquareCampus is a young company, and you should weigh that plainly rather than politely ignore it. The pilot structure exists because of that fact, not despite it: the scope is small, your current systems keep running, your data stays exportable throughout, and stopping at the end is a published outcome. Everything in the rest of this post is a protection you can hold us to on paper.

The pilot is deliberately small

A founding pilot solves one measurable operating bottleneck, on one campus or one agreed bundle of workflows, in 60–90 days. A bottleneck is simply a place where work piles up — fees that take days to reconcile, admissions enquiries that stall between offices, reports that contradict each other. The pilot picks one, not five. If the first conversation surfaces several problems worth solving, we still start with one, because one problem can be measured and five can only be discussed.

Small is not a limitation; it is the design. A pilot that spreads across the whole institution cannot finish inside a term, and a pilot that cannot finish cannot be judged. It quietly becomes a phased programme nobody agreed to, with a renewal conversation where a verdict should have been. Bounding the work is what makes the verdict possible — and the verdict, not the deployment, is the product of a pilot.

• One bottleneck: a single operating problem whose cost or delay can be observed today — not a general wish to digitise.
• One deployment: one campus, or one agreed workflow bundle. Not the whole institution at once.
• One window: 60–90 days, sequenced around admissions, fee deadlines, examinations and results rather than through them.
• One success measure: agreed in writing before implementation, so the closing conversation is about a number, not a feeling.
• No rip-and-replace: nothing your institution currently depends on is switched off to find out whether this works.

Someone senior has to own the outcome

Every founding pilot needs a named executive sponsor — a senior person inside the institution who owns the outcome as their own. A principal, a trustee, a director, a registrar, a group leader. Not a committee, and not the most junior person who could be spared. The sponsor is the answer to a simple question every pilot eventually asks: when this needs a decision, who makes it? If that question has no one-name answer on day one, it will be answered by delay on day forty.

The role is real work, though not heavy work. The sponsor convenes the people the workflow crosses, clears obstacles that staff cannot clear themselves, joins the weekly implementation reviews, and makes the convert, extend or stop decision at the end on the evidence. Where the sponsor’s authority is visible, staff treat the pilot as an institutional decision rather than an IT experiment happening to them — and that visibility does more for adoption than any feature.

If no one senior will put their name on the outcome, the honest reading is that the institution does not want the change yet. That is worth knowing before money and staff time are committed, not after. It is one of the questions we ask directly in the first conversation, and one of the grounds on which we will suggest not proceeding.

What founding status does not give you

Founding partner status carries real entitlements — a protected 40% discount on Enterprise commercial terms, white-labelled mobile apps without the standard white-label charge, a named implementation counterpart, defined influence on the roadmap. It is just as important to say what it does not create, because unspoken expectations surface at the worst possible moments. The list below is not small print; it is the same boundary published on the founding partner page at squarecampus.com/launch-partners/, and it applies to both Founding Partner positions equally.

Exact entitlements are governed by the proposal and the signed order form — not by this post, and not by anything said in a meeting. If a promise matters to your institution, ask for it in writing and expect to receive it in writing. That is the standard we recommend for every vendor evaluation, and we hold ourselves to it. A programme that trades on being honest cannot carry private side-arrangements that contradict the published one.

• No exclusivity: founding status does not prevent SquareCampus working with other institutions, including ones near you.
• No ownership of SquareCampus intellectual property: workflows built during the pilot remain part of the product.
• No veto over other customers, or over what the product becomes.
• No unlimited bespoke engineering: the innovation allocation is defined and bounded in the proposal.
• No guaranteed roadmap outcome: workflow proposals receive structured, written consideration — influence is real, command is not.

Who should not apply

The most useful thing we can publish about this programme is a list of institutions it will not serve well. Applying, being accepted, and then discovering mid-pilot that the fit was wrong costs a school far more than reading this section. If any of the following describes your institution today, a founding pilot is the wrong instrument — sometimes only for now, sometimes altogether. None of these are judgements about the institution; they are statements about what a pilot needs in order to work.

The mirror image is also true. An institution with a sponsor, a bottleneck it genuinely wants measured, and the capacity to take part in discovery and weekly reviews is exactly who the programme is for. There are two founding positions, one school and one university, and the programme closes when both are allocated — that is a statement about how the work is done, not a scarcity device, and you will not find a countdown anywhere on our site. The full programme, including the questions boards ask before saying yes, is on the founding partner page.

• No executive sponsor: if no principal, trustee, director, registrar or group leader will own the outcome, the pilot will drift no matter how good the software is.
• No measurable bottleneck: ‘we should digitise’ is a mood, not a problem. A pilot needs a workflow whose cost or delay can be observed today.
• No capacity during the term: if the coming 60–90 days hold a leadership transition, an inspection or an accreditation cycle, wait. A pilot competing for attention loses.
• Wanting a cheaper attendance app: good, inexpensive point tools exist, and we will say so. An institutional decision layer is the wrong purchase for that need.
• Wanting a free trial or unlimited custom development: the programme is neither, and no conversation will make it either.

Universities and multi-school groups take a different route

A private university or a multi-campus higher-education group is a different conversation, with its own page at squarecampus.com/launch-partners/higher-education/. The evidence model is identical — one bounded scope, one written baseline, one named sponsor, 60–90 days, then convert, extend or stop. But the wedge is usually different. Universities rarely lack software; they lose weeks in the gaps between systems that already exist. A pilot there typically governs an exception queue: a list of cases that fell between two systems — an admission that cleared one stage and stalled at the next, a payment that succeeded at the gateway but never matched the record — each with a named owner and a current position.

One boundary is worth stating even in a school-focused post: clinical and hospital information systems are outside the suggested pilot scope. Where an institution operates a teaching hospital, a pilot is scoped to non-clinical administrative workflows only, and SquareCampus makes no medical, patient-care, accreditation or regulatory claim. A wedge that touches patient care is not a wedge; it is a liability, and we will decline it. Naming that boundary up front protects the conversation more than silence would.

However you arrive — school, trust, group or university — the first step is the same and costs nothing: a 30-minute institutional diagnosis. Bring one bottleneck. Tell us where visibility arrives late, where ownership goes unclear, where staff rebuild the same truth by hand. We will tell you honestly whether it belongs in a founding pilot, and ‘not this, not yet’ is an answer we actually give. It is a strange way to market a programme. It is the only way to run this one.