How can support answer a question that depends on one customer's data and on your code?

Support answers grounded in your code base and production data

ReplyPen for B2B SaaS reads a read-only view of your production database, your source code and your help center, then drafts the reply where the conversation already happens. It is built for the questions a help article cannot answer because the answer depends on one customer's rows: why this invoice shows this amount, why this job did not run. By default nothing is sent and nothing is changed without a person.

A patient asks why she was charged for a cleaning she cancelled. A help center in a chat box retrieves the policy page and offers a human. ReplyPen finds her appointment, applies the practice’s own rule and quotes the fee your code computes. Most support questions are like this: each an edge case too rare for its own screen, and until now only a person could combine the sources.

What does ReplyPen read?

  • Your production database, through a stripped-down, read-only view: only the tables and columns you declare, PII masked by column, rows filtered per tenant and per end customer. PostgreSQL and MySQL 5.6.0+ are supported.
  • Your source code, as read-only copies of the repositories you choose to connect. Optional.
  • Your application logs, when you connect them. Optional.
  • Your help center, internal wiki and connected tools, each only after you connect it.
  • A knowledge repository per project with product answers, tone of voice and runbooks, in plain Markdown plus small scripts. You can read and edit it, and it is where ReplyPen’s learning accumulates, so answers improve without a redeploy on either side.

How does the reply stay readable?

The reply is written to a human bar: short, in your tone, and never a log of what was checked. Every draft lists what it checked separately from the reply itself. Replies never describe your internals such as files, schemas or columns, and when nothing needs to happen on the customer’s side, the reply says so plainly. Each correction your team makes feeds the knowledge repository.

What stays read-only?

ReplyPen’s own database connection is read-only. A change to your data only happens through an action: a vetted, parameterized script, and every call is signed. Two switches decide how much happens without a person, set per project and closed by default:

Switch Default Can be opened to
Sending Draft only; a person reviews and sends Auto-send
Actions A person confirms every run A rule you can read, such as waive_late_fee → auto if amount ≤ €50, or auto

Opening a switch is configuration on ReplyPen’s side, not a deploy on yours, and it is reversible.

What does setup involve?

  1. A read-only database user, limited to the tables you choose, on a TLS-only endpoint with ReplyPen’s single fixed egress IP allowlisted. A read replica works.
  2. Your domain knowledge written as plain Markdown: “a cancellation inside 24 hours is charged €25”.
  3. The mailbox or channel connected with OAuth.

Nothing is installed in your application for reading. The enforced boundary and the strictest configuration are on the security page.

Where to go next

Questions

Do we need to install anything in our product?

Not for reading. ReplyPen reads through a read-only database user and, if you want, read-only copies of your repositories. Only if you want data changes does a small SDK run on your side.

Which databases are supported?

PostgreSQL and MySQL 5.6.0 and later, both shielded the same way.

Can one tenant see another tenant's data?

No. Rows in the read-only view are filtered per tenant and per end customer, and each audience is scoped so nobody sees another tenant's data.

Last updated September 2026