Guides to using Frank.

Three guides

1. 01

   Gather what your team already uses

   Don’t write anything new for Frank. What helps is what actually circulates in the company, even if it is messy. In order of usefulness:

   • Culture or values handbook: this is where how people speak in your company, and what is never said, comes from.
   • Sales playbook: sales process, arguments, frequent objections and how they are answered.
   • Pricing and discount policy: the real numbers the counterpart will push with.
   • CRM notes: reasons for lost deals, verbatim client phrases, the story of a negotiation that went sideways.
   • Career plan, feedback or review guide: what a leader has to tell their team, and how.
2. 02

   Check the format

   Frank reads PDF, DOCX, Markdown and plain text. What matters is that the text is selectable: a PDF scanned as an image cannot be read. One document per topic works better than a three-hundred-page file with everything inside. And short things don’t need a file: a five-line block like “How we give feedback here” is worth as much as a handbook.

3. 03

   Leave out what must not go in

   Frank needs the objection, not the name of the person who raised it. Before uploading, remove or anonymize:

   • Client personal data: names, emails, phone numbers, identifiers, individual history.
   • Third-party information under a confidentiality agreement: supplier proposals, contracts with counterparty details, partner material.
   • Performance reviews of specific people on your team.
   • Credentials, access details and any financial data that is not a general policy.

   If a document is useful but contains personal data, a copy with the names replaced works just as well.

4. 04

   Label each document and upload it

   Each file carries a short label saying what it is: “Discount policy”, “Feedback guide”. Who uploaded it and when is recorded. Only the people who administer the organization can upload context, and that context is private: it is not shared with any other organization.

   What we keep and for how long

5. 05

   What happens next

   With the context loaded, Frank proposes scenarios with your products, your objections and your numbers inside. None of them reaches a person on your team until someone in your organization approves it. How to review them is the next guide.

Next guide: How to approve and correct scenarios

1. 01

   Where proposals show up

   Every scenario Frank writes comes in with the status “Under review”. While it sits there it does not exist for your team: nobody can practice it or see it. It moves to “Approved” only when someone in your organization reviews it and accepts it, with their name on record.

2. 02

   What to check in each one

   Five questions, in this order. If any of them fails, the scenario is not ready.

   • Does the counterpart want something concrete and believable? A discount, a date, for the meeting to end. Without a goal of their own there is no pressure.
   • Does the situation come from your documents? Your products, your prices, the objections your team actually hears. If it could belong to any company, context is missing.
   • Does the nature of the scenario match the real conversation? Routine, tense, or conflict. Closing a sale and letting someone go are nothing alike, and neither should the counterpart be.
   • Can it end in more than one way? If there is only one right answer, it is an exam, not a conversation.
   • Is there any real personal data? Names of clients or team members don’t go in. They get replaced before approval.
3. 03

   What a well-written one looks like

   An approved scenario reads like the example below. Each field answers a question the counterpart will need during the session, and none of them says what the person practicing has to reply.

4. 04

   Correct before you reject

   Most proposals are not rejected: they are adjusted. Changing a product name, fixing a number that went stale, removing a phrase nobody in your company would say. Whatever you edit is saved in the approved scenario. If it still doesn’t work, don’t approve it: a weak scenario costs someone an entire session.

5. 05

   Why approval is always human

   A scenario is what a person on your team is going to face out loud and under pressure. Deciding what they practice is a decision about that person, and decisions about people are made by a person. That is why approval carries a name, and why there is no automatic mode. It is a design decision, not a temporary limitation.

A well-written scenario

Title

The account asking for a discount

Nature

Tense

Who is on the other side

Procurement at a mid-sized client, third renewal, with the budget cut this quarter.

What they want

18% off the price already closed, agreed today.

What they know

That you have room to give something, and that losing the account hurts you more than switching suppliers hurts them.

How it opens

Comes in without a greeting and goes straight to the number.

When it closes

If there is no clear signal within four minutes, says they have another meeting and ends it.

What is missing: a script of what the person practicing has to say, and a right answer. The conversation supplies those.

To see how a scenario fits inside a program: How Frank works

1. 01

   Start with the baseline

   Each person’s first session serves one purpose: recording how they sound when nothing is at stake. That recording is their baseline. Everything that follows is compared against it, not against a team average or an external ideal. An accent, a disfluency or an unusual timbre are not noise: they are the starting point.

2. 02

   Read each delta as a distance

   A delta is how far the voice moved from its own baseline at a specific moment. “Sped up when talking about price” means faster than usual for that person, not faster than a norm. A delta has no good or bad direction on its own: picking up the pace can be the right move in a close and a problem in a negotiation. It is read together with the moment it happened in.

3. 03

   Locate the key moments

   The report marks on the timeline the moments where something happened: the counterpart pushed, interrupted, left a silence, or warned they were about to end it. At each one you see how the voice moved relative to the baseline. That is the material for the next practice: not the session average, but those points.

4. 04

   Trust the words, not only the marks

   The report is told in plain language: “You held the first part well”, “You sounded tense at the end”. That is the reading that matters. The acoustic signals sit underneath and serve to explain, not to grade. When the audio does not allow a confident measurement, the report says so instead of reporting a doubtful number.

5. 05

   Who sees what

   The full report belongs to the person who practiced. The organization sees each person’s progress against their own starting point and aggregated team views, not the session or the audio. Nobody listens to another person’s session without that person knowing.

What a report cannot conclude

• Nothing about the person’s personality. How they sounded in ten minutes of practice does not say who they are.
• Nothing about their emotions or internal states. Frank describes voice signals; it does not infer what someone feels.
• Nothing about their job performance. A delta in one session does not predict how they will do at work, and the report is not built for that.
• No decision about the person. Not hiring, not promoting, not letting go. If a report is used for that, it is being misused.

This limit is a design decision, not a temporary restriction.

The terms in this guide, explained one by one: Glossary

Missing a guide?

These three cover what gets asked most in the first weeks. If your question isn’t here, write to us: we answer in person and, if it comes up again, it becomes a guide.