The Missionary Assistant—also referred to in team conversations as the Missionary Chatbot or Service Missionary Chatbot—is an emerging conversational tool created to help service missionaries quickly locate accurate, current guidance they need to support BYU‑Pathway Worldwide students. At present, missionaries must hunt across multiple websites, PDFs, slide decks, Help Center articles, and internal reference pages; this fragmentation leads to delays, uneven answers, and added training burden. The Missionary Assistant addresses that fragmentation by drawing from the same distributed knowledge sources and returning a concise answer with a reference back to the originating source, so the missionary can review and confidently pass information to a student or escalate when needed. 

The primary objective is to give missionaries a single conversational entry point that surfaces authoritative instructions, deadlines, and process steps without requiring them to navigate “5–6–7 different sites” for every question. In day‑to‑day service, missionaries field recurring topics: how to submit tickets, key academic or term due dates, and what steps students must complete for tasks such as registration or adding items to a calendar. By centralizing this information:

• Response times to student questions should improve because the searching overhead drops.

• Guidance becomes more consistent when answers are anchored to shared source material.

• Training time for new missionaries is reduced; they do not need to memorize where everything lives before being useful.

• Students receive faster, clearer next steps, improving their overall support experience. 

Missionaries interact with the Assistant through a stand‑alone website (currently outside the Companion mobile + web product). That site has been gradually “enriched” with additional content, but has also been described as heavy to load and use—an important consideration given the bandwidth constraints common in the global areas where missionaries serve.

The underlying knowledge base is “fed” with the scattered materials missionaries currently rely on: multiple program web properties, PDFs, PowerPoint job aids, Help Center content, and EnglishConnect / InSite resources. When a missionary asks a question, the Assistant returns a brief, actionable answer and indicates the source document or page so the missionary can verify context.

Common queries discussed by the development team include: “How do I submit a ticket?”, “What are the due dates for a given term (e.g., Term 5)?”, and “What steps does a student take to register or add deadlines to a calendar?” 

Looking ahead, the Missionary Assistant could evolve into a role‑aware, responsive support layer that recognizes the user as a missionary (not a student), tailors language accordingly, and walks the user through student‑support processes step by step. Instead of simple lookup answers, it could guide missionaries through structured workflows: confirm the student’s program, surface the correct policy window (e.g., add/drop, payment due), and generate a ready‑to‑share summary that the service missionary can send to the student.

A future version could also include lightweight case capture: when the missionary asks a question tied to a student issue, the Assistant could prompt, “Would you like to create a ticket?” and prefill relevant fields. Over time, aggregated anonymized interactions could surface trending student pain points (e.g., repeated confusion around registration steps in certain regions), informing program improvements.

Localization hooks would matter at scale: the Assistant could expose region‑specific instructions or language variants where policy, deadline timing, or access to systems differ. 

Some program directors have expressed interest in evaluating whether the Missionary Assistant should eventually live inside Companion (the mobile + web ecosystem used for student support features now in beta). This idea is under consideration only; it has not been discussed in depth with the development team, and no decision, resources, or timeline exist.

Potential advantages to explore:

• Unified access: Missionaries who already guide students in Companion could access their support tools in the same environment.

• Shared low‑bandwidth design: Companion is being engineered for constrained connectivity; migrating the Assistant could reduce the “heavy website” pain.

• Role detection: Companion authentication could help distinguish missionaries, students, and possibly mentors, reducing role confusion in answers.

• Shared content services: Central content pipelines (updates, localization, policy refresh) could serve both student‑facing and missionary‑facing assistants, improving consistency.

• Telemetry in one place: Usage, response quality, and top topics could roll into Companion analytics, giving leadership clearer visibility.

Again: these are evaluation points, not commitments. Stakeholder alignment would be required before any design or build effort begins. 

Current missionary support work is slowed by fragmented information spread across many systems. Even experienced team members report spending too much time opening multiple pages to confirm routine answers. Inconsistent or outdated guidance can frustrate students, delay problem resolution, and increase escalations. A consolidated, conversational layer reduces that friction, helps standardize what missionaries share, and shortens the learning curve for newly called volunteers. As BYU‑Pathway programs scale globally, reducing support variance becomes a strategic enabler of quality and reach. 

Although formal analytics are not yet implemented, ongoing weekly feedback and the like/dislike mechanism have already improved answer quality—especially in correcting role mix‑ups. Service missionaries report that having a fast lookup tool reduces time spent navigating multiple sites. Establishing basic telemetry (query volume, top topics, percent of answers rated helpful, time to resolution when paired with ticketing) will be important for demonstrating scaled value to leadership.