Managed Services
The Salesforce team most institutions cannot staff.
A Salesforce org needs steady hands long after go-live — an administrator, a developer, an architect. Few institutions can justify that as permanent headcount for one platform. We stay on as that team: named people who keep your institutional context, not a rotating support queue.
The standing work
What an org needs every year.
A live Salesforce org is not a finished project. Four kinds of work recur on a calendar of their own, whether anyone is assigned to them or not.
- Release readiness
- Salesforce releases three times a year, on its calendar rather than yours. Readiness work happens before each one reaches your users.
- Enhancement backlog
- Requests scoped, sequenced and worked steadily in one backlog — improvements ship in order, not in bursts.
- Governance
- Who can change what, how a change is decided, and a record of why — so the org five years from now is still explicable.
- Administration
- Users, permissions, data quality and the daily questions. Some clients staff this themselves; others hand it to us entirely.
The shape of an engagement follows the org, and we will be specific about it in the first conversation.
Continuity
A named team that keeps your context.
The people who answer are the people who know your org — how your terms are configured, which integration is brittle, why that validation rule exists. That knowledge is institutional context, and it is retained the only way it can be: the same named people, engagement after engagement.
Three releases a year is a schedule, not a surprise.
Salesforce ships them whether an institution is ready or not. Release readiness is standing work on a known calendar — reviewed before each release lands, so it is something your team reads about rather than recovers from.
Coverage
The whole platform, not one corner of it.
Institutions rarely run a single cloud. One team covers the platform your institution actually has.
- Education Cloud
- The student record and the data model beneath it — including EDA, below.
- Sales and Service
- Recruitment pipelines and the service console — cases, queues, and the inbox behind them.
- Data Cloud
- Records unified across sources into one profile of the student.
- Commerce Cloud
- Commerce and payment experiences running against the same record.
- Marketing Cloud
- Journeys, segmentation, and the communication history kept where every office can see it.
- Tableau
- Reporting and analytics drawn from the record rather than exported from it.
EDA and HEDA
Still on the Education Data Architecture? Someone has to hold it.
EDA — the Education Data Architecture, called HEDA, the Higher Education Data Architecture, for most of its life — is now the legacy package: new implementations are built on Education Cloud. An institution still running EDA needs people who know that architecture and will keep it healthy through every release. We run both data models in production among our clients, so we hold EDA orgs as they are — and know the ground on both sides if a move ever becomes the right call.
Start here
Bring the org you already have.
Whether we built it or are meeting it for the first time, the first conversation is the same: what runs, what hurts, and what the next release will touch. Bring whoever holds the admin password today.