Security & data

01Where the data lives

The application runs on Postgres hosted by Supabase, which also provides authentication, file storage and the server-side functions the app calls. Data is hosted in the United States. Encryption is in transit (TLS) and at rest.

The marketing site you are reading is a separate static site and holds no customer records. The application is at app.btrrep.com.

02How access is enforced

Every table is protected by row-level security policies evaluated by the database on each query, written against the roles the app knows: rep, manager, QA, QA manager, admin and superadmin. The interface hides what a role shouldn't see; the database refuses to return it. That distinction matters — an interface-only permission model is one browser console away from not being a permission model.

• Reps see their own accounts, their own coaching, their own training.
• Managers see their own crew, and the errors flagged against their own reps.
• Quality agents see their own queue. Not the whole company's.
• Admins see the operation. Superadmins see across brands.
• Tab-level control lets an administrator grant or revoke individual areas of the app, per role and per user, without a deploy.

03Authentication

Sign-in is email and password, handled server-side by Supabase Auth. There is no SSO and no magic-link login today. Sessions carry expiring access tokens that refresh in the background, and every write retries against a refreshed token — so a long shift doesn't end with silently lost work. Server-side functions verify the caller's token; none of them accept an anonymous request.

04Customer-facing email

BtrRep sends confirmation email to customers in exactly one circumstance: a quality audit found that a service change was never communicated. Sending is restricted to named senders, the content is drawn from the operator's own morning report, and the reply path goes back to the operator's quality inbox — never to BtrRep.

05AI features

Sage and the roleplay customer run behind authenticated server-side functions. Sage answers from the brand records in your library rather than from model recall, so an answer changes when the record changes. Session access is tied to a real login, and the roleplay usage cap is enforced server-side.

06Backups and continuity

The database is backed up on Supabase's managed schedule. Board and dashboard displays are static reads — if one goes down, nothing about the underlying records is affected.

07Your data is yours

Customer records originate from your own service-system exports — RealGreen, ServiceTitan, PestPac, Jobber and the like. You own that data; BtrRep is a processor of it.

BtrRep does not sell customer data, does not use your operational data to train models for anyone else, and does not share it between operators. If you leave, you get a full export of your records in an open format.