Frequently asked questions

No. The solution is deployed behind the university firewall on institution-controlled hosting. All data processing occurs within your environment—either on-premises or in your cloud infrastructure (Azure, AWS, etc.). We never host student data on our servers. You maintain full control of the infrastructure, updates, and data retention.

Two main options: (1) On-premises deployment—you host the Docker container on your own infrastructure with full control. (2) Your cloud account—deployed in your Azure/AWS/GCP account, managed by your IT team. Both options keep data within your firewall. We provide the container package, configuration templates, and runbook documentation; you maintain the hosting environment. No data ever touches our servers.

Yes. Because the solution runs entirely within your environment, FERPA compliance follows your existing institutional policies. We don't access, store, or process student data externally. The bot operates under your data governance—same as any other internal system. Conversation logs and tickets stay in your Freshservice instance and your local deployment. We can provide documentation for your compliance review.

Identity is sourced from the portal session context. When a student is logged into your portal (Jenzabar, Ellucian, or custom), the widget receives authentication context via portal-auth headers or session tokens. Students do not re-enter credentials. We support SAML/OIDC flows through your existing portal authentication. The bot uses this identity to personalize responses and associate tickets with the correct student record in Freshservice.

No. It enhances Freshservice by collecting clean intake and creating structured tickets. The bot acts as a front-end that guides students through troubleshooting, then creates well-formed tickets in Freshservice when escalation is needed. Your agents continue using Freshservice as their primary tool—they just receive better-quality tickets with more context.

We use a dedicated Freshservice API service account with scoped permissions: Create Ticket, Add Private Note, and Read KB/Solutions articles. We do NOT request: read access to existing tickets, delete permissions, admin operations, or access to other modules. All API access is logged and auditable. We recommend testing in Freshservice Sandbox first before production deployment.

We use retrieval-augmented generation (RAG)—NOT model training. Here's what that means: We sync your approved Freshservice Solutions articles into a local retrieval index that runs inside your environment. When a student asks a question, the bot searches this index and grounds its response in your approved content. We do NOT train AI models on student messages or ticket data. Your KB articles never leave your network. You control exactly which Solutions categories to include or exclude from the index.

No. We explicitly do NOT train models on student conversations or ticket data. The bot uses retrieval-augmented generation (RAG) to find relevant answers from your approved KB articles—it doesn't learn or adapt from individual conversations. Model improvements come from our development process, not your data. If you want to improve bot responses, you update your KB articles—the bot will immediately use the new content.

Yes. The pilot is free and designed to prove value quickly. Day 0-30: Launch with 2-3 core flows (MFA, Wi-Fi, Email). Day 31-60: Measure deflection, optimize scripts, expand KB coverage. Day 61-90: Add new categories, refine routing, finalize long-term pricing. Success metrics include deflection rate, time-to-intake reduction, and ticket completeness improvements. No commitment required to proceed after pilot.

Pilot launches typically take 2-4 weeks from approval. We need from your team: (1) Portal access details for widget embedding, (2) Freshservice Sandbox API credentials, (3) Top 3-5 issue types to configure first (e.g., MFA, Wi-Fi, Email), (4) Your branding/colors for the widget, (5) A technical contact for integration questions. Week 1: Setup and configuration. Week 2: Testing and refinement. Week 3-4: Soft launch with limited user group, then full rollout.

Minimal ongoing effort. Your team is responsible for: (1) Hosting infrastructure (standard Docker maintenance), (2) Updating KB articles when procedures change, (3) Monitoring the admin dashboard for issues. We provide: runbook documentation, update packages, and support for configuration changes. Most updates are simple config file changes or container pulls—no custom development required.

We use department-level flat pricing, not per-agent or per-user fees. This means your cost stays the same whether you have 3 agents or 30. Pilot: $0. Full implementation: starts at $15K (one-time). Ongoing support: starts at $2K/month. Final pricing depends on scope, number of flows, and support level. We'll provide a detailed quote after the pilot assessment.

Cancel anytime with no penalties. Since the solution runs in your environment, you retain full control. If you cancel ongoing support, you keep the deployed system—it just won't receive updates or support. Prorated refunds are available per your MSA terms. No long-term lock-in contracts required.

No. We offer flexible terms: month-to-month for ongoing support, or annual agreements with modest discounts. Most institutions start with a pilot, then move to annual support agreements after proving value. We don't require multi-year commitments—we'd rather earn your renewal each year.

Support tiers include: (1) Email support for configuration questions and troubleshooting, (2) Quarterly check-ins to review metrics and optimization opportunities, (3) Access to update packages and security patches, (4) Documentation and runbook updates. Premium support options include dedicated Slack channel, faster response SLAs, and proactive monitoring assistance.

Updates are delivered as new container versions or configuration patches. Your team pulls the update from our private registry and deploys using standard Docker commands. We provide release notes, migration guides, and rollback procedures for every update. You control when updates are applied—we recommend testing in sandbox first. Security patches are flagged as urgent with expedited documentation.