CopaMigo

01. The Problem

Community college completion rates are low. Nationally, fewer than six in ten community college students return for a second year at the same institution. Part-time students, who make up the majority of community college enrollment, persist to a second fall semester at only 53 percent. These are not students who were not capable of finishing. They are students who started and stopped.

Decades of research point to the same root cause: students who feel connected to their institution and supported by its services persist at significantly higher rates. A 2024 national study of 1,600 students found that those aware of five or more campus support services were 13 percentage points more likely to say they would persist than peers who were aware of fewer. Connection is the mechanism. It shows up in an advising relationship, in knowing how to get a financial aid question answered, in finding a club where you belong, in a peer coach who checks in on you. Students who have a reason to come back come back.

The problem is that the students who most need connection are the least likely to seek it out. They don’t know which office handles what, or that a club for people like them exists. They are embarrassed to walk into a building called “Disability Services,” or they don’t think of themselves as disabled at all. A student who was on an IEP in high school, or who has ADHD or anxiety, often doesn’t connect those experiences to the idea that they might qualify for accommodations in college. They just know they’re struggling. They won’t search for disability services because that word doesn’t describe how they see themselves. Every campus has more support than its students can find. The services and communities exist. Students don’t find them.

The inspiration for CopaMigo was close to home. Watching my own daughter reach for ChatGPT the moment she had a question she didn’t want to ask a person made something plain: for her generation, typing a worry into a chatbot that never judges is the natural first move, not a last resort. Community college students now bring that same instinct to questions about paying for school, failing a class, or finding someone to talk to, and the institution has to meet them where they already are.

There is also growing evidence that students are already turning to ChatGPT with questions they’re afraid to ask a human. A 2024 study found students explicitly value AI because they “can ask any questions they want and don’t have to worry about being judged or embarrassed.” Kim et al., CHI 2024. A professor at Old Dominion University noted that young people prefer asking AI partly because “they don’t have to go to a mental health clinician’s office where there may be some stigma associated with coming to the office.” ChatGPT has no idea what your campus offers, cannot connect a student to a real advisor, and in serious cases has been documented causing harm. Students need something that receives them the way ChatGPT does, without judgment, any time of day, but routes them toward real answers and real humans.

This pattern is widespread, not anecdotal. Recent research has documented students across higher education using ChatGPT for the kinds of questions that traditionally went to an advisor, a financial aid officer, or a campus counselor: course selection, what to do when struggling in a class, financial aid timing, transfer planning, and personal academic concerns. Almogren et al. (2024, Heliyon) reviewed studies of ChatGPT use for academic advising and found that students using AI for these decisions reported higher satisfaction with the process, but those students were taking direction from a tool with no knowledge of their actual campus, their actual program requirements, or which class their actual advisor would suggest given their coursework so far. Cavazos et al. (2025, Teaching of Psychology) documented college students’ regular use of generative AI for academic decisions. ChatGPT answers confidently and often incorrectly because it has no access to local context. Students act on responses that sound right and end up enrolled in the wrong class, missing a deadline, compromising their aid, or escalating problems they could have solved by talking to the right person on campus. The pattern is widespread enough that addressing it is no longer optional for student-facing institutions.

Many college websites already have a chat widget on the homepage. Students have learned to ignore them. These tools are essentially a search engine with a chat interface; they scan the website for keywords and return links. Type “I’m failing my class and I don’t know what to do” into most of them and you’ll get a link to the academic calendar. They are not designed to understand a student’s situation, and students know it. One of CopaMigo’s design challenges is overcoming that earned skepticism. Students will need to learn quickly that this is not one of those bots: built with real thought, real departmental input, and a genuine intent to connect them to a person who can help.

02. What CopaMigo Does

CopaMigo is a student-facing app that receives a student’s situation in plain language (typed or spoken) and answers it the way a knowledgeable friend at GCC would. The answers themselves come from the people on campus who would otherwise field these questions in person: advisors, librarians, financial aid staff, the veterans coordinator, social workers, the tutoring office, the records office, and the staff in every other student-facing service. They write the content, decide what the bot says, and update it when something changes. The bot is the delivery layer; the people are the substance. CopaMigo does not replace advisors, counselors, or support staff. It is a smarter front door to them, with the answers already on the front porch.

Not every question needs a chat handoff

CopaMigo uses a three-tier routing model based on the nature of the question. Some questions have clear, current answers, populated by department staff, that resolve the situation immediately. Others have a useful first answer but need a person to go further given the student’s specific circumstances. A few are urgent or sensitive enough that the bot should not pretend to answer at all and should hand off to a human with empathy and no delay. Getting this distinction right is part of the design.

02b. Audience

CopaMigo is built for community college students who are not sure where to go for help. That is the whole audience in one sentence. The student who already knows which office handles their problem rarely needs it. The student who is struggling, embarrassed, or simply does not know that an office exists is the one CopaMigo is designed to reach.

GCC is a Hispanic-Serving Institution, and the student body reflects that. Language access is not a translate button bolted on at the end. Multiple languages are built into how the tool receives a student and answers them, and the design does not assume the conversation happens in English or Spanish alone. A student should be able to describe their situation in the language they actually think in and be met there.

There is a second audience that is easy to overlook: the staff and services on the other end of the routing. Advisors, librarians, financial aid staff, the veterans coordinator, social workers, counselors, and the tutoring office are the people CopaMigo routes students to, and they are also the people who write and maintain the answers. The tool only works if it serves them too, by sending fewer repeat questions their way and handing them students who arrive with the right context already in hand.

03. Who Uses CopaMigo

Primary: Students (any stage)

• Enrolled students who are struggling and don’t know where to turn
• Prospective students who have barriers to enrolling and need a non-scary first contact
• Returning students who stopped out and are unsure how to come back
• Dual enrollment students (under 18), with age-appropriate routing and no personal data collected

Secondary: Student Services Staff

• Content admins: each department submits and maintains their question bank
• Human handoff recipients: advisors, counselors, coaches who receive routed students
• Analytics viewers: seeing what students are asking for that isn’t currently being met

Tertiary: Institutional Decision-Makers

• Retention data, service gap analysis, aggregate anonymized usage patterns

03b. The Advising Partnership

Why advisors are at the center of this

CopaMigo only works if advisors are part of it. A bot that doesn’t know which classes got cancelled, which courses only run in the fall, or which substitutions have been approved isn’t helpful, it sends students to add and drop classes based on outdated information and creates more work for the people it was supposed to help. Advisors aren’t supporting someone else’s tool here. They’re the reason it works.

First-semester students: advisor first, always

CopaMigo does not advise first-semester students on course selection. This is a hard rule. New students don’t yet have a checksheet, don’t know which courses have prerequisites, don’t know what’s running this semester, and don’t know about substitution options that might apply to their situation. Getting this wrong costs them time and money. When a new student asks what classes to take, the bot’s response is warm, clear, and firm: here is the link to your program’s checksheet, and your first step is meeting with an advisor before you register.

Continuing students: checksheet first, advisor second

Students who have already met with an advisor and have a checksheet are the primary advising use case. They have a plan. What they need help with is when something disrupts that plan: a class gets cancelled mid-semester, a prerequisite changed, a course turns out to only run in fall, a section filled up. These are the questions that currently generate one-off emails and 30-minute meetings that could be a 5-minute phone call.

CopaMigo’s job today is to surface the published checksheet again, remind them what their advisor told them about it, and route the question to advising. Course substitutions and sequencing are advisor decisions, not bot decisions. A class being cancelled doesn’t automatically tell the bot what replaces it for a specific student in a specific program year. Phase 2, with explicit advisor buy-in and per-program data submitted via R-17, opens the door to richer responses, but only after advisors have approved the data and the responses.

The advisor-facing layer: a tool for them, not just about them

Worth exploring as this project develops: whether CopaMigo can do more than route students to advisors. Advisors currently manage a significant amount of information by hand, checksheets, degree audits, notes on individual students, tracking who has been seen, much of which lives in spreadsheets or in the SIS in ways that require more steps than the task warrants. The idea worth putting on the table is that advisors could have their own interface within CopaMigo. Some starting observations, offered as suggestions, not specifications:

• A fast update interface for flagging class changes, cancellations, semester-only offerings, and approved substitutions, where a single update immediately changes what the bot tells every student who asks
• A degree audit or checksheet tracker that is faster than the current SIS workflow for the kinds of checks advisors do most often
• A query dashboard showing what students are asking about most, surfacing patterns before they become problems
• A student interaction log (voluntary, opt-in for students) so advisors can start from context instead of starting from scratch
• Appointment integration so the “book a quick check-in” prompt connects to a real schedule

These are starting points for a conversation with the people who do the job. The advisors who end up involved will have better ideas, and those ideas should drive what gets built.

04. Functional Requirements

05. Student Scenarios and Routing

06. Department Modules and Sample Questions

Each module is maintained by the department. The department submits their top 20-50 questions, the plain-language name of their service as it should appear in CopaMigo, and their direct contact instructions. Departments own their content.

06b. Low-Level Tutoring

CopaMigo’s default rule is to route, not answer. Low-level tutoring is the one scoped exception, and it applies only to simple, concept-level academic questions. For everything else, services, offices, money, crisis, IT, conduct, the bot still routes the student to a human. This capability lets CopaMigo give a quick, first-line tutoring answer right in the chat before it points the student to free GCC tutoring for anything deeper.

What it does

When a student asks a simple academic question, CopaMigo may do one short thing inline, then route: define or explain a term or concept in plain language, walk through one short worked example, clarify a formula or a grammar or citation rule, or suggest a concrete study approach. It is the fast first answer, the quick explanation a student would otherwise wait to ask a tutor. A student who asks “Can you explain what a thesis statement is?” or “Explain how to find a percentage” gets a brief, patient explanation on the spot rather than only a referral.

Socratic style

The inline help is patient, encouraging, and Socratic where possible. CopaMigo guides the student toward the answer instead of just handing it over, keeps the language plain, and ends the quick explanation with a checking question (“Does that part make sense?” or “Want to try the next one yourself?”). It stays bilingual and answers in the student’s language, the same as the rest of CopaMigo.

Escalation threshold

After the quick help, or any time the need is bigger than a quick concept, an ongoing struggle in a class, a whole assignment, feedback on writing, test prep, or repeated questions, CopaMigo warmly routes to the free GCC tutoring it already knows about: drop-in 30-minute sessions, online tutoring on GCC’s Discord, Brainfuse 24/7, and the Writing Center. Inline tutoring is framed as the fast first answer, and the free human and Brainfuse tutoring is the next step for anything real. When the student is struggling inside a specific class, the existing instructor-first rule still applies.

07. Human Handoff

Every routed interaction should end with a clear, warm next step toward a human. The quality of the handoff is the product. A phone number on a screen is not a handoff.

Contact card requirements per service

• Plain-language name of the service (how CopaMigo describes it, not the official title)
• What this service actually does in one sentence
• How to contact: walk-in location, phone, email, and/or scheduling link
• Hours and whether walk-ins are accepted
• What to say or bring when you show up; this removes the anxiety of not knowing what to do next
• Whether there is any cost
• Whether it is confidential (where applicable)

Live chat as the universal fallback (planned, Phase 2)

Live chat is a planned Phase 2 capability, not part of the current prototype (see the prototype-state note below). As designed, every service card will terminate in a chat fallback so no student leaves the tool without a path to a real person, per Principle 04 and R-14. This section describes how that handoff will work operationally once it is built. Today, the warm handoff runs through the contact information on each card (phone, email, walk-in location, and scheduling link), which is fully functional now.

Per-office staffing model

Each office’s chat would be staffed by the same person who already answers that office’s phone for appointments and routine questions: an advising office secretary, a veteran services administrator, the tutoring office admin, a financial aid front-desk staff member. For GCC Cares the natural staffing is the social work interns who already triage walk-ins. The chat shows up in their existing communication queue alongside phones and email; it does not require a separate role or schedule. If chat volume in any office exceeds what existing front-desk staff can handle, the next staffing layer is work-study students assigned to that office. Chat handoff should not require a new department, contract, or funding line to launch.

What chat looks like on the card

The chat affordance would be visible on every service card but visually subordinate to the primary contact info. The student sees the phone number, email, walk-in location, and scheduling link first because those resolve most situations on their own. The chat link sits at the bottom, smaller and quieter, framed as a fallback: “Still stuck? Chat with this office.” Crisis, Title IX, instructor, and campus police cards do not include chat: crisis numbers have their own 24/7 chat infrastructure (988, Crisis Text Line); Title IX is a formal reporting process where casual chat would be inappropriate; the instructor card connects the student to their own professor; campus police uses dedicated lines.

08. Current Prototype Architecture

This section describes the prototype as it stands today. The prototype was built to validate the design ideas cheaply and to give us something to test with students. It is not production architecture. Production scenarios are in Section 08b.

08b. Production Architecture: Hosting and API Scenarios

The current prototype runs as a single HTML file with the student providing their own Anthropic API key. This is not a production architecture and was never intended to be one; it is a testing posture that lets the design ideas be validated cheaply. Production deployment requires a server-side application with centralized API access, secrets management, request logging, rate limiting, and an institutional Data Processing Agreement with whichever AI provider is chosen. This section describes the realistic options for that production architecture.

Scenario A: Direct Anthropic API (custom-built CopaMigo)

What it is: A server-side application (Node.js or Python) running in Maricopa-managed infrastructure, communicating with the Anthropic API. Student traffic hits a Maricopa server, which then calls Anthropic with an institutional API key. The student never touches the API directly. API key lives in a secrets manager (AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault). Standard request logging, rate limiting, monitoring, and incident response built around it.

Data position: Anthropic’s commercial terms state by default that customer API data is not used to train Anthropic’s models. Zero Data Retention is available as a contractual addition for enterprise customers. Anthropic offers SOC 2 Type 2 and signs Data Processing Agreements. There is no middleman between Maricopa and Anthropic. This is the structurally cleanest data-handling model among the five scenarios.

Hosting: Maricopa-managed AWS, Azure, or on-premise. Student conversations can be logged in Maricopa’s own infrastructure (anonymized) for abuse detection and accuracy auditing. No conversation data ever leaves the Maricopa boundary except the prompt-and-response round trip to Anthropic.

What it costs: Anthropic API costs scale with token usage. Rough estimate at the projections in the Cost Model section. Plus infrastructure (estimated under $5,000/year on AWS at projected load). Plus development and maintenance.

Pros: Cleanest data architecture. No vendor chain. Anthropic’s models are the ones the prototype was built and tuned against, so no prompt re-engineering needed. Direct support relationship.

Cons: Adds another vendor to Maricopa’s contract surface. Requires institutional procurement of an Anthropic Enterprise contract with negotiated DPA terms.

Scenario B: AWS Bedrock with Claude (custom-built via cloud provider)

What it is: Identical application architecture to Scenario A, but the Claude model is accessed through AWS Bedrock instead of directly through Anthropic. Maricopa likely already has an AWS contract; this avoids adding a new vendor relationship. Bedrock provides the same Claude models with AWS-native compliance and billing.

Data position: AWS Bedrock by default does not use customer prompts or completions to train Anthropic’s models. Customer data stays in the customer’s AWS account. AWS BAA, AWS GovCloud availability if needed for additional compliance.

Hosting: Native to AWS. Application, secrets, logging, rate limiting all in AWS using existing Maricopa account.

What it costs: Bedrock pricing is roughly comparable to direct Anthropic API but slightly higher (typical AWS markup of approximately 5–15%). Procurement is simpler because it’s an existing AWS line item rather than a new vendor.

Pros: Leverages existing AWS contract. AWS handles BAA, audit, and compliance overlay. Maricopa security and procurement already trust AWS. No new vendor to onboard.

Cons: Slight cost premium over direct API. Bedrock occasionally lags on latest model releases (typically by days or weeks, not months).

Scenario C: Azure OpenAI Service (custom-built with GPT-4 family)

What it is: Same architecture pattern, but uses OpenAI models through Microsoft’s Azure OpenAI Service rather than Claude. Maricopa likely has a Microsoft enterprise contract via Microsoft 365.

Data position: Azure OpenAI explicitly does not use customer data to train OpenAI models. Customer data stays in the customer’s Azure tenant. Microsoft signs BAA and DPA institutionally.

Hosting: Native to Azure. Same advantages as Scenario B but in Microsoft’s ecosystem instead of Amazon’s.

What it costs: GPT-4 family pricing is comparable to Claude pricing on a per-token basis with model-by-model variation. Procurement leverages existing Microsoft contract.

Pros: Existing Microsoft relationship through M365. Frontier-quality model. Strong compliance posture. May already be on Maricopa’s approved-vendor list.

Cons: Different model family from what the prototype was built against; the system prompt would need to be re-tested and tuned. Some routing behavior may shift between Claude and GPT-4 (this is real and shouldn’t be hand-waved). OpenAI’s brand has had its own data-handling controversies, which may matter to the CIO even though the Azure tenant is contractually distinct.

Scenario D: Buy Salesforce Agentforce Education

What it is: Maricopa adds Agentforce for Education to its existing Salesforce Education Cloud subscription. Pre-built agents handle student inquiries grounded in Salesforce CRM data. CopaMigo as a separate tool would be retired or absorbed.

Data position: The Einstein Trust Layer provides zero data retention with the LLM partner (currently OpenAI), data masking for PII, prompt defense, and an audit trail. Salesforce documents this as a contractual guarantee with their LLM partners. The data-training concern that previously blocked Maricopa adoption may be addressable today; this is worth re-checking with the CIO. The architecture has more layers than direct API access (Maricopa → Salesforce → OpenAI), which means more surface area for compliance review but also more institutional accountability.

Architectural fit for CopaMigo’s design: This is the harder question. Agentforce is designed for student service automation grounded in CRM data: students who are already in the system, with records, asking questions whose answers depend on their record. CopaMigo’s design center is anonymous-first, stigma-aware intake for students who do not want to identify themselves and whose questions are about navigation, not records. These are different paradigms. Agentforce can be configured to do something similar, but the design philosophy of the platform pulls against the design philosophy of CopaMigo. The default Agentforce experience would not look like CopaMigo without significant custom work, at which point the cost advantage of buying-not-building shrinks.

What it costs: Agentforce pricing is per-conversation or per-user model, negotiated as part of the Salesforce contract. Likely six-figure annual commitment at district scale. Implementation partner cost on top.

Pros: Single vendor. Single contract. Salesforce handles compliance and security. Inherits all of Salesforce’s enterprise infrastructure.

Cons: Design paradigm mismatch with CopaMigo’s anonymous-first, stigma-aware approach. Significant implementation work to make it look and feel like CopaMigo. Locks Maricopa into Salesforce as the long-term student-AI platform. Higher total cost than custom build at the prototype’s scope.

Scenario E: Hybrid (custom CopaMigo as anonymous funnel, Salesforce for identified students)

What it is: Both. CopaMigo runs as the anonymous-first inbound layer (Scenario A or B architecture). When a student opts to identify themselves and escalate to a real person, their consented conversation context hands off into Salesforce as a service case in the existing CRM. The student does not have to repeat themselves.

Data position: Anonymous portion is governed by the chosen base scenario (A or B). Identified portion enters Salesforce under existing district data agreements. Crossing the boundary is the student’s consented action, not a system-level integration.

Architectural fit: This is the option that respects CopaMigo’s design philosophy AND uses the institutional CRM investment Maricopa is already making. The anonymous front door stays anonymous. The students who choose to enter the institutional system enter it cleanly. The handoff is a positive student action, not a data-syncing background process.

Pros: Best architectural fit for the design philosophy. Maricopa’s Salesforce investment is leveraged where it adds value (case management for identified students). The anonymous funnel is preserved for students who fear disclosure. Two systems each doing what they do well.

Cons: Two systems instead of one. Integration work to wire the consented handoff. Slightly higher long-term operational complexity.

Recommendation

For the GCC pilot, Scenario B (AWS Bedrock with Claude) is the right architecture. The reasoning: the prototype was built and tuned against Claude, the design philosophy is anonymous-first, the data-training concern is satisfied by Bedrock’s default policy, the procurement path uses an existing Maricopa AWS contract rather than adding a new vendor, and the cost is modest relative to the alternatives. Anonymous request logs stay in Maricopa’s AWS account; conversation data leaves Maricopa infrastructure only as the prompt-and-response round trip to the Bedrock-hosted model, and is not retained or used for training on the way back.

Decisions about district-scale architecture should wait for pilot evidence. If the pilot validates the tool’s value at GCC, the next conversation is whether to scale up the same architecture across the district, integrate with Salesforce in a hybrid pattern (Scenario E), or take a different path entirely based on what the pilot teaches. Committing to a long-term architecture before pilot results is not what a thoughtful CIO would expect or recommend, and the PRD should reflect that.

A direct rebuild on Agentforce (Scenario D) is the path of least resistance from a procurement standpoint but the most expensive way to get to something that looks like CopaMigo, and the design fight against Agentforce’s CRM-grounded paradigm is more work than the procurement savings would justify. It also re-opens the data-training question that the CIO has already taken a position on (see the data-sovereignty callout below).

09. Scope

10. Success Metrics

11. Build Order

12. Staffing, Funding, and Deployment

Student-informed, faculty-built

CopaMigo was designed and built by faculty with student input shaping the voice, routing logic, and testing. Students know what other students are actually afraid to ask, and their feedback is essential to getting the tone and the routing right. Usability testing with real students validates that the tool feels trustworthy. Future development may involve student developers through work-study or capstone projects, with a small grant covering ongoing development phases. Grant funding is appropriate here: this is applied research with a direct retention outcome, and community college student success grants are well-established at both the state and federal level.

Human handoff staffing model

The human layer of CopaMigo is the live chat handoff when the AI can’t fully resolve a student’s question. The GCC Cares social work interns are a strong fit to staff this chat during hub hours: they already know the resources, the referral pathways, and the student population. This keeps the handoff warm and informed rather than routing students to a generic help desk. During hours when the hub is closed, the handoff falls back to email with a next-business-day response. Crisis situations always route to professional resources (988, campus counseling, campus police) regardless of staffing.

Crisis routing goes outside the peer layer

Tier 3 crisis situations route to professional resources, not students. The campus social worker and social work interns are the appropriate first human contact for situations that rise above peer navigation. When counseling isn’t immediately available, and on many community college campuses counselors are primarily referral-based rather than providing ongoing therapy on-site, the escalation path goes to a community crisis line or agency, not to a peer. The system should make this handoff clear, warm, and fast.

Deployment path

For the GCC pilot, CopaMigo runs as a standalone web application separate from the district’s portal app. This lets the pilot move quickly without OIT integration work and keeps the anonymous-first design clean. After the pilot, the integration question (with the district student portal app, with Canvas LTI per R-22, with Salesforce per Section 08b Scenario E) gets decided based on what the pilot proves out. Production hosting and API architecture for the pilot are described in Section 08b.

13. Competitive Landscape

Nine products are most relevant to where CopaMigo sits. The architectural comparison with Salesforce Agentforce specifically is detailed in Section 08b; this table summarizes how each shapes CopaMigo’s design choices.

Appendix A: Discoverability and Distribution

Building a useful tool is half the work. The other half is making sure students who would benefit actually find it and trust it enough to try. Most college chatbots fail at this stage, not at the technology stage. CopaMigo’s distribution strategy is intentionally multi-channel and built around the realities of community college student behavior.

What does NOT work (and why)

Replacing a discredited chatbot in its existing UI slot is the most common move and the wrong one. If GCC’s Gaucho Bot has a reputation for being unhelpful, students who have tried it once will not click on whatever sits in that same spot. They will assume it’s the same useless tool with a new logo. The Sam the Ram example from Fresno City College above is the same pattern: the chatbot is right there, students know it’s there, and they don’t use it because they don’t trust it. Putting CopaMigo in the help menu and calling it done would inherit that distrust. So would replacing the existing widget without changing the visual identity, label, or framing.

Distribution channels that work for community college students

Canvas LTI integration. Canvas supports LTI 1.3 external tools, which can be added as a global navigation tab visible in every course. CopaMigo as a Canvas tab labeled “Find Help” or “Talk to CopaMigo” would put it in front of every student every time they log in to do coursework. This is one of the highest-traffic surfaces on campus. LTI does not require students to log in to CopaMigo separately, and the tool can choose to ignore the user identity that LTI passes (preserving anonymous-first design). Canvas placement is a Phase 2 priority.

Syllabus statement. Faculty add a one-line statement to their syllabus pointing students to CopaMigo: “If you ever need help finding the right office on campus and don’t know where to start, try CopaMigo at [URL], it’s anonymous and bilingual.” This costs nothing, scales across hundreds of courses, and reaches every student at the start of every semester. Maricopa already has mandatory syllabus statements for DRS and Title IX; a CopaMigo statement would fit naturally alongside those.

Faculty referral during class. Instructors who know a student is struggling can mention CopaMigo as a low-pressure starting point. “You don’t have to figure this out alone, here’s a tool that can help you find the right person.” This is especially valuable from instructors who teach gateway courses where retention is most fragile (developmental math, ENG091, FYE).

QR codes in physical spaces. Bathroom stalls, the back of restroom doors, the tutoring center, the library, the food pantry, the Veterans Center, the Counseling waiting area. Bathroom QR codes specifically are highly effective because students have a private moment with their phone and are often dealing with stress. Posters at GCC Cares and the upcoming GCC Cares Hub are natural placements.

The GCC Cares Hub kiosk. The hub is being designed (see separate brief) as the physical embodiment of student support. CopaMigo as a touchscreen kiosk near the entrance lets students start the conversation without talking to a person first, then walk to the right desk inside the hub or take their phone home with the answer. The new interactive screen in the library could function as a second kiosk surface.

Student government and peer mentors. ASG, student ambassadors, peer success coaches, club leaders. Train them on CopaMigo so they can recommend it organically when they encounter a struggling student. Word-of-mouth from a peer carries far more weight than a banner on a website.

Social media. Short videos showing real-looking student situations and the CopaMigo response. Not promotional, just authentic (“Wait, you can just ask it like this?”). Instagram and TikTok reach the right age group; the GCC Discord community is also a high-trust channel.

If CopaMigo does take a website slot, rebrand the visible label. Don’t call it “Chatbot” or put it where the Gaucho Bot lives. Call it “Find Your Person at GCC” or “CopaMigo: Anonymous Help Finder.” Different name, different visual identity, different promise. The chatbot category is contaminated; the help-finder category is fresh.

Discoverability metrics for the pilot

The right success metric is not just total messages or sessions. It is whether CopaMigo is reaching the students who needed it most: anonymous students with stigmatized situations, students who would not have walked into a building, students who eventually accepted a human handoff. Phase 2 admin analytics should specifically report on:

• What share of conversations involved a stigma-coded topic (mental health, basic needs, sexual misconduct, considering withdrawal)
• What share ended with a human handoff requested
• What share came in via each distribution channel (referrer URL, QR code parameter, Canvas LTI session, hub kiosk)
• What time of day the messages cluster (a successful tool will see late-night and weekend traffic, when offices are closed)
• Language distribution (how many sessions are in Spanish vs. English vs. other)
• Topics that hit dead ends (no relevant card available) so we know what services to add or verify next

Appendix B: Service Directory

This appendix is the authoritative source for everything CopaMigo knows about campus services. All system prompt updates should be derived from verified data in this section. When CopaMigo moves to an institutional deployment, this is the section that gets updated by campus staff.

Basic Needs / GCC Cares

Academic Advising

Financial Aid

Disability Resources & Services (DRS)

Counseling Services

Tutoring & Academic Support

Student Life & Belonging

IT Help

Enrollment Services

Crisis Resources

North Campus

Other Services

Routing Rules from Student Handbook

Appendix C: Open Questions and Pending Decisions

The questions below are deliberately unanswered. They are operational, financial, and governance unknowns that pilot evidence and CIO-level conversations are the right way to resolve. Listing them here is a credibility move, not a stalling tactic: the difference between a tool that is ready to pilot and a tool that is ready to scale is whether these have answers, and the honest answer today is that they do not.

Operational

• Per-office chat staffing in practice. Section 07 describes a model where each office’s existing front-desk staff handles chat alongside phones and email, with work-study as overflow. This is operationally untested. A pilot at one or two GCC offices is the right way to validate whether the volume actually fits inside existing front-desk capacity, or whether a staffing layer is needed.
• The 90/10 design intent. Principle 04 states that roughly 90% of students should resolve their question through the empathy message and contact card alone, with only 10% needing chat. This is an aspiration grounded in design intent, not a measured number. The pilot should report the actual ratio and the bot’s response should be tuned if the ratio is materially worse.
• Native Spanish speaker usability. Bilingual support is built in (R-19 multilingual voice, auto-detected response language), but testing with Spanish-dominant students has been limited. The pilot should include intentional usability sessions with native Spanish speakers and adjust the auto-detect behavior, voice quality, and prompt phrasing based on what they say.
• Crisis protocol review. The Tier 3 crisis routing (988, campus police, Title IX) has not been formally reviewed by GCC counseling staff or district legal counsel. A clinical and legal review should happen before live student deployment.
• Existing chatbot conflict. Maricopa District has an existing website chatbot (referred to internally as Gaucho Bot in some contexts). Whether deploying CopaMigo creates a contractual conflict, a policy conflict, or simply a positioning question is unknown and is a CIO-level conversation.

Financial and procurement

• AWS Bedrock pricing at district scale. Scenario B (Section 08b) is the recommended pilot architecture. Production-cost modeling at the GCC pilot scale is straightforward; district-scale projections require a Maricopa-specific pricing conversation with AWS account management. This has not been started.
• Anthropic enterprise procurement path. Whether direct Anthropic API (Scenario A) or AWS Bedrock-mediated access (Scenario B), an enterprise contract with negotiated DPA terms is part of the production architecture. Maricopa procurement has not been engaged.
• Salesforce Scenario E integration scope. Section 08b describes a hybrid architecture where CopaMigo hands off consented students to Salesforce. The actual integration scope (API access, data flow, identity transition UX) has not been engineered.

Governance and ownership

• Long-term ownership. CopaMigo was designed and built by faculty. As the tool moves toward institutional deployment, the question of who owns it operationally, which department, which budget line, which incident-response role, is not yet answered.
• Continuity if the original builder transitions. The current builder may transition out of GCC during the pilot timeline. The maintenance plan needs to be a documented institutional responsibility before that transition rather than after.
• Content stewardship for new schools. R-18 describes the deployment workflow for adding new Maricopa colleges. Each new school requires deep conversations with departments to populate the human-curated content base. The institutional unit responsible for running this process across the district has not been identified.

Compliance and accessibility

• WCAG 2.1 Level AA audit vendor. R-23 commits to ADA Title II compliance ahead of the April 26, 2027 deadline. The audit vendor has not been selected and the audit itself has not been scheduled.
• FERPA application boundary. CopaMigo collects no FERPA-protected data by design. Whether the tool’s anonymous query logs trigger any institutional data-handling obligation despite that design choice is a question for district legal review.

Design and brand

• Branding follows the college it serves. The prototype is deliberately unbranded and lives on a personal website, not a Maricopa domain, so no one stumbling onto it mistakes it for an official GCC tool. On launch it would take on the serving college’s colors, fonts, and brand, GCC’s for GCC, and each college’s own in a district-wide deployment.
• Maricopa brand alignment. The current visual design is functional but not aligned with the Maricopa brand system. A redesign pass using Anthropic’s Claude Design (loading the Maricopa brand manual as the foundation) is planned. Whether the resulting design will satisfy Maricopa Marketing’s brand-approval process is unknown.
• The school picker UX. A district-wide deployment requires a school selection flow at first launch. The current proposed wording (“Which Maricopa college do you call home?”) tested well in conversation but has not been usability-tested with actual students.

Appendix D: AI Implementation Specification

This appendix is the implementation-level spec for CopaMigo’s AI behavior. It exists so that if the production deployment uses a different AI provider than Claude (any of Scenarios B through E in Section 08b), the engineer doing the rebuild has a model-agnostic specification of what the tool must do. The current Claude system prompt in index.html is the working implementation; this appendix is the design intent. When the two diverge, this appendix is the authoritative source.

C.1 Response Schema

The AI returns a single JSON object on every turn. The front-end parses it and renders the bubble plus zero or more service cards. The schema is fixed and any deviation is a bug.

{
  “message”: “Warm 2-4 sentence response in plain language. No service names. No bullet lists. No URLs. This is the voice the student reads first.”,
  “followUp”: “Optional. A single short clarifying question if more info is needed before routing. Empty string if not needed.”,
  “crisis”: false,
  “services”: [
    {
      “id”: “advising”,
      “icon”: “📋”,
      “label”: “Figure out your next step”,
      “program”: “Optional. Plain text program name only, e.g. ‘Nursing AAS’. Front-end converts to checksheet URL.”,
      “contact”: “Multi-line string. Use \\n between lines. URLs MUST be markdown links: [readable text](https://...). Never spell URLs in plain text.”,
      “hours”: “Multi-line string. Use \\n between lines. Same URL rules as contact.”
    }
  ]
}

Field-by-field rules:

• message: Empathy-first acknowledgment in 2-4 sentences. Plain conversational language. No institutional service names (“Disability Services,” “Financial Aid Office”) in this field. No bullet points or numbered lists. No URLs of any kind. The student reads this before they see any cards. If they read only this, they should feel heard.
• followUp: Used only when the AI needs one piece of information to route correctly (e.g., “Is this for math, writing, or something else?”). Empty string otherwise. Never used to extract personal information.
• crisis: Boolean. true only when student input indicates immediate mental health crisis or physical safety risk. When true, the front-end suppresses all non-crisis cards and shows crisis resources only. False on every other turn.
• services: Array of zero or more service cards. Empty array is valid (e.g., when only a follow-up question is needed). Multiple cards are valid and expected for multi-service situations like “I’m failing and my financial aid is on hold.”
• service.id: Lowercase snake_case identifier matching one of the known card types in the system. The front-end uses this for analytics and styling.
• service.icon: Single emoji that matches the service category. Used as the visual anchor on the card.
• service.label: Action-oriented headline in plain language (“Get help paying for school,” not “Financial Aid”). This is the only place the student sees the institutional service framing, and it should still avoid jargon.
• service.program: Used only on the ADVISING card when the student named a specific program. Plain text only (“Web Design/Development AAS”). The front-end runs this through a hardcoded URL lookup table and renders it as a clickable checksheet link. Never let the AI construct the URL itself; URL hallucination is the failure mode this field is designed to prevent.
• service.contact and service.hours: Multi-line strings using \n for line breaks. URLs must always be wrapped in markdown link syntax. Bare URLs are forbidden in these fields. Phone numbers should be plain text in 623-XXX-XXXX format so mobile devices auto-link them.

C.2 System Prompt Structure

The system prompt is organized into named sections. Each section serves a specific role. The order matters because later sections reference earlier ones and because sections at the top of the prompt are weighted more heavily by most current AI models.

C.3 Routing Flow Rules

Several routing patterns are too complex for “match the student’s words to a card” and require explicit decision logic. These flows are codified in the system prompt.

Empathy-first response (every turn)

1. Read the student’s input in full.
2. Compose a 2-4 sentence acknowledgment in plain language. No service names, no jargon, no bullets.
3. Decide which service card(s) apply.
4. Return the empathy message in message and the cards in services.

Crisis flow (overrides all others)

1. If the student’s input mentions self-harm, suicide, immediate physical danger, or active abuse: set crisis: true.
2. Show only the CRISIS card. Suppress all other routing.
3. The CRISIS card always leads with 911 for immediate danger, then 988, Crisis Text Line, Maricopa Crisis Line, and campus emergency.
4. The empathy message is shorter and more grounded than usual: “You don’t have to handle this alone. Here are people available right now.”

Tutoring flow

1. If the student is struggling in a specific class or with a professor: show INSTRUCTOR card first, then TUTORING as backup.
2. If the student clearly said math: show MATH_SOLUTION.
3. If the student clearly said writing or essay or paper: show WRITING_CENTER.
4. If the student clearly said research or sources or citations: show LIBRARY.
5. If subject is unclear or they said “everything”: show general TUTORING and use followUp to ask which subject.
6. If after hours or student mentioned needing help nights or weekends: include Brainfuse mention in the card.

Academic program advising flow

1. Validate that asking is the right move and acknowledge the program warmly.
2. Mention universal AAS basics: ENG101 or ENG107, a math course, FYE101 or FYE103. Beyond that, point to the program checksheet.
3. Show ADVISING card with the program name as plain text in the program field. The front-end converts it to a checksheet URL.
4. Encourage the student to read the checksheet themselves AND meet with an advisor for confirmation of what’s offered this semester.
5. If first-semester student: always direct them to meet with an advisor before registering.
6. Never name specific course numbers or course titles from training data. Course catalogs change every semester and AI training data on course names is unreliable. Only the live checksheet is authoritative.

Dates and calendar flow

GCC has three different “when is X” pages. The AI must route to the correct one based on the question type:

1. Graduation or commencement question → show RECORDS card. Tell the student the current date, time, and location is on the GCC Graduation Ceremony page. Never guess the date.
2. Academic deadline (finals, registration, drop deadline, breaks, holidays) → show RECORDS card. Point to the Academic Calendar.
3. Activities or events (club meetings, performances, guest speakers, sports) → show STUDENT_LIFE card. Point to the clubs page (for meeting times) or the campus events calendar (for one-off events).
4. Identity-based club question (LGBTQ+, Latinx, religious, cultural) → show STUDENT_LIFE card. Name the matching club from the Clubs and Organizations section if one exists. Always direct to the live clubs page for current meeting times.

C.4 Anti-Hallucination Guardrails

AI models will hallucinate confidently when their training data is stale, partial, or pattern-matched. CopaMigo’s guardrails are not optional behaviors; they are structural constraints that prevent the AI from sending a student to a wrong place. A new AI model is not equivalent to Claude on this tool unless it can be made to obey all of these.

C.5 Behavioral Patterns

These are the qualitative patterns that distinguish CopaMigo from a generic chatbot. They are codified in the Core Behavioral Rules section of the system prompt and tested for in C.8.

• Empathy first, always. The student feels read before they see resources. The message field is structured to deliver this and only this.
• Plain conversational language. Same register a thoughtful peer would use. Not the register of a campus brochure or a help desk script.
• Stigma-aware framing. Avoid loaded terms in the empathy layer. The card surfaces the formal service name only after the human acknowledgment.
• Lean responses. One or two most-useful links per card, not every possible link. Students are used to ChatGPT-style direct answers, not navigation through a website.
• Multi-service routing when warranted. One situation can route to several offices. The AI does not artificially limit to one card.
• Route to humans, do not replace them. The AI does not answer the student’s underlying question (about benefits, accommodations, financial aid eligibility, course selection); it identifies who can answer and how to reach them.
• Crisis is non-negotiable. When in doubt, route to crisis. The cost of a false positive is a student seeing a hotline they did not need; the cost of a false negative is potentially fatal.
• Anonymous-first. The AI never asks for the student’s name, ID number, MEID, or any personally identifying information. Identity belongs at the human handoff, not at intake.

C.6 Front-End Logic vs AI Logic

The split between what the AI does and what the front-end handles is deliberate. The front-end carries the deterministic logic so the AI is never asked to do things AI is bad at (string-building URLs, exact-match data lookups, schema validation). A rebuild on a different AI inherits the same front-end and only needs to replicate the AI side.

C.7 Localization Requirements

CopaMigo is bilingual at minimum (English and Spanish) with planned expansion to Arabic, Vietnamese, and other Maricopa-common languages. The localization work splits into two layers:

• AI-generated content (the message field, follow-up questions, card content): Modern frontier models including Claude, GPT-4 family, and Gemini handle multilingual generation natively. The AI auto-detects language from the student’s input and responds in the same language. The system prompt is in English regardless of student language; only the output is translated. A new AI model must demonstrate Spanish-language quality at least equivalent to current Claude before being considered ready for the GCC pilot.
• Static UI text (welcome screen, input placeholder, button labels, footer): These are not generated by the AI; they live in the front-end. Each new language requires a translation pass and a language switcher (or auto-detect from browser locale).
• Card data: Service card content (contact info, hours, building names) stays in English. The AI translates the empathy message and any narrative content but does not translate proper nouns, phone numbers, or URLs. A Spanish-speaking student gets a Spanish empathy message and English contact info, which matches the reality that they will be calling an English-speaking office.
• Voice input: The Web Speech API supports multilingual recognition. Configuration is per-browser per-language; the front-end sets the recognition locale based on detected user language.

C.8 Migration and Equivalence Testing

If CopaMigo is rebuilt on a different AI model, the rebuild is functionally equivalent to the current Claude implementation when it passes the following test scenarios. Each scenario should be evaluated by a faculty reviewer (not an automated metric) for correctness, tone, and routing fidelity.

A successful rebuild satisfies all ten scenarios at quality equivalent to or better than the current Claude implementation. Any scenario where the new model degrades materially from current behavior is a release blocker, not an acceptable difference.

Appendix E: Path to Production

The current CopaMigo prototype is intentionally lightweight: a single HTML file on GitHub Pages, an Anthropic API key supplied by the tester, and zero backend. That posture exists to validate the design ideas with real students at near-zero cost. It is explicitly not production architecture and was never intended to be. This appendix lays out the four phases between today’s prototype and a district-wide deployment across all ten Maricopa colleges, and what changes at each step.

The frame this appendix uses: the prototype proves the design. The production build is a different kind of work, backend engineering, infrastructure operations, vendor coordination, compliance audits, content governance, and is appropriately the kind of work institutional IT and a vendor partner should lead, not a single faculty builder. CopaMigo’s role at each phase is to be the spec for what gets built, not to be the build itself.

D.1 Phase 0: Current Prototype (where we are)

Stack: Single HTML file (copamigo/index.html) on GitHub Pages. Vanilla JavaScript, no build step. During prototyping the AI is called directly from the browser; production moves these calls to a server so credentials are handled server-side, never in the browser. All conversation state lives in browser memory. No server, no database, no logging, no analytics.

Hosting: a static GitHub Pages site used for prototyping and stakeholder demos. Production moves to college-owned hosting.

What this is good for: Demonstrating the design to stakeholders. Walking the CIO and department leads through realistic scenarios. Running the planned student usability testing (six to eight students, see Section 11). Iterating on routing logic and card content based on what students actually ask. Proving that the empathy-first JSON pattern produces a usable conversation.

What this is not good for: Anything involving real students at scale. Specifically:

• In the prototype, AI calls are made client-side; production moves them behind a server so credentials are handled server-side and never exposed in the browser. This is a standard prototype-to-production change and a prerequisite for any public deployment.
• There is no rate limiting, abuse detection, or cost cap. A single bad actor could rack up thousands of dollars of API charges in an afternoon.
• Conversations are not logged. There is no way to audit accuracy, identify routing failures, or measure whether students are getting helped.
• Department content updates require editing the system prompt by hand and redeploying the HTML file. Not sustainable beyond a single department-of-one.
• No accessibility audit, no FERPA review, no DPA, no incident response plan, no on-call.
• Not yet institutionally owned. Production runs on college-owned hosting with an institutional AI account.

Phase 0 is a faculty prototype. The student usability testing in Section 11 happens in this phase. After the testing validates the design, Phase 1 begins.

D.2 Phase 1: Hardened Prototype for Institutional Pilot

Goal: Move the working prototype off the builder’s personal infrastructure and onto Maricopa-controlled infrastructure with institutional credentials, while preserving the design and behavior validated in Phase 0. This is the smallest possible step that produces a tool a Maricopa CIO can responsibly run a real pilot on.

What changes architecturally:

What stays the same: The visible front-end (look, feel, conversation flow), the system prompt logic, the JSON schema, the routing rules, the card content, the empathy-first design. Everything in Appendix D carries over. The student-visible tool is the same; the infrastructure underneath it is institutional.

Estimated work: Six to ten weeks of one mid-level full-stack engineer. The frontend is essentially copy-paste from the prototype with the API call rewritten to hit the Maricopa proxy instead of Anthropic directly. The backend is a thin proxy with secrets management, rate limiting, and logging, well-understood patterns with mature libraries in any major language.

Operating costs: Two variable costs (API usage scales with student traffic; infrastructure scales sub-linearly because the proxy is small) plus negligible flat costs for monitoring and storage. Specific numbers depend on Maricopa’s existing AWS or Azure pricing agreements, the model tier chosen at the API layer, and pilot traffic volume. The pilot is the right place to gather actual usage data rather than commit to estimates.

What this enables: A real GCC pilot with real students. A signed institutional DPA with Anthropic. A defensible answer to “where does the data go” and “who pays for it.” A baseline for measuring whether the tool reduces no-show rates, improves first-time service routing, or reaches stigma-coded populations who would not have walked into an office.

D.3 Phase 2: GCC Single-Campus Production Pilot

Goal: Run CopaMigo as a real production service for GCC students for a full academic semester, with the operational features that distinguish a service from a science project. Generate the evidence base that decides whether to scale district-wide.

New capabilities required:

Canvas LTI 1.3 integration

CopaMigo registered as an LTI external tool in Canvas, addable as a global navigation tab. Visible in every course for every GCC student. Branded “Find Help” or similar to avoid inheriting the reputation of the legacy Gaucho chatbot. LTI passes student identity at launch, but the tool ignores it to preserve anonymous-first design. Implementation involves registering a Developer Key with Maricopa Canvas admin, exposing an LTI launch endpoint, and signing LTI launch tokens. Standard OAuth 2.0 flows, well-documented by Instructure.

Department content management

The current prototype updates department content by editing the system prompt by hand. This does not scale. Phase 2 needs a back-office tool that lets each department’s designated content steward review and update their own service card content (contact info, hours, links, FAQ-style answers) without engineering involvement. The advisor submission form (R-17) prototypes this idea; Phase 2 builds it as a real CMS-lite. Submissions are reviewed and approved before publishing. Versioned, audited, reversible.

Live chat infrastructure

The “Still stuck? Chat with this office” link currently opens a modal explaining this is a prototype. Phase 2 wires it to a real chat platform (Intercom, Olark, LibChat, or whatever Maricopa standardizes on) with per-office routing. Each office’s chat would be staffed by the same person who already answers that office’s phone, advising office secretary, veteran services administrator, tutoring office admin, financial aid front-desk staff, GCC Cares social work interns. Work-study students are the next staffing layer if volume exceeds existing capacity. Crisis cards do not include chat (crisis numbers have their own 24/7 infrastructure).

WCAG 2.1 Level AA compliance audit

Required by ADA Title II for public community colleges with the Maricopa District compliance deadline of April 26, 2027 (R-23). Phase 2 includes a full audit by an external accessibility vendor, remediation of any findings, and ongoing testing as part of the deploy pipeline. The Claude Design redesign (planned for Phase 1.5 or Phase 2 entry) is the natural moment to bake compliance in from the start.

Multilingual UI framework

Spanish at launch, with Arabic, Vietnamese, and other Maricopa-common languages added based on observed traffic patterns. UI text (welcome screen, placeholders, button labels) translated and language-switchable. The AI side (response generation) is already multilingual via Claude; Phase 2 builds the UI scaffolding around it.

Analytics and evaluation dashboard

Beyond Phase 1’s basic logging, Phase 2 produces the evidence the district needs to decide on scaling. Dashboard metrics include the discoverability metrics from Appendix A, plus session-level success indicators (did the student receive a card; did they tap a link; did they request a chat; did the chat connect; did the office report a successful interaction). Anonymous, aggregated, FERPA-aware.

Operational maturity

SLO/SLA targets. Monitoring and alerting (uptime, latency, error rate, API cost). Incident response runbooks. Quarterly access reviews. Annual penetration test. Documentation that does not depend on tribal knowledge from the original builder.

Estimated work: Six to nine months of a small product team, one product manager, two engineers, one designer (part-time), one accessibility specialist (contracted). Plus institutional roles: Canvas admin coordination, IT security review, accessibility audit vendor, content stewardship process design. This is the phase where the work is genuinely “vendor or in-house IT” scope, not “faculty side project” scope.

Cost framing: Total cost depends heavily on the build approach. The build-everything-from-scratch path is the most expensive; the partner-with-an-existing-platform path (Element 451 or similar) leverages infrastructure that already exists and substantially reduces what needs to be built. The prototype work in Phase 0 and 1 substantially de-risks any of these estimates by validating the design before the spend, and Maricopa should expect actual numbers based on RFP responses rather than commit to a budget at PRD-writing time.

D.4 Phase 3: District-Wide Deployment (10 Maricopa Colleges)

Goal: Make CopaMigo available to every student at every Maricopa college, with each college’s own service directory, while preserving the unified design and shared infrastructure that make a district-wide tool worth doing.

What changes from Phase 2:

• Multi-tenant architecture. One CopaMigo deployment, ten content sets. The school-picker UX (first launch flow already designed: “Which Maricopa college do you call home?”) routes each student to their college’s service directory while sharing the same chat engine, same routing logic, same design system.
• Per-campus content stewardship. Each of the ten colleges identifies content stewards for their service directory and runs the same review/approval process GCC piloted in Phase 2. The district provides the platform and governance; each campus owns its own content.
• Centralized governance. A district-level steward (or small committee) ensures consistency across campuses, handles cross-cutting issues (Maricopa-wide policies, district services like the Title IX office), and manages new-college onboarding when campuses are added.
• Cross-campus analytics. Patterns visible at one campus (a routing dead-end at SCC, a high-traffic question at PVCC) inform improvements that ship to all ten. Shared learning is the main institutional case for one tool versus ten.
• Salesforce integration (optional, Scenario E from Section 08b). If the district wants to convert anonymous CopaMigo conversations into identified service cases in Salesforce, Phase 3 is when that integration gets built. Student opts in; CopaMigo passes the conversation context as a service case; the student does not have to repeat themselves to a human staff member. The anonymous funnel stays anonymous; the boundary is the student’s consented action.
• Distribution at scale. Canvas LTI rollout across all ten colleges. Syllabus statement language standardized at the district level. QR codes in physical spaces at every campus. Coordination with student government and peer mentor programs at each college.

Estimated work: Twelve to eighteen months of a district-level product team building on the GCC pilot. The architecture work (multi-tenancy, school picker, per-campus content) is substantial but tractable. The harder work is institutional: coordinating ten colleges’ worth of content stewards, governance committees, faculty senates, marketing teams, and IT departments to deploy a unified tool.

Cost framing: Multi-tenant scaling is sub-linear at the infrastructure layer because the platform is shared across colleges, but content stewardship, governance, and traffic do scale. As with Phase 2, actual numbers should come from RFP responses informed by Phase 2 pilot data rather than from PRD-time estimates. The Phase 2 pilot is what tells the district what Phase 3 actually costs.

D.5 What Stays vs What Changes Across All Phases

The design intent (Sections 01 through 13 of this PRD) is invariant across all four phases. What changes is the infrastructure underneath it. This summary is offered as a sanity check for any vendor or engineering team scoping the production work.

D.6 Where Vendor Partnerships Make Sense

The work between Phase 1 and Phase 3 is real backend, infrastructure, and operational work. CopaMigo’s design philosophy is anonymous-first and open-architecture, which is compatible with vendor partnerships in specific layers but not all of them. This subsection is offered to vendors evaluating CopaMigo as a potential collaboration.

Vendor partnerships make sense for:

• Live chat infrastructure (Phase 2). Building per-office chat from scratch is reinventing what platforms like Element 451, Intercom, or LibChat already do well. Integrating CopaMigo with an existing chat platform is straightforward and is the right buy-vs-build decision.
• Content management for the department service directory (Phase 2). A platform that already provides content workflows, versioning, approval flows, and stakeholder portals is doing work CopaMigo would otherwise have to build. Element 451 specifically and similar student communication platforms generally are good fits here.
• Analytics and engagement dashboards (Phase 2 and 3). Same reasoning. Mature student-engagement platforms have analytics infrastructure that CopaMigo would otherwise build poorly.
• Multi-tenant scaffolding (Phase 3). If the chosen vendor platform supports multi-tenancy out of the box, the Phase 3 lift is dramatically smaller than building it custom.
• Accessibility audit and remediation (Phase 2). Specialty work, contracted to a specialist firm.

Vendor partnerships are a worse fit for:

• The AI routing engine itself. CopaMigo’s design philosophy (anonymous-first, stigma-aware, route-to-humans) is specific and not the default behavior of generic CRM-grounded student service automation. The AI side is the prototype’s IP and stays in Maricopa-controlled infrastructure regardless of which vendor handles the surrounding layers. See Appendix D for the spec a vendor’s AI implementation would need to satisfy.
• The prompt and routing rules. These are institutional artifacts and live with the institution, not the vendor.
• The student-facing brand and trust layer. CopaMigo as a name and a design system is an institutional commitment. A vendor white-label that re-skins it as “AskGaucho 2.0” or “Maricopa Bot” defeats the entire discoverability strategy in Appendix A.

The cleanest vendor relationship is one where the vendor brings infrastructure, chat, content management, and analytics, and the institution brings the AI routing engine, the prompt, the design philosophy, and the brand. That split lets each side do the work they are good at and lets CopaMigo benefit from mature platforms without losing the design properties that make it different from a generic chatbot.

D.7 What the Faculty Builder Brings to Each Phase

This is included because Maricopa needs to know what role the original builder plays at each phase, and where the institutional handoff should happen. Continuity is named as a known unknown in Section 14; this subsection is the constructive answer to it.

• Phase 0 (now): Sole builder. Owns the design, the prompt, the content, the deployment, the testing.
• Phase 1 (hardened prototype): Design lead and content lead. The engineering team builds the proxy and infrastructure; the faculty builder reviews routing changes, validates that the hardened version still produces the same student experience, and runs the formal usability testing.
• Phase 2 (GCC pilot): Product owner or product partner role. Works with the engineering team, content stewards, and accessibility specialists to deliver the production version. Continues to own the routing logic, the system prompt design, and the student-facing voice. Trains content stewards in the design philosophy.
• Phase 3 (district-wide): Optional. The institutional product team owns the tool by this point. The faculty builder may transition fully out, may stay on as an advisor, or may step into a permanent product role. The succession plan is a Phase 2 deliverable.

The point of this progression is that CopaMigo does not stay tied to one builder forever. The institutional artifact, this PRD, is the design memory. Anyone with this document and the spec in Appendix D can carry the work forward.

References

• Pew Research Center. (2026, June 17). Americans and AI in 2026: Chatbots, smart devices, and views on impact. pewresearch.org/internet/2026/06/17/americans-and-ai-2026
• Alexander, B. (2026, July 6). How Americans view AI in 2026. AI, academia, and the Future. aiandacademia.substack.com/p/how-americans-view-ai-in-2026
• Kim, et al. (2024). CHI 2024. dl.acm.org/doi/10.1145/3613904.3642785
• Almogren, et al. (2024). Heliyon. pmc.ncbi.nlm.nih.gov/articles/PMC11154614
• Cavazos, et al. (2025). Teaching of Psychology. journals.sagepub.com/doi/full/10.1177/00986283241268829
• ADA Title II Web and Mobile Accessibility Rule (2024). ada.gov/resources/2024-03-08-web-rule