Three practical pieces for a committee that rarely meets. First, how the service crosswalk and the usage baseline get gathered with the least possible work from each college, by having the AI-agent walkthrough draft the first pass so owners only correct their own row. Second, an async subcommittee plan that breaks the work into small, ownable chunks so people contribute without sitting in meetings. Third, a ready-to-send letter a committee member can drop to a college service owner today, asking for just two things and collecting no student data.
The crosswalk needs two things from each college for each service: what that college actually calls the service (its local name), and roughly how many students it serves in a year. That is the whole ask. One contact, the service owner, answers just those two questions for their own service. No long survey, no student-level reporting, no audit.
The AI-agent walkthrough already reads each college’s public site and auto-drafts a first-pass crosswalk row for every service. So when an owner opens the intake, their row is mostly filled in already. They are not building a grid from scratch, they are checking one row, fixing the local name if we got it wrong, and adding the rough annual number. That turns an hour of work into a few minutes, which is the only reason a busy advising or financial-aid office will actually do it.
The AI-agent walkthrough reads the college’s public site and seeds a first-draft local name for each service. The owner starts from a filled-in row, not a blank one.
The owner confirms or fixes their local service name, and adds an approximate students-served-per-year figure. Two fields, a few minutes.
Each verified row completes that college’s column in the crosswalk, college by college, until the grid is owner-confirmed rather than draft.
The annual headcounts become the “before” number: the baseline that future AI improvements get measured against. No PII, just an approximate count.
So one short intake produces both deliverables at once. The corrected local names give us the verified crosswalk. The rough annual numbers give us the usage baseline, the starting point we measure any AI improvement against later. Both come from the same two-field reply, which is why the ask stays small.
The point of gathering usage now, in Phase 1, is to set up a pre/post impact evaluation. For each service we capture two things: how many students use it today (the per-service count, which comes from the department because Institutional Research does not hold it) and the college’s total enrollment (public, from IPEDS and the college fact books). Together those are the baseline. Then, about a year after the AI tools and processes launch, we re-take the same measures at the same services to see whether more students are reaching them. If the after-number is higher, the tools are doing their job. The whole loop stays inside the no-student-data line: counts and aggregates only, no PII.
The intake never asks for names, records, or anything that identifies a student. The only number we want is roughly how many students the service serves in a year, a planning figure the office already knows or can estimate. An approximate count is fine. If an office cannot share a number, the local-name correction alone is still useful.
Domain 5 has about 10 members, many of them advisors, financial-aid specialists, and other support staff with full day jobs. The committee rarely gets everyone in a room. So the work is split into a few small subcommittees, each with one clear lead and a first deliverable small enough to finish without a single coordinating meeting. People contribute asynchronously, in chunks they own, on their own time. The point is to make progress between meetings, not to depend on them.
Every subcommittee is staffed by the people who do student support, and the work is aimed at taking the routine, repetitive load off them. They are the experts on where students get stuck and which service answers which question. Their input is what makes any future tool actually route a student to the right human. The study exists to give these offices their time back, not to automate anyone out of a role.
Lead: one member who owns the crosswalk grid.
Each member owns 2 to 3 colleges. They send the intake letter to those colleges’ service owners, chase the replies, and drop the corrected local names and annual numbers into the grid. Because the agent pre-fills each row, members are confirming and nudging, not building.
Lead: one member with student-facing access.
Recruit a few real students (through student government, a design studio, or advising) and run short think-aloud sessions to validate the three personas and the top findings. Confirms the scaled agent data against real student behavior. No PII recorded, just observations.
Lead: one member comfortable with research and numbers.
Keep the evidence base current: persistence research, the local barrier survey, and the usage baseline coming out of Subcommittee A. This is the “why it matters” spine that every recommendation leans on, and the before-number improvements get measured against.
Lead: one member who can translate barriers into options.
Turn the barrier log into ranked, no-PII AI options, each marked build or buy, screened against the no-student-data line. Reach first: how many students would this actually help. This is the hand-off to the recommendations and pilots.
Three to four small groups, each ownable in chunks, each with a low-coordination first deliverable. Members contribute asynchronously between meetings. Adjust the split as people self-select into the lane that fits their day job.
A committee member can copy this, fill in the bracketed bits, and send it. It asks for just two things, the local service name and a rough annual headcount, reassures the owner that this is about helping students find what already exists and taking routine work off their plate, and makes clear we collect no student data. Keep it short. The reply should take a few minutes.
Hi [first name],
I am reaching out from the Maricopa AI committee’s Student Support and Success group (Domain 5 of the ARC). We are putting together a simple map of the student-support services across all 10 colleges so that students can actually find the help that already exists on every campus. The goal is to make it easier for a student to reach the right office, and to take some of the routine “where do I go for this” questions off your team so you can spend your time on the students who really need you.
This is not an audit and it is not about replacing anyone. It is the opposite. The better we map what you offer, the more credit your service gets and the fewer students fall through the cracks before they reach you.
I only need two quick things about [service name] at [college], and you are the right person to confirm them:
1. Local name. What do you officially call this service on your campus? We have a draft from your public site, so you may just be confirming or correcting it.
2. Rough annual reach. About how many students does it serve in a year? A ballpark is completely fine.
That is the whole ask. We are not collecting any student names, records, or personal data, just the service name and an approximate count. If a number is hard to pin down, the name alone still helps.
You can reply right to this email with something as short as:
Local name: ________________________
Approximate students served per year: ________________________
Anything we got wrong on the draft: ________________________
Thank you for the few minutes. Happy to answer any questions, and glad to share the finished map with you when it is done.
Best,
[your name]
[your title], [your college]
Domain 5, Student Support and Success, the ARC
No student PII is requested or collected. The only data points are a service’s local name and an approximate annual headcount. For committee use. · ← Domain 5 hub