SCRIBE
Six sections, and the last one is where most enterprise proposals quietly invent things.
What is SCRIBE?
SCRIBE is six sections: Situation, Challenge, Response, Impact, Benefits, Evidence. It is built for the document that goes to an enterprise evaluation committee — the one that gets circulated, annotated, and read by someone whose job is to find the weak claim.
Enterprise proposals are read adversarially. Somebody on that committee has been burned before, and they read the Benefits section looking for the number that cannot be supported. SCRIBE's useful property is that Evidence is a separate final section rather than something sprinkled through, which forces the question every proposal should answer and most avoid: for each claim we have made, what actually backs it? Doing that honestly usually reveals that two or three claims have nothing behind them — and the right response is a bracketed placeholder rather than a plausible figure, because a plausible figure is exactly what the sceptical reader is looking for.
Where SCRIBE Came From
A modern sales convention with no author of record
SCRIBE has no documented inventor. It belongs to the consultative and solution-selling tradition that grew around SPIN and its descendants, and it is best understood as a document structure rather than a methodology — the written artefact that follows a discovery process, not the process itself.
It is SCIPAB's written cousin, and the differences matter
Compare it with SCIPAB. Both open with Situation and Challenge or Complication; both end with Benefit. But SCIPAB is a ninety-second spoken opening and assumes you are in the room to answer questions, while SCRIBE is a document that has to survive being forwarded to someone who was not. Hence the extra section: Evidence exists because nobody will be there to be asked for it.
Why Evidence is last rather than woven through
A structural decision that changes behaviour. Evidence scattered through a proposal is impossible to audit — each claim looks supported because a citation is nearby. Collected at the end, against a list of the claims made, the gaps become visible to the writer before they become visible to the finance director.
The 6 Slots, One at a Time
Each slot is a decision. Leave it out and the model still makes it — just without you.
Written from their side, using their words and their org chart. A Situation section that describes the prospect in vendor vocabulary — "your current legacy estate" — tells the committee this document could have been sent to anyone. Name the eleven regional offices and the system bought in 2011.
The temptation is to describe the problem your product solves and stop. The stronger move is to include the facts that complicate your pitch — two failed replacement attempts, both abandoned at pilot. Omitting them does not hide them; it just means the committee raises them without you having framed them.
The section that decides whether this reads as attempt number three. A response that describes your product without reference to the previous failures will be read as the same proposal that was rejected twice. Address the failure mode directly — if both pilots died at pilot stage, the interesting part of your response is what happens differently at that stage.
Not the commercial case — that is the next section. Impact is what a regional manager notices on a Tuesday: what stops happening, what becomes possible, who does something differently. Keeping this separate from Benefits is what prevents the document from becoming one long argument about money.
Write this for the person who blocked the last attempt. Every figure should carry the assumption it rests on in the same sentence, because a committee that can see your assumptions can argue with them — which is a conversation you can win. One they cannot see is one they simply distrust.
Go through the claims you have made and put the support next to each. Where there is none, write [EVIDENCE NEEDED: what would substantiate this] rather than a plausible number. This is uncomfortable and it is the point: an unsupported claim you have flagged is a task, and an unsupported claim you have dressed up is the thing that loses the deal when somebody checks.
One Task, Before and After
The task: An enterprise solution document for a prospect who has abandoned two previous pilots. Both prompts below are scored by our free prompt checker — paste either in and you will get the same number, because the scoring is deterministic.
Write a proposal for an enterprise prospect.
Seven words. You get a confident proposal with a 340% ROI figure, no mention of the two failed attempts, and a Situation section that could have been sent to any facilities company.
Write a solution document for an enterprise prospect using Situation, Challenge, Response, Impact, Benefits, Evidence. The deal, and the only facts available: a 4,000-person facilities management company. They run scheduling across 11 regional offices on a mix of spreadsheets and a system bought in 2011 that the vendor no longer supports. Two failed replacement attempts in the last five years, both abandoned at the pilot stage. The evaluation committee is six people including a finance director who blocked the last attempt. Our platform is 180,000 pounds a year. We have three comparable customers, one of whom will take a reference call. Situation - their world as they would describe it, not as we would. Challenge - what specifically is not working, including the two failed attempts, which cannot be politely omitted. Response - what we propose, phrased so it addresses the reason the previous attempts failed rather than ignoring it. Impact - what changes operationally, in their terms. Benefits - the commercial case, with the assumptions visible. Evidence - what backs each claim. Use only the three comparable customers and the reference call. Any figure we cannot support goes in as [EVIDENCE NEEDED: what would substantiate this]. The two failed pilots are the most important fact in the document. A proposal that does not address why they failed will be read by the finance director as the third attempt at the same thing. Write 1,100 to 1,400 words in six headed sections for an evaluation committee who will circulate this and annotate it. Reason through the objection before you write: the finance director blocked the last attempt, and the Benefits section is written for them specifically. For example, mark unsupported claims like this: ``` Regional scheduling conflicts fall by [EVIDENCE NEEDED: comparable figure from one of the three reference customers, or remove this claim]. ``` Ensure every claim in Benefits names the assumption it rests on. Do not invent customer names, ROI percentages, implementation timelines or savings figures, and do not describe the previous vendors or attempts disparagingly.
Ninety-two. The instruction that matters most is the placeholder rule in the Evidence section: it produces a document with visible gaps, which feels weaker and is stronger.
Ninety-two, and a fabricated ROI figure would score the same
One check is out of reach, and the risk specific to enterprise documents is unmeasured:
No persona slot. Eight points for adding one, and a "solution architect" persona tends to produce exactly the vendor vocabulary the Situation section is supposed to avoid.
The failure this document format exists to prevent, and no rubric sees it. "340% ROI within 18 months" scores as a specific, confident claim. So does a bracketed placeholder. Only one of them survives a committee member asking where the number came from.
A proposal that never mentions the two abandoned pilots reads as complete and confident. To the finance director who stopped the last one, it reads as the third attempt at the same thing.
So the discipline worth importing into any proposal: list your claims, put the evidence beside each, and bracket the ones with nothing behind them. It produces a document with visible gaps, which feels weaker and is stronger — because the gaps are now yours to close rather than theirs to find.
Copy-Paste Prompt Template
Replace the bracketed placeholders with your specific details.
[The deal, and the ONLY facts available — including the awkward ones: failed attempts, who blocked what, how much evidence you actually have] Situation: [their world in THEIR words — named offices, named systems, real dates] Challenge: [what is not working, INCLUDING the facts that complicate your pitch] Response: [what you propose, aimed at why the last attempt failed] Impact: [what changes operationally, in their terms — not the money] Benefits: [the commercial case, every figure naming the assumption it rests on] Evidence: [what backs each claim. Where nothing does: [EVIDENCE NEEDED: what would substantiate this] — never a plausible number] [Written for the person who blocked the last attempt] [No invented customer names, ROI percentages, timelines or savings]
When SCRIBE Fits — and When It Does Not
- Enterprise proposals that will be circulated and annotated without you present.
- Deals with a previous failed attempt, which the Challenge section can address directly.
- Committee purchases where one member is looking for the unsupportable claim.
- Technical solution documents that must survive procurement scrutiny.
- Any proposal where you have less evidence than you would like and need to be honest about it.
- Short or transactional sales, where six sections is more document than the deal warrants.
- The live conversation. Use SCIPAB for the opening and QUEST for discovery.
- Marketing copy. This is a document written to be scrutinised, not to attract.
- Situations where you genuinely have no evidence — the last section will be all placeholders.
- Cold outreach. SCRIBE follows discovery; without it, Situation is guesswork.
10 Ready-Made SCRIBE Prompts
Every prompt below was produced by the Frompting generator with SCRIBE selected — not written by hand for this page. Each is scored by our prompt checker; the median is 88/100. Click one to open it, then copy.
A solution presentation for enterprise 80
You are a senior solution architect tasked with creating a concise, persuasive presentation that outlines a tailored solution for an enterprise prospect. The presentation must flow logically, beginning with a clear description of the prospect’s current environment, then identifying the primary business and technical challenges they face. Follow this with a detailed description of the proposed solution, explaining how it addresses each challenge. Next, illustrate the expected impact on the prospect’s operations, enumerate the concrete benefits they will realize, and conclude with credible evidence that supports the solution’s effectiveness. The audience is the prospect’s executive decision-makers and technical evaluators. Produce the presentation in **plain text** with the following structure, using short headings (no more than 5 words) to separate sections: 1. **Current Environment** - summarize the prospect’s situation. 2. **Key Challenges** - list the critical problems to solve. 3. **Proposed Solution** - describe the architecture, components, and how they map to each challenge. 4. **Projected Impact** - quantify operational or financial changes (e.g., efficiency gains, cost reductions). 5. **Benefits** - highlight strategic advantages and ROI. 6. **Supporting Evidence** - cite relevant case studies, benchmarks, or industry data. Length: approximately **715-945 words** total. Quality criteria: - Clear, logical progression that a busy executive can follow in under 5 minutes. - Use concrete, specific language; avoid vague buzzwords. - Include at least one measurable metric in the impact and benefits sections. Boundary: do not include pricing details, implementation timelines, or contractual terms. If any of the following details are unknown, insert a placeholder in the format **[PLACEHOLDER: brief hint]** and proceed with the assumption that the missing information will be supplied later: - **[PROSPECT_INDUSTRY: industry of the enterprise]** - **[SOLUTION_TYPE: core product or service being offered]** - **[KEY_CHALLENGES: top 2-3 pain points the prospect faces]** - **[TARGET_IMPACT: desired quantitative outcome, e.g., % cost reduction]** - **[EVIDENCE_SOURCE: relevant case study or benchmark to cite]** State any assumptions you make and ask up to three clarifying questions before finalizing the presentation.
A proposal for a platform migration 88
You are a senior solution architect tasked with drafting a technical proposal for migrating a client’s platform to a new environment. The proposal must be concise (≈ 350 words) and organized to flow logically from the current context through the solution and its value. Begin by describing the client’s existing situation, including the current platform, business drivers, and any relevant constraints. Next, outline the primary challenges the migration must address (e.g., downtime risk, data integrity, integration complexity). Then, present a step‑by‑step response detailing the migration approach, architecture, tools, and timeline. After that, explain the expected impact of the proposed solution on operations, performance, and risk mitigation. Follow with a clear list of benefits for the client’s business and technical teams. Conclude with evidence that supports the approach (e.g., similar case studies, benchmark results, vendor certifications). The output should be a polished, client‑facing document written in professional business‑technical language, using headings and short bullet points where appropriate, but without excessive jargon. Quality criteria: 1. Logical progression that naturally guides the reader through the six sections. 2. Specific, actionable technical details (e.g., migration phases, tools, validation steps). 3. Persuasive language that quantifies value where possible. Boundary: Do not include pricing tables, contractual terms, or internal resource allocations. If any of the following details are unknown, insert a placeholder in the format **[PLACEHOLDER: brief hint]** and proceed: - **[CURRENT_PLATFORM]** – the platform being migrated from. - **[MIGRATION_TIMELINE]** – expected duration or key milestones. - **[KEY_STAKEHOLDERS]** – primary decision‑makers or technical contacts. - **[BUDGET_RANGE]** – approximate budget or cost constraints. - **[SUCCESS_METRICS]** – how the client will measure migration success. State any assumptions you make and ask up to three clarifying questions before finalizing the proposal. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A business case for a security platform 88
You are a senior business analyst specializing in enterprise security solutions. Your task is to craft a concise, persuasive business case for a security platform aimed at senior decision‑makers in a B2B environment. Begin by describing the current environment and why security is a priority. Identify the specific problem(s) the organization faces that the platform must address. Explain the proposed solution, outlining its core capabilities and how it will be deployed. Detail the expected outcomes, focusing on risk reduction, operational efficiency, and compliance improvements. Highlight the tangible advantages for the organization, such as cost savings, revenue protection, and strategic alignment. Support your arguments with credible evidence, referencing industry standards, comparable deployments, and any available performance metrics. The business case should be written for a [ROLE: e.g., CIO, CISO, VP of Security] and be no longer than 800 words. Include a brief executive summary (max 100 words) at the beginning, followed by clearly separated sections for each part of the argument. Use a professional tone, concrete language, and avoid jargon unless defined on first use. If any of the following details are unknown, insert a placeholder in the format **[PLACEHOLDER: description]** and proceed with the assumption that the missing information will be supplied later: - **[COMPANY_SIZE: number of employees or revenue range]** - **[CURRENT_SECURITY_MATURITY: maturity level or recent incidents]** - **[BUDGET_RANGE: expected investment amount]** - **[IMPLEMENTATION_TIMELINE: projected rollout period]** - **[KEY_PERFORMANCE_INDICATORS: metrics to measure success]** State any assumptions you make explicitly, and ask up to three clarifying questions to fill critical gaps before finalizing the business case. Deliver the business case as plain text with headings for each section, ensuring it is ready for inclusion in a formal proposal packet.
A solution overview for procurement 88
You are a senior solution architect tasked with drafting a concise solution overview for a procurement committee. The overview must clearly describe the current business context, the specific problem the organization faces, the proposed technical response, the anticipated impact of that response, the key benefits to the organization, and the supporting evidence that validates the solution. Write the overview for **[SOLUTION NAME: brief description of the product or service]** aimed at **[COMMITTEE TYPE: e.g., IT procurement, facilities, finance]**. Limit the total length to **375-495 words**. **Quality criteria** 1. Logical flow that naturally moves from context through evidence without explicit headings. 2. Use concrete, jargon appropriate to the solution, with brief definitions for any specialized terms on first use. 3. Emphasize measurable outcomes and credible references (e.g., industry standards, case studies, vendor certifications). **Boundary** - Do not include pricing details, contractual terms, or implementation schedules. If any of the required details are unclear, first state your assumptions and then ask up to three clarifying questions before producing the final overview.
A proposal for an ERP implementation 88
You are a senior enterprise solutions consultant tasked with drafting a comprehensive ERP implementation proposal. The proposal will be presented to the decision‑making team of **[COMPANY NAME]:** a brief description of the organization’s industry and size. Your document should be approximately 1,200–1,500 words, organized as a flowing narrative that naturally guides the reader through the following logical progression: 1. Describe the current operational environment and business context, highlighting existing systems and processes. 2. Explain the specific pain points and strategic challenges the organization faces that an ERP solution must address. 3. Outline a detailed implementation approach, including methodology, key phases, major deliverables, and required resources. 4. Illustrate the expected impact on operations, performance metrics, and risk mitigation once the solution is live. 5. Summarize the tangible benefits for the organization, such as cost savings, efficiency gains, and competitive advantage. 6. Provide credible evidence to support the proposal, referencing relevant case studies, industry benchmarks, and success metrics (use approximate figures where exact data is unavailable). **Quality criteria:** - Clear, concise language tailored to senior executives with limited technical background. - Logical flow that builds a compelling business case without jargon overload. - Persuasive tone that balances optimism with realistic expectations. **Boundary:** Exclude detailed technical specifications, code snippets, or pricing tables; focus on strategic and business aspects only. If any essential details are missing, state your assumptions explicitly and ask up to three clarifying questions (e.g., desired implementation timeline, budget range, key stakeholder roles). Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A business case for a data warehouse 84
You are a senior business analyst specializing in enterprise data solutions. Your task is to craft a concise business case for implementing a data warehouse. The document should be organized as a logical narrative that first describes the current organizational context and data environment, then outlines the specific problems hindering decision‑making and operational efficiency. Next, propose a detailed solution architecture and implementation approach, followed by an analysis of the expected operational and strategic impact. Conclude with a clear articulation of the tangible benefits and supporting evidence such as industry benchmarks or case study references. Write the business case for **[AUDIENCE: e.g., C‑suite executives, board members, IT steering committee]**. Target length: approximately 800 words. Quality criteria: 1. Persuasive and data‑driven, with each claim backed by a brief citation of a reputable source or benchmark. 2. Structured with clear paragraph breaks that guide the reader through the narrative flow. 3. Written in a professional tone, using precise technical terminology where appropriate but defining any specialized terms on first use. Boundary: do not include detailed project schedules, cost breakdown tables, or vendor product comparisons. If any essential details are missing, state your assumptions explicitly and ask up to three clarifying questions before finalizing the business case.
A compliance platform solution document 95
You are a senior solution architect tasked with drafting a comprehensive solution document for a compliance platform. Begin by describing the current environment and business context in which the platform will be deployed. Identify the key obstacles and regulatory pressures that the organization faces, focusing on the most critical compliance gaps. Outline a detailed, step‑by‑step solution that leverages the platform’s capabilities, specifying any required integrations, data flows, and security controls. Explain the expected outcomes of the solution, including measurable improvements to compliance posture and operational efficiency. Highlight the strategic advantages for the organization, such as risk reduction, cost savings, and alignment with industry standards. Provide supporting evidence, referencing well‑known regulations, industry best practices, and any relevant case studies or benchmark data. The document should be written for senior decision‑makers and technical stakeholders, using clear, professional language and a logical flow. Deliver the solution document in markdown format, with the following sections in order: 1. Executive overview (≈150 words) 2. Business context (≈250 words) 3. Compliance challenges (≈200 words) 4. Proposed solution architecture (≈400 words, include a high‑level diagram description) 5. Anticipated impact (≈200 words) 6. Business benefits (≈200 words) 7. Evidence and references (≈150 words) Quality criteria: - Accuracy of regulatory references and technical details. - Clarity of the solution architecture description. - Persuasive articulation of value for both business and technical audiences. Exclude any marketing fluff, speculative pricing, or implementation timelines. If any essential details are missing, state your assumptions explicitly and ask up to three clarifying questions before finalizing the document. [REGULATIONS: list the specific compliance regulations the platform must address] [INTEGRATIONS: list any external systems the solution must connect to] [CASE_STAKEHOLDERS: identify the primary audience for the document]
A managed services proposal 90
You are a senior B2B proposal writer experienced in crafting comprehensive managed‑services contracts for enterprise clients. Your task is to produce a polished proposal that clearly outlines the current operating environment, the specific challenges the client faces, your proposed managed‑services solution, the expected impact of that solution, the key benefits to the client, and supporting evidence that validates the approach. The proposal is intended for the decision‑making team of **[CLIENT ORGANIZATION]: name of the company seeking services**. It should be concise yet thorough, targeting a length of **approximately 1,200–1,500 words**. Structure the document in a logical flow that naturally follows the five sections described above, using clear headings and brief introductory sentences for each section. Within each section, provide concrete details, avoid vague language, and use bullet points or tables where they improve clarity. Quality criteria: 1. Demonstrates a deep understanding of the client’s operational context and pain points. 2. Presents a technically sound, feasible solution with measurable outcomes. 3. Persuasive and professional tone, free of jargon unless defined. Boundary: Do not include pricing tables, detailed legal clauses, or proprietary methodology diagrams; focus on strategic description and justification. If any essential details are missing, state your assumptions explicitly and ask up to three clarifying questions before finalizing the proposal. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A business case for internal tooling 87
You are a senior business analyst tasked with drafting a concise, persuasive business case to secure internal investment for a new tooling solution. The document will be presented to senior leadership and finance decision‑makers to obtain funding and resources. Produce a single, well‑structured narrative that flows through the following logical progression: 1. Describe the current operational environment, including the existing processes and tools that support the relevant work streams. 2. Explain the specific problem or limitation that hampers efficiency, quality, or scalability. 3. Propose the recommended tooling solution, outlining its key capabilities and how it will be implemented. 4. Illustrate the expected impact on performance, risk reduction, and strategic objectives. 5. Detail the tangible and intangible benefits, such as cost savings, productivity gains, and competitive advantage. 6. Provide supporting evidence, referencing industry best practices, comparable case studies, or internal pilot results. The business case should be approximately **800 words** in length, written in a professional yet accessible tone, and formatted as a plain‑text document with clear paragraph breaks. Quality criteria: - Logical coherence and smooth transitions between each section. - Quantitative estimates (e.g., % improvement, cost reduction) where possible, clearly marked as estimates if not exact. - Alignment with the organization’s strategic roadmap. Boundary: Do not include detailed technical specifications, vendor pricing tables, or implementation schedules beyond a high‑level overview. If any essential details are missing, state your assumptions explicitly and ask up to three clarifying questions before finalizing the business case. [TOOL TYPE]: specify the category of tooling (e.g., CI/CD platform, data‑analytics suite, monitoring system). [PRIMARY STAKEHOLDER]: identify the department or role championing the investment. [CURRENT METRICS]: provide baseline performance figures (e.g., deployment frequency, incident rate). [EXPECTED ROI PERIOD]: indicate the time horizon for realizing financial returns. [COMPARABLE CASE]: reference a similar internal or external project that demonstrates success. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.
A presentation for a healthcare system 75
You are a senior solution architect specializing in enterprise healthcare technology. Your task is to create a concise, persuasive presentation that outlines a comprehensive solution for a healthcare system. First, describe the current environment, including the system’s primary functions, existing technology stack, and any recent initiatives that set the stage for improvement. Next, identify the most critical obstacles the organization faces—such as interoperability gaps, regulatory compliance pressures, scalability constraints, or patient experience challenges. Then, propose a detailed response: a tailored solution architecture, key components, integration approach, and implementation roadmap that directly addresses the identified obstacles. After that, illustrate the expected impact of the solution, quantifying improvements in operational efficiency, clinical outcomes, cost reduction, or compliance adherence. Follow with a clear articulation of the benefits for each stakeholder group—executives, clinicians, IT staff, and patients—highlighting strategic, financial, and experiential advantages. Conclude by providing credible evidence to support the proposal, such as references to industry standards, case studies from comparable healthcare organizations, and any relevant performance metrics. The presentation is intended for [AUDIENCE: e.g., C‑suite executives, CIO, clinical leadership] and should be no more than [WORD COUNT: 800] words. Quality criteria: 1. Logical flow that naturally guides the reader from context to solution and proof. 2. Use of concrete, data‑driven examples wherever possible; mark any estimates as approximate. 3. Professional tone with clear, jargon‑aware language suitable for senior healthcare decision‑makers. Exclude any discussion of unrelated technologies or solutions not directly tied to the healthcare system’s needs. If any essential details (e.g., specific regulatory requirements, existing vendor contracts, or budget constraints) are unclear, state your assumptions and ask up to three clarifying questions before finalizing the presentation.
Scores range from 75 to 95. They are shown as generated rather than cherry-picked — a library where every entry scores in the nineties tells you it was curated, not measured.
SCRIBE vs the Alternatives
The spoken cousin, and the difference is presence. SCIPAB opens a meeting where you can be asked questions; SCRIBE is a document read when you are not there, which is why it has an Evidence section.
What comes first. QUEST is the discovery call that produces the facts; SCRIBE is the document written from them.
The questioning technique behind the discovery. SPIN produces the explicitly stated need that SCRIBE's Response section answers.
For the Impact and Benefits sections specifically. FAB is the disciplined way to keep a benefit tied to a need the buyer actually stated.
The short internal version of the same instinct. PEP is one page for a colleague; SCRIBE is twelve hundred words for a committee.
Five Ways People Get SCRIBE Wrong
The defining SCRIBE failure and the one that loses deals. A specific percentage with no derivation is the first thing a sceptical finance director tests. Bracket it as evidence needed and go and get it.
They will be in the room whether or not they are in the document. Naming them lets you frame why this is different; omitting them means the committee frames it as attempt three.
"Your current legacy estate" describes a category. Eleven regional offices and a system bought in 2011 describes them, and that is what signals you were listening.
A committee that can see your assumptions can argue with them, which is a conversation you can win. One that cannot simply discounts the number.
Operational change and commercial case are different arguments for different readers. Merged, the document becomes one long conversation about money and the operations lead has nothing to respond to.
Scattered citations make every claim look supported. Collected at the end against a list of claims, the gaps become visible — to you, before the reader.
SCRIBE Questions
What does SCRIBE stand for?
Situation, Challenge, Response, Impact, Benefits, Evidence — a six-section structure for an enterprise solution document or proposal.
How is SCRIBE different from SCIPAB?
SCIPAB is a spoken opening of about ninety seconds, delivered when you are present to answer questions. SCRIBE is a document that gets forwarded to people who were not in the room, which is why it ends with a dedicated Evidence section.
Why is Evidence a separate section?
Because evidence scattered through a proposal cannot be audited — every claim looks supported because something is nearby. Collected at the end against your list of claims, the unsupported ones become visible while you can still do something about them.
What should I do about claims I cannot support?
Write [EVIDENCE NEEDED: what would substantiate this] and leave it in your draft. It is uncomfortable and it converts an unsupported claim from a liability into a task.
Should I mention that previous attempts failed?
Yes, in the Challenge section. The committee remembers them and one member probably stopped the last one. Addressing why they failed is what stops this being read as the same proposal a third time.
How long should a SCRIBE document be?
For an enterprise evaluation, roughly 1,100 to 1,400 words is a workable range — long enough for six real sections, short enough to be read by six people who will annotate it.
Generate a SCRIBE Prompt Instantly
Skip the manual template — Frompting applies SCRIBE to your topic in one click.
Try it FreeFramework Details
| Name | SCRIBE |
| Stands for | Situation-Challenge-Response-Impact-Benefits-Evidence |
| Domain | Persuasion & Conversion |
| Steps | 6 |
| Access | Pro |