Every renewal depended on a contract nobody could see, because the program and its emails lived on different records.
A US education company sells learning products to colleges and universities, with renewals every semester or every year. It wanted Attio as its customer success workspace, and to retire the spreadsheet-style tracker where renewals were kept by hand. A free audit found why that was impossible as the workspace stood. We are now rebuilding it around the program, not the institution. Phase 1 is in progress.
Audit, then paid build
Engagement
Phase 1 in progress
Status
79
Programs migrated
11
Workflows live
6
Dashboard reports
The problem.
The company sells to colleges and universities. A client is not really the university. It is one department or program inside it, with its own faculty champion, budget holder, contract and renewal date. Some renew every semester, some every year, each on their own start date and payment model.
In Attio, institutions and programs were stacked in the same Companies object. A program field on the institution could hold only one value, so a university with six programs showed one link. Fifteen programs belonged to no institution at all.
Every program record had zero interaction history. Email domains sit on the university, so the conversations were on one record and the contract data on another. No health score could be worked out from that.
There was no money field anywhere, and no way to tell a renewed program from a churned one. More than half of the programs with a date were already past the end of their coverage. That is why the renewal tracker outside Attio could not be retired.
Mail sync had filled the workspace with about 4,500 people, most created automatically and many with no name. There were no workflows, reports or tasks.
Objectives.
- Split programs from institutions, and put every conversation and contract on the record it belongs to.
- Run renewals as a pipeline, one record per renewal cycle, with outreach at the right time for each contract type.
- Hold what each program bought and at what price, so the outside tracker can be retired.
- Give every program a health score built from the team's own three inputs.
- Change nothing without written approval, and back everything up before the first change.
The data model.
Seven objects in all. The institution stays on Companies. Everything the customer success team works on hangs off the program.
Companies
The institution only. Six duplicate institutions created by mail sync were merged, keeping both domains on each survivor.
Programs
The actual client: one department or program at an institution, with its client code, key contacts, terms deployed and health score.
Agreements
Every signed document for a program, with its type, cadence, terms and auto-renew.
Purchases
One product at one price on an agreement, with the payment model for that product.
Student-pay terms
For programs where students pay, a forecast against actual for each term.
Renewals
The standard Deals object, turned on and renamed. One record per renewal cycle: Upcoming, Outreach sent, Change order out, then Won, Lapsed or Churned.
What is built so far.
The migration
79 programs moved off the institution records onto their own object, every one linked to an institution. 79 renewals seeded, one per program. 298 people placed on a program contacts list with their role, one entry per person per program.
Workflows
Eleven live. Outreach tasks at 60 days for annual contracts and 30 for semester ones, with escalations after that. A won renewal creates the next one 4 or 12 months out. Signed agreements update the program. Institution and program copy down onto every child record.
Health score
Three inputs the team already used: product usage, decision-maker strength and partner sentiment, each scored 1 to 3. The average puts each program in Healthy, Watch or At risk.
A renewals dashboard
Six reports: upcoming renewals by term, change orders not signed, agreement totals, student-pay forecast against actual, renewal outcomes by term, and the spread of health scores.
How the work is run.
Backup before anything
A full export of both objects and both lists went to the client before the first change. Nothing in the workspace was touched until the data model was approved in writing.
Every deletion approved
More than a hundred junk people were deleted, one approved batch, after their own CSV export. The rest of the nameless contacts are a review list, never a mass delete.
Scripts that can rerun
The migration runs from scripts that track every record they create, so a rerun never makes a duplicate.
Still to come.
Phase 1 is not finished. The survey tool, the document-signing tool and the accounting sync each need the client to connect their own account first, and the matching workflows go live after that. Deal values and starting terms on the renewals are still being filled in by the client's team. A runbook and a sample check against the source export close out the phase.
Results.
- Programs and institutions on separate records for the first time, so each program has its own contacts, contracts and renewals.
- A renewals pipeline seeded for every program, with outreach and the next renewal created automatically.
- A health score and a six-report renewals dashboard, built on the team's own definitions.
- Everything done so far is backed up, approved in writing, and repeatable from scripts.
Ready when you are.
Book a call and we will tell you honestly whether this is worth doing, or start with the free 48-hour audit and decide afterwards.