Skip to content

AppThentic Docs

By team

Pre-sales answers

Sales and solution engineers answer "does your product do X?", RFPs and security questionnaires from the systems themselves, without pulling in engineering.

A prospect asks whether your product does something. The honest answer is in the system, and the person who can read it is an engineer in the middle of a release. So the deal waits, or someone answers from memory and the contract promises something the system does not do.

The usual way

Prospect: “Do you hold seller payouts on cash-on-delivery orders, and for how long?”
Solution engineer: Not sure. Posts in the engineering channel.
Engineer, two days later: Reads the payouts code and replies with a number, but not the exceptions.
The RFP goes out with half an answer. Forty more questions in the same questionnaire wait their turn.

With AppThentic

Solution engineers ask om, and every answer cites the rule and its owner.

Ask om · RFP, payouts section

Solution engineer

Do we hold seller payouts on cash-on-delivery orders? For how long, and does it apply to every seller?

om

Yes. Cash-on-delivery payouts are held for 24 hours after delivery, for every seller, so fraud flagged within a day is caught before money moves.

Owner Priya S., PaymentsApproved Jun 2026Next review Dec 2026

Ask in plain words, the way the prospect asked.
om answers from approved rules, with the owner and approval date on each answer.
What om does not know, it says. It asks the owner and comes back with their answer, so nothing goes into a contract on a guess.

RFPs and security questionnaires

Most questions repeat across deals: how refunds work, which payouts get a manual review, who must approve a large payout, how a failed payout retries. om answers them from the systems themselves, with the same sources every time. An engineer is pulled in only for what nobody has explained yet, and their answer serves every deal after.

What sales can see

Admins assign who sees what. A solution engineer gets the rule and its reason, and nothing their access does not cover, however a question is phrased. See Access and audit trail.

When a promise changes

om answers from each rule as it is today. When a rule changes, it is marked Stale and its owner is asked again, so the next RFP gets the current answer. See Keeping answers current.

Who uses it

Sales engineers, solution engineers and the people who fill in RFPs and security questionnaires.

# Pre-sales answers

Sales and solution engineers answer "does your product do X?", RFPs and security questionnaires from the systems themselves, without pulling in engineering.

A prospect asks whether your product does something. The honest answer is in the system, and the person who can read it is an engineer in the middle of a release. So the deal waits, or someone answers from memory and the contract promises something the system does not do.

## The usual way

1. **Prospect:** "Do you hold seller payouts on cash-on-delivery orders, and for how long?"
2. **Solution engineer:** Not sure. Posts in the engineering channel.
3. **Engineer, two days later:** Reads the payouts code and replies with a number, but not the exceptions.
4. **The RFP** goes out with half an answer. Forty more questions in the same questionnaire wait their turn.

## With AppThentic

Solution engineers ask om, and every answer cites the rule and its owner.

<figure class="frame">
  <div class="frame__bar"><span class="frame__dots" aria-hidden="true"><i></i><i></i><i></i></span><span class="frame__title">Ask om · RFP, payouts section</span><span aria-hidden="true"></span></div>
  <div class="frame__body mock">
    <div class="mock__box">
      <span class="mock__who">Solution engineer</span>
      <p>Do we hold seller payouts on cash-on-delivery orders? For how long, and does it apply to every seller?</p>
    </div>
    <div class="mock__box mock__box--answer">
      <span class="mock__who">om</span>
      <p>Yes. Cash-on-delivery payouts are held for 24 hours after delivery, for every seller, so fraud flagged within a day is caught before money moves.</p>
    </div>
    <div class="mock__chips"><span class="chip"><b>Owner</b> Priya S., Payments</span><span class="chip"><b>Approved</b> Jun 2026</span><span class="chip"><b>Next review</b> Dec 2026</span></div>
  </div>
</figure>

1. **Ask in plain words**, the way the prospect asked.
2. **om answers from approved rules**, with the owner and approval date on each answer.
3. **What om does not know, it says.** It asks the owner and comes back with their answer, so nothing goes into a contract on a guess.

## RFPs and security questionnaires

Most questions repeat across deals: how refunds work, which payouts get a manual review, who must approve a large payout, how a failed payout retries. om answers them from the systems themselves, with the same sources every time. An engineer is pulled in only for what nobody has explained yet, and their answer serves every deal after.

## What sales can see

Admins assign who sees what. A solution engineer gets the rule and its reason, and nothing their access does not cover, however a question is phrased. See [Access and audit trail](/docs/access-and-audit-trail).

## When a promise changes

om answers from each rule as it is today. When a rule changes, it is marked **Stale** and its owner is asked again, so the next RFP gets the current answer. See [Keeping answers current](/docs/keeping-answers-current).

## Who uses it

Sales engineers, solution engineers and the people who fill in RFPs and security questionnaires.