Working with Bevel

We meet with the core stakeholders. The goal is to deeply understand institutional priorities, current workflows (e.g., revision cycles, quality reviews, accreditation prep), and what success looks like for your team. By the end of the call, the team is onboarded and has sandbox access in hand.

This gives us enough context to set up a sandbox that best maps to your workflows and goals.

Your team gets access to a Bevel sandbox environment. We preload representative sample course content so the team can test real workflows from day one. If there's interest, we can also upload a sample of your own content (via .imscc package).

• -No LMS integration required
• -Representative sample content preloaded
• -Test key Bevel workflows yourself

The sandbox is meant to be a low-lift way to find the best way to use Bevel for your institution.

Stakeholders reconvene to discuss what the team found. We talk through feedback, and whether there's a clear, contained use case worth running a pilot on. If there's mutual alignment, we start scoping what that pilot looks like.

Bevel will draft a scope document based on conversations as a starting point. We then work through it together to land on something realistic and well-defined, with clear success criteria.

• -Number of seats
• -Courses included
• -Specific workflows to test
• -Clear success criteria, defined up front so the evaluation is objective

We iterate on scope until it feels appropriately sized and aligned with your institutional goals. Once we're aligned, we'll finalize the scope document.

Our CTO leads a technical diligence call alongside your IT or security team. We come prepared with documentation and answer questions directly. Read more here.

• -SOC materials (as applicable)
• -HECVAT
• -Security architecture overview
• -Data handling practices

Most institutions clear technical diligence in a single session between Bevel and your IT team.