Running a Cypher LM Account as an Administrator

This path is for whoever holds the account administrator role on Cypher LM — usually a founder, an operations lead, or an IT contact responsible for the account itself rather than any single agent. It covers team and roles, plans and usage enforcement, security posture, integrations, and keeping agents and knowledge consistent across the whole organization, all of which live under Settings or close to it in the dashboard.

Day to day, individual teammates work inside Agents, Calls, Bookings, or Copilot, focused on their own slice of the business. The admin's job sits a level above all of that: deciding who can access what, which plan the account is on and what that plan actually limits, which integrations are connected and why each one is there, and whether the organization's agents and knowledge are actually staying consistent as the team and the number of agents grow over time. None of this requires deep technical knowledge to do well — it mostly requires checking Settings on a regular cadence rather than only when something visibly breaks.

It is worth thinking of the admin role as closer to ongoing maintenance than a one-time setup task. An account configured carefully at launch can still drift over months — a plan that no longer matches usage, an integration that was connected for a project that ended, a role that was never revoked after someone left the team. Treating these as a short, recurring routine rather than a reaction to a problem is what actually keeps an account healthy as the organization using it grows.

The rest of this path works through each of these in turn: team and roles, plans and enforcement, security, integrations, and finally the ongoing work of managing agents and knowledge across the whole account. Each lesson stands largely on its own, so an admin returning to this path later can jump straight to whichever area needs attention that week.

None of this is meant to replace the judgment of whoever actually runs the business day to day. An admin's role is to make sure the account itself — access, plan, security, integrations, consistency — stays in good shape so that the teams actually using Cypher V, Cypher S, Cypher M, Cypher N, and Cypher P can focus on their own work without being slowed down by something that should have been caught earlier at the account level.

This path is written so an admin can return to any single lesson later as a quick reference, rather than needing to read the whole thing again whenever one specific question comes up — a new hire asking about roles, a plan question before a busy season, or a check on which integrations are actually connected right now.

Settings > team & roles is where the admin controls who has access to the account and what they can actually do once inside it. As an organization adds people, this is the first thing worth setting up deliberately, since the default of granting broad access to everyone becomes a real risk once the account holds customer call recordings, payment configuration, and a full history of every contact the business has ever spoken with.

Assign roles based on what a person's job actually requires, not on what is simplest to set up in the moment. A support or sales rep typically needs Calls, Contacts, Notes, and Copilot; a manager typically also needs Agents, Analytics, and Automations layered on top of that; full Settings access — integrations, payments configuration, plan management — should stay limited to the admin and anyone directly responsible for the account's technical setup. Review roles whenever someone's responsibilities change or when they leave the team entirely, not only when they first join and get set up for the first time.

A simple habit that keeps roles from drifting over time: once a quarter, open team & roles and check that every listed person's access still genuinely matches their current job. Accounts that skip this step tend to accumulate stale access quietly — a former employee whose access was never formally revoked, or someone whose role changed six months ago but who still carries permissions left over from their old position, unnoticed until an audit or an incident forces the question.

Roles are also where the organization's plan interacts directly with its people — some plans limit how many team members or agents the account can run at once, which is worth understanding alongside roles rather than as a separate, disconnected topic, and is covered in more depth next.

When a new department starts using the account for the first time — say a recruiting team joining an account that was originally set up for sales — it is worth reviewing roles for that whole group together rather than one person at a time, since departments often share a similar access pattern and it is easier to get the pattern right once than to correct several individual accounts later.

It also helps to write down, even briefly, why a particular role was given a particular level of access — a note that a given manager has Settings access because they also handle integrations, for instance. That small bit of documentation saves real time later when someone else is reviewing roles and trying to work out whether a given permission still makes sense.

Every account starts with a 7-day free trial, giving a new organization time to build and genuinely test an agent before committing to a paid plan. Once the trial ends, the account moves to whichever plan it has chosen, and Settings is where the admin can review which plan is currently active and what exactly it includes, rather than relying on memory of what was selected at signup.

The Basic plan specifically includes Cypher V only — meaning scheduling, copilot, notes, and payments features tied to Cypher S, Cypher M, Cypher N, and Cypher P respectively are not part of that tier. If a team on Basic expects one of these features to be available and it is simply not showing up anywhere in the dashboard, the plan itself is the first thing to check before assuming something elsewhere is misconfigured or broken.

Usage enforcement applies across every plan, meaning the account is held to real limits rather than operating on a loose trust basis that quietly expands over time. As the admin, it is worth checking in on usage periodically rather than being surprised by it later — particularly ahead of a busy period such as a product launch, a hiring push, or a marketing campaign that will clearly drive a spike in call volume, specifically to confirm the current plan can actually support that increase comfortably.

If the team outgrows its current plan — more agents are needed, or features from a higher tier become genuinely necessary, such as Cypher S or Cypher M for a team that started on Basic — this is a Settings-level decision for the admin to make deliberately, not something an individual teammate should need to work around informally by improvising with whatever access they already have.

Keep a loose record of why the account is on its current plan and what would trigger a change, so the decision does not have to be re-derived from scratch each time usage patterns shift or the team grows. This is particularly useful when ownership of the admin role itself changes hands, since the next admin inherits the reasoning along with the account.

It is also worth checking the plan right after any major change to the business — a new product line, a new team being added, a marketing push expected to drive a surge of inbound calls — rather than waiting for enforcement to signal that a limit has actually been reached in the middle of something time-sensitive.

Cypher LM is built with security in mind — the platform has been through a hardening pass covering secrets handling, request origins, and security headers. As the admin, the practical takeaway is less about any single technical detail and more about your own ongoing responsibilities: keeping login credentials and any connected integration keys private, reviewing team access regularly as covered earlier in this path, and not sharing admin-level Settings access more broadly across the team than is actually necessary for people to do their jobs.

Where the account connects third-party services — Google integrations, a Stripe key for payments — those connections carry their own ongoing responsibility beyond the initial setup. Only connect integrations the organization actually needs for its current workflows, and review what is connected under Settings > Integrations periodically rather than simply assuming a connection made months ago by someone who has since left is still necessary or still correctly configured.

If the organization has specific compliance or security requirements beyond what the platform provides out of the box — particular to your industry, your region, or a specific client contract — that is worth evaluating directly against your own actual requirements rather than assuming any single platform feature automatically covers it for you. The honest summary for an admin is straightforward: the platform takes security seriously as an ongoing practice, not a one-time checkbox, and the admin's own habits around access and credentials matter just as much as anything the platform does on its own behind the scenes.

Treat any credential rotation, such as updating the Stripe key or reconnecting a Google integration, as an opportunity to also review who currently has access to that credential, rather than simply swapping the value and moving on without a second look.

It is also worth having a simple, agreed process for what happens if a credential is ever suspected to be compromised — who to notify, which integration to disconnect first, and how quickly a replacement key can be issued — so that moment does not have to be figured out for the first time under pressure.

None of this needs to be elaborate for a small organization. Even a short written note — who holds admin access, which integrations are connected and why, what to do if a key needs rotating — is enough to keep security posture from depending entirely on one person's memory, which is the same principle that applies to roles and to knowledge files elsewhere in this path.

Settings > Integrations is where the admin connects the services agents and teammates rely on every day. Google integrations cover Calendar and Meet sync, needed for Cypher S to book real appointments with working video links, Gmail send-as-user, used for sending recaps and follow-ups on the business's behalf, Google Docs, Google Sheets, and Drive-to-knowledge-base import for keeping agent knowledge current. A Stripe key connects card payments for Cypher P; without it connected, payment requests fall back automatically to manual instructions such as bank transfer, JazzCash, or Easypaisa instead.

Check integrations whenever something that depends on them stops working as expected — a booking not syncing properly to Google Calendar, a recap email not sending out, a payment link not generating a card option when it should. These are almost always an integration connection issue rather than a problem with the agent's own configuration, so Settings > Integrations is the first place to check, not the agent itself or its knowledge files.

A periodic admin checklist

• Confirm Google and Stripe integrations are still connected and working
• Review team & roles for anyone whose access no longer matches their job
• Check the current plan against actual usage and upcoming needs
• Review Automations toggles — recap email, booking confirmation, reminders, receipts
• Spot-check agents' knowledge files for anything outdated across the organization

That last point, knowledge files, is worth owning at the admin level even if individual teams manage their own agents day to day, because outdated or duplicated knowledge spread across multiple agents is exactly the kind of problem that compounds quietly over months without anyone noticing until a customer gets a wrong answer. Periodically open each agent in Agents and check its knowledge files are genuinely current, and that agents serving similar functions across the organization are not slowly drifting apart in tone or behavior from one another over time.

As the organization adds more agents — a sales agent, a support agent, a recruiting agent, each built by a different team — the admin is often the only person positioned to notice when they start drifting apart in ways that matter to the business as a whole, such as inconsistent tone or conflicting policy answers across departments. A short review across all active agents, even twice a year, catches far more than waiting for a customer or a teammate to flag it.

For a deeper look at keeping a growing team's agents, playbooks, and knowledge consistent as more people get involved in building and maintaining them, continue to the enablement path in the Learning Hub, or open Settings directly in the dashboard to review the current state of your account right now.