Privacy Policy

Last updated 30 August 2026

Ops Backroom is an operations dashboard for a business's own commerce and social-media data. It is built so that its automated pipelines never write down a shopper's name, email address, phone number or shipping address. This policy sets out what it does store, which third parties receive it, and — plainly — that data is kept until it is deleted by hand rather than on a schedule.

Who we are

Ops Backroom is operations software for small direct-to-consumer brands, built and operated by Brandon Karraa as a sole proprietor, based in California, United States. For anything in this policy, including access and deletion requests, contact bkarraa@opsbackroom.app.

In this policy, “you” means a business that uses Ops Backroom and the people it authorises to sign in. Ops Backroom is a business tool; it is not offered to consumers and is not directed at children.

What we deliberately do not collect

This is the design constraint the system is built around, so it comes first.

Your customers' identities. When an order is ingested, its commercial fields are copied across using an explicit list of permitted fields rather than by removing known-bad ones. Names, email addresses, phone numbers, billing and shipping addresses and payment details are not on that list, so they are never written to our database — and a new personal field added by a platform in future is excluded by default rather than needing to be noticed.
Payment instruments. No card numbers, bank details or payment credentials of any kind are stored. Order values are held only as whole-cent totals.
The identities of people who follow, view or comment on your posts. We request counts, never identities. No commenter handle, no comment text and no individual follower record is ever fetched or stored.
Uploaded files. Where a report is imported from a spreadsheet, the file itself is not kept — only its name, a checksum, the row count and the period it covers.

Two honest qualifications. First, where a platform sends us data by webhook, the full payload arrives at our server before it is filtered; the personal fields are discarded in memory and are never written to storage, which is a different statement from “they never reach us”. Second, these protections govern automated ingestion. They cannot govern what an authorised person types into a free-text box — see “Information you type in” below.

What we do collect

Account information

For each person authorised to sign in: an email address, an optional display name, an internal identifier and the date the account was created. Sign-in is passwordless — a one-time code is emailed to you — so we never receive, handle or store a password.

Commerce data

Orders and their line items, product and SKU identifiers, quantities, discounts, taxes, shipping charges, platform and payment fees, refunds, stock levels, inventory movements and cost inputs — all monetary values as whole cents. Two items in this category are personal data and we call them out rather than bury them:

A pseudonymous customer identifier. Each order carries the identifier the sales platform assigned to that shopper, both on the order record and in the order's stored audit copy. It contains no name or contact details and we cannot resolve it to a person, but the platform that issued it can — so it is personal data, and it is stored. It is used for one purpose only: telling repeat purchases apart from first purchases.
Refund reasons. The note a member of your staff wrote when issuing a refund is stored as written. It is free text and is not filtered, so it will contain whatever was typed.

Creator records

If you use the creator-seeding features, the system stores details about the creators you work with: social handle, name, business contact details, audience size, pipeline status, shipment tracking references and your own notes. This is personal data about third parties that you enter and control. You are responsible for having a lawful basis to record it, and for telling those people if that is required where you operate.

Customer support correspondence

If you use the support features, the system stores the email conversations your customers send to your support address: the message body, the subject, the sender and recipient addresses, and the timestamps. This is your own correspondence with your own customers — the same records your mailbox already holds — and you enter and control it, on the same terms as the creator records above.

If a store adds this product's chat widget to its storefront, the system also stores the messages a visitor types into that chat window, with their timestamps — and nothing else about the visitor: no name, no email address, no phone number, no account. A visitor can return to a conversation only through that conversation's own key, held by their browser; there is no visitor identity, and two chat conversations are never linked to each other or to anything else you know about a shopper. Where a chat needs details of an order, that order is found by an order number the visitor themselves typed, and by nothing else. The chat accepts no attachments.

We do not build a profile of anyone who writes to you. The system stores conversations, not people. It does not link a support conversation to a shopper record, does not connect two conversations from the same address to each other, and keeps no scoring, no sentiment history and no customer profile. It does classify an incoming message in one way, and that classification is written down: which kind of question the message is asking. Where a reply was drafted, the kind is kept with the draft — one of the six kinds named below, the same ones a business switches automatic replies on by. Where the message is one for a person to answer, the only thing kept is that it is. The kind stays with that one message, and nothing about a correspondent is built up across their conversations. Looking someone up by their email address is not a feature this system has. Where a reply needs details of an order, that order is found by an order number the customer themselves gave you, and by nothing else.

Replies: drafted by software, and approved by a person before they are sent. The system prepares a suggested reply to an incoming support message and holds it for your review; preparing that suggestion sends the text of the customer's message to our AI provider, so a suggested reply may be written by an AI model. Where the product is used to send replies, three things hold. No reply leaves unless a person you have authorised approves that exact message, and what was approved is exactly what is sent. A reply can go only to the address that wrote in on that conversation: the product cannot send to a looked-up address, a typed-in address or a list, and it sends no marketing or bulk email of any kind. And every sent reply is recorded — what was sent, when, and who approved it.

Automatic replies, for the kinds of question a business switches on. Sending a reply that nobody has read first was authorised in writing on 30 August 2026, and the part of the system that does it was built on 31 August 2026. No reply has been sent that way yet, because it can only happen where a business has both turned reply sending on and switched a kind of question on, and none has. It works like this. A business may switch on particular kinds of question by name — order status, shipping and delivery, returns and refunds, product usage, ingredients and safety, and account or order changes — and only for a kind it has switched on may a reply be sent without a person reading that specific message first. Skin reactions and medical questions can never be switched on, and they go to a person always, as does anything the software cannot confidently place; a customer can always reach a person. The record of such a reply names the automatic mechanism and the switch it acted under, never a person as the approver, so a reply nobody read is never presented as one somebody reviewed. Everything else above still holds: only the address that wrote in, only email, no marketing and no bulk mail. Such a reply also says so in its own text: it tells the customer it was sent automatically, that nobody had read it, and that replying will reach a person.

Replies in a storefront chat window, where a business installs one. Showing a reply to a visitor inside a chat window on a business storefront was authorised in writing on 30 August 2026, and the system can now do it. A reply drafted by software may be shown to a visitor — but only after a person at that business approves that exact message, and what was approved is exactly what is shown. A chat window appears on a storefront only where that business installed it and switched it on, and turning it off takes effect at once. A reply is shown only inside the conversation the visitor themselves opened. The software does not speak first: it composes nothing for a visitor who has not written. It cannot send email, a text message, or anything else to an address a visitor types into the window, and it cannot carry a reply to any other conversation, list, or place. Every reply shown is recorded — which conversation, who approved it, what was shown, and when.

Automatic chat replies, for the kinds of question a business switches on. Showing a chat reply that nobody has read first was authorised in writing on 31 August 2026; the part of the system that would do it is not built, and no reply has ever been shown that way. When it is built, it will work the same way as automatic email replies: only for a kind of question that business has switched on by name, with the same one set of switches covering both email and chat; skin reactions and medical questions can never be switched on and go to a person always, as does anything the software cannot confidently place, and a visitor can always reach a person. The record of such a reply names the automatic mechanism and the switch it acted under, never a person as the approver, and the window never presents it as reviewed by a person. Everything else above still holds: only the conversation the visitor themselves opened, only where the business installed the window and switched it on, never speaking first, and never to any address a visitor types.

For each connected account we store: follower and following counts, post and video counts, and per-post metrics such as views, likes, comment counts, shares, saves, reach, watch time and interactions. We also store the caption text of those posts — copy that was written and published publicly — along with the post's link and short descriptive labels derived from the caption. For Instagram we additionally store the aggregate audience statistics the platform provides: age bands, gender split, countries, cities and hours of activity, each as bucket counts.

The spoken words in your published videos. For Instagram Reels published by a connected account, we fetch the video file the platform serves, convert its speech to text, and store that text. The video file itself is never stored: it is fetched, transcribed and discarded within a single run. Alongside the text we store three numbers per video: how many milliseconds into the video the first speech begins, how likely the transcription service thinks it is that the video contains no speech at all, and how many seconds of audio the video holds, which is what that service charges us for. We do not request speaker labels, or any separation of one voice from another, so the stored text does not record who said which words, and no other position inside the video is kept — not who spoke when, not where one voice stops and another starts. A reel you published may contain other people's voices; the transcript is held as part of your own published work, on the same footing as that post's caption, and the rights set out below reach it.

What your published videos show. For those same Instagram Reels we also fetch the video file, take a handful of still frames from it, and store one short structured description of what the frames show: what the opening frame shows and how it is framed, how the video is shot across the frames, the setting, whether on-screen text appears, how visibly the product features, the video's format, and a one- to two-sentence summary of what happens. The frames and the video file are discarded within the run that made them — no image is stored. The model producing the description is instructed not to identify or name any person and not to describe anyone's age, gender or other characteristics, and where a person appears they are described only generically, by what they are doing. Like the transcript, the description is held as part of your own published work, and the rights set out below reach it.

The words written on your published videos. Alongside that description we store one further thing, and it is a copy rather than a characterisation: the text overlaid on the video's opening frame, transcribed word for word. That means the caption, sticker or title card added when the video was edited — not text that was simply in shot, such as writing on clothing, on packaging or on a sign, which is never transcribed. Because it is a transcription rather than a description, we cannot promise it names nobody: a reel you published may carry a name, a handle or someone else's words written on the screen, and removing them would mean first working out that a person is named, which is itself the kind of inference we do not make. It is held on the same footing as the transcript of what is said and as that post's own caption — part of your own published work — and the rights set out below reach it.

A connected account is not always the brand's own. Where a creator collaborates on posts with a brand, the platform serves those posts only to the account that published them, so the creator may connect their own account in order for their collaboration posts to be measured. When that happens we store the metrics, captions and links for the posts of that account that fall within the agreed scope, and the dashboard labels each item with the account that published it. That connection is authorised by the creator themselves and they can withdraw it at any time from within Instagram. Scope is agreed in advance; it is not a licence to read an account in full.

Those audience statistics are supplied to us already aggregated and we never receive any individual follower's identity. We do note, for accuracy, that a bucket can be small — a city may show a count of one — so we describe the data as aggregate rather than as anonymous.

Information you type in

Several parts of the dashboard accept free-text notes: creator notes, marketing-spend notes, cash-position notes, social snapshot notes, reconciliation notes, inventory references and tracking numbers. These are stored exactly as entered and are not filtered or inspected. If personal information is typed into one of them, it will be stored.

Imported conversation archive

A signed-in person can import the conversation archive that claude.ai exports for them, so that their own past conversations with the Claude assistant become searchable inside the product. What is stored is the text of those conversations: the messages that person wrote and the replies the model wrote, each with its date and the name of the conversation it belongs to. The only two speakers in such an archive are the account holder and the model — importing it stores no third party's messages — and inside the product an imported archive is visible only to the account that imported it, not to the other people authorised on the same dashboard.

Part of the archive is removed in your browser, before anything is uploaded. The archive file itself never leaves your machine: it is unpacked there, and only the extracted messages are sent. Attached files and documents are not imported at all. The model's internal reasoning and its tool activity are counted by type and discarded — only the text of the messages themselves is kept. And that text is scanned for credentials of recognised shapes — API keys, access tokens, private keys — each of which is replaced with a named marker before upload. The scan looks for known credential formats; it is not a guarantee that every secret is caught.

When the product's built-in analyst searches or reads an imported archive, the excerpts it retrieves are sent to our AI provider, the same way as the other stored records its tools read (see “Who else receives data” below). And unlike most of what this policy describes, the archive can be deleted without asking us: removing an import takes it out of search immediately and can be undone, and deleting it permanently erases its messages from the database. It is kept until the person who imported it does one of those.

Technical information

Our hosting provider records standard server information for requests to the site, including IP address and user agent. This is platform-level logging outside the application itself.

Cookies

The application sets only the strictly necessary cookies its authentication library uses to keep you signed in. There is no analytics, tracking or advertising cookie, no third-party script, no advertising pixel and no telemetry of any kind in the front end. Web fonts are bundled and served from our own domain, so viewing the site makes no request to a font provider. The public pages you are reading now set no cookie at all and require no session.

Who else receives data

We do not sell data, do not share it for advertising, and do not use one business's data to inform or benchmark another. Data reaches the following service providers because the product runs on them:

Supabase — the database and authentication provider. Everything the product stores is stored there.
Vercel — application hosting. Receives every request to the site and runs the scheduled jobs.
Anthropic — the provider of the Claude AI models behind the product's classification, drafting and analysis features; where this policy says “our AI provider”, this is who is meant. Each feature sends the text it works on. A daily job sends the text of published post captions to the Claude API to classify them by hook, theme and call-to-action — the captions of every account we track, including a collaborating creator's — one caption per request as the only content in it, with no customer data, no account details, no order data and no metric value alongside it. A sibling daily job sends the stored transcript of a published Reel — the spoken words described above — on the same one-item-per-request terms. A third daily job sends a handful of still frames taken from each published Reel — images sampled from the video described above, never the video or its audio — and receives back the stored description of what the Reel shows. Where the support features are in use, preparing a suggested reply sends the text of the customer's own message, together with the business facts a reply needs: your business profile, your stored policy answers, and the details of an order found by an order number the customer themselves gave (see “Customer support correspondence” above). And the remaining features send what they read in order to answer: a narrated report sends the stored figures it narrates, the research features send the public web text they review, and the built-in analyst sends what an authorised person asks it, along with the stored records its tools read to reply — including, for a person who has imported one, excerpts of the imported conversation archive described above.
OpenAI — the speech-to-text provider (its Whisper transcription service). Audio reaches it in two cases, and in both what comes back is text. The daily job described under “The spoken words in your published videos” sends it the video file of each published Reel and receives the transcript and the single first-speech timing that section sets out. And when a person uses the dashboard's voice dictation, the recording of their own dictated speech is sent and the recognised words come back onto their screen. We keep no copy of the audio in either case: a Reel's video file is discarded within the run that fetched it, and a dictation recording is never written to storage. Nor are the dictated words — the text is returned to the person who spoke it, and what is kept of a dictation is a meter row (its duration, its size, the time, and which provider transcribed it) used to enforce a daily limit.
Meta (Instagram) and TikTok — the platforms whose accounts you connect. We send the access token you granted and receive the analytics described above.
Shopify — where the commerce integration is configured, we send an API credential and receive order data, stock levels and product costs.
Brevo — the email relay, and the one service provider here that is not in the United States: it is a French company and hosts in the European Union. Two things reach it. It relays the sign-in email containing your one-time code, and therefore receives the email address requesting it. And where you have asked to receive the daily brief, it relays that too — so it receives the address it is sent to and the figures the brief contains. It receives no order data and no customer data. It does receive figures derived from connected platforms: the brief carries each connected social account’s follower count, read from the Instagram and TikTok APIs.

We may also disclose data where we are legally required to do so.

When you connect Ops Backroom to another application

You can connect Ops Backroom to Claude as a custom connector, so you can ask about your business inside your own Claude conversations. This is the one place where data leaves us because you asked for it there, rather than because we sent it to a provider we chose — and the distinction matters, because the list above does not cover it.

Nothing moves until you approve it. Connecting shows you a consent screen naming the application and where the approval goes. Until you approve, the connection can read nothing. You can withdraw it at any time from Settings, under Connected applications, and withdrawing takes effect immediately.
What it can read. The figures your dashboard screens compute, the definitions behind them, and the industry benchmarks and research findings this product has adopted. It reads them through the same code the screens themselves use, so the numbers are the numbers you see. It can also search your research documents — the long-form written record behind those findings — and quote passages back to you. If you switch it on in Settings, it can also read short notes the Studio has written about how you work, derived from conversations you imported; the conversations themselves stay unreadable to it either way, and notes about your life rather than your work are never shared. It reaches the email addresses of the people you have authorised on your own business, because the inventory movement log names who entered each row.
What it cannot read. Your studio conversations, any chat history you have imported, your support threads and the messages inside them, and the platform access tokens for your connected accounts. It cannot run its own database queries, and it cannot write, change or send anything.
This product's own engineering documents. An account holding the repository-documents grant — given only to someone who can already read this product's source code — can also search and read the product's own engineering documents through the connector. Those documents can quote material the list above says the connector cannot read, so for that account the list holds for everything outside them. No other account can see, list or call that part of the connector.
Where it lands, and whose terms apply. What the connector reads goes into your Claude account, under Anthropic's terms with you and your own data settings there — including whatever you have chosen about training. That is you pulling your own data into a service you hold an account with, which is not the same relationship as the providers listed above, where the provider processes data on our instructions and under our contract. We cannot see your Claude conversations, and connecting does not give us any access to your Claude account.

How long we keep it

Commercial records — orders, line items, quantities, money — are kept indefinitely, until deleted on request. The historical series the dashboard depends on are designed to accumulate rather than roll over, so there is no expiry on them.

Personal data has a retention period of 24 months, and it is enforced automatically. A daily job removes the pseudonymous customer identifier — from the order record and from its stored audit copy — and the refund reasons your staff typed, once they are older than that. The order itself survives the purge entirely: what is removed is the ability to link it to a shopper, which is the only purpose that identifier ever served. Twenty-four months is set by the longest customer analysis the dashboard performs, not chosen for roundness.

The original of a support email is kept for 30 days, and then only the readable conversation remains. Incoming support mail is normally stored twice: once exactly as it arrived, and once as the readable message shown on screen. A daily job erases the original after 30 days — matching how long the mail provider itself keeps it — so nothing is held in that form for longer than the service it arrived through would have held it. The conversation you and your customer can both read is kept, so the history of what was asked and answered survives.

There is one case where a message is stored once rather than twice. Occasionally an email arrives that we cannot read — malformed, damaged in transit, or missing the sender address a reply would need. There is no readable version of it to keep, so we hold only the original, exactly as it arrived, and the same 30-day erasure applies to it. After that, what remains is the fact that something arrived on that date and could not be read. We keep it that way so an email to you is not silently lost while we work out what went wrong with it.

Access tokens are the exception: they are refreshed in place and cease to work when they expire or when you revoke them at the platform.

Your rights over this data

Four things you can ask for — to see what we hold, to have it corrected, to have further processing restricted, and to have it deleted. How each one works, and what survives a deletion, is set out on Data rights and deletion. The short version:

Email bkarraa@opsbackroom.app and we will action it manually. We describe it that way deliberately: with one exception, there is no self-serve deletion button in the product, so a request is carried out by hand against the database rather than by a feature. The exception is the imported conversation archive described above — the person who imported it can remove it, restore it, or delete it permanently themselves, from inside the product. We aim to respond within 30 days.

You can also cut off future collection yourself at any time, without involving us, by revoking Ops Backroom's access in your Instagram, TikTok or Shopify settings. That stops new data arriving; for Instagram and TikTok it does not remove what has already been stored. Shopify is the exception: uninstalling the app makes Shopify send us a shop-data erasure request 48 hours later, and we action it automatically — the store's orders, its credential and its registration are deleted, and a receipt of what went is kept. The same automatic path actions a shopper's erasure or data-access request that Shopify forwards to us on a merchant's behalf.

Removing a person's sign-in access is immediate. Note that records they created — a note they wrote, a movement they logged — remain, with the authorship reference cleared, because deleting them would silently change historical figures.

How it is protected

Sign-in is by emailed one-time code. There are no passwords to leak, and public sign-up is disabled — an account has to be created for you.
Every database table enforces row-level security, so an unauthenticated or unauthorised request returns nothing rather than returning data.
Platform access tokens live in a dedicated table that no client-side credential can read: it carries no access policy at all and every client privilege on it is revoked. The administrative database key never appears in anything served to your browser, and an automated test fails the build if it does. Server-side jobs that need it — the order webhook and our operational scripts — run only on our own infrastructure.
Scheduled jobs authenticate with a bearer secret compared in constant time.
Data is encrypted in transit, and at rest by our hosting providers. We do not apply an additional layer of application-level encryption to stored tokens — they are protected by the access controls above.

One limitation worth stating rather than glossing: access to a business's dashboard is currently all-or-nothing. Anyone you authorise can see all of that business's data; there are no per-person roles or partial views. Authorise accordingly.

International transfers

Ops Backroom is operated from the United States and the service providers listed above process data in the United States and elsewhere. If you are outside the United States, using the service involves transferring data there.

Changes

If this policy changes we will update the date at the top of this page, and we will tell users directly where the change is material. Continuing to use the service after a change means you accept the updated policy.

Contact

bkarraa@opsbackroom.app — or see the Terms of Service.