FROM PEOPLE ARE THE POINT

Make the GRADE

Pick one process in your business. Not your whole company or your AI strategy. One process.

Write down how it works now. A formal SOP is great if you have one. A messy explanation is fine too. Then use this prompt with whatever AI tool you prefer.

G — Guard: What should remain human?
R — Redesign: If we were creating this from scratch, how should it work?
A — Automate: What should technology do?
D — Delegate: What remaining work should another human do?
E — Eliminate: What shouldn't happen at all?

Build Your GRADE Diagnostic Prompt

Nothing you type here leaves your browser. I don't store or send your answers anywhere.

What system or process do you want to examine?

Pick one process. For example: onboarding a new employee, handling a customer complaint, or taking a client from signed agreement through completion.

Where does this process begin and end?

Describe what starts the process, what tells you it's complete, and what a good result looks like.

Who is involved?

Include the people or roles who do the work, make decisions, approve things, receive handoffs or need to know what's happening.

Where does it frustrate people, take too much time, or seem to break down?

Think about things people have to remember, check, chase, re-enter, reconcile or work around. Don't worry about diagnosing the problem yet.

What documentation do you have? (optional)

If you're using a document your AI already has access to, name it here. Otherwise, paste the relevant documentation here or attach it when you use your prompt. Don't clean it up first. The mess can be useful information.

Your GRADE analysis is a starting point. Before you change the process, take its questions back to the people who actually do the work. They know things your documentation doesn't.

GRADE Diagnostic Prompt
I want you to analyze the attached business system using the GRADE framework.
Do not assume the current process is well designed. Do not simply look for opportunities to make the existing steps faster. Treat the documentation as evidence of how the system currently works, not as a blueprint for how it should work.
Do not design the future-state workflow yet. This first analysis should help us understand the current system, identify where redesign is needed, and determine what we need to learn from the people doing the work before we design its replacement.
First: Reconstruct the Current System
Identify:

* major steps
* people and roles involved
* handoffs
* approvals and decisions
* technology and systems
* where information originates and where it moves
* duplicate entry or handling
* monitoring and checking
* dependencies on individual memory or institutional knowledge
* exceptions and workarounds

Note anything unnecessarily complicated, unclear, repetitive or dependent on people compensating for weaknesses elsewhere in the system.
Then run the current system through GRADE, in this order.
G — Guard: What should remain human?
Identify where human judgment, expertise, discretion, curiosity, creativity, conversation, relationship or care appear to create meaningful value.
Explain why each deserves human involvement rather than assuming that anything currently done by a person should remain human.
Distinguish valuable human work from human activity that exists because a person currently has to compensate for the way the system works.
Flag anything where the documentation alone isn't enough to determine whether human involvement creates value.
R — Redesign: What needs to be reconsidered?
Do not design the replacement workflow yet.
Identify the parts of the current system we should challenge if we were building it from scratch today.
Question:

* sequence
* roles
* ownership
* handoffs
* approvals
* information flow
* sources of truth
* controls
* communication
* assumptions inherited from the existing process

Look especially for places where the current process may be solving problems created by the process itself.
For each major redesign opportunity, identify what we need to understand about the desired outcome, customer experience, employee experience, business requirements or risk before deciding what the future process should be.
A — Automate: What appears to be a candidate for technology?
Identify work technology could potentially handle, including repetitive tasks, data movement, reminders, calculations, retrieval, documentation, status updates, pattern recognition and coordination.
Pay particular attention to places where a person currently:

* moves information between systems
* monitors another system for a change
* remembers a deadline
* checks whether something happened
* tells another person that something happened
* gathers information that already exists elsewhere

Treat these as automation candidates, not automation recommendations. Some of this work may disappear when the process is redesigned.
D — Delegate: What work may not require the person currently doing it?
Identify work that requires a human today but may not require the expertise, authority or relationship of the person currently doing it.
Again, treat these as candidates. Do not recommend delegating work until we know that the work should exist in the redesigned system.
E — Eliminate: What may not need to happen at all?
Identify:

* duplicate entry
* duplicate handling
* redundant checks
* unnecessary approvals
* obsolete reports
* unnecessary communication
* workarounds
* legacy requirements
* activity whose primary purpose is compensating for another weakness in the system

Do not recommend eliminating a control until we understand why it exists and what risk it currently manages.
Never eliminate compensating work until we've identified and addressed the reason it exists.
Finish With a Diagnostic Summary
Give me:

1. Current-state diagnosis: Where does this system appear to consume unnecessary time, attention or capacity?
2. Guard candidates: Where does human involvement appear to create meaningful value?
3. Redesign opportunities: What parts of the system most deserve to be reconsidered?
4. Automation candidates: What work appears suitable for technology if it survives the redesign?
5. Delegation candidates: What work may be sitting with the wrong level or role?
6. Elimination candidates: What work may have no independent reason to exist?
7. Compensating work: Where are people compensating for disconnected systems, unclear ownership, unreliable handoffs or other process weaknesses?
8. Evidence gaps: What can't we determine from the documentation?
9. Questions for the team: What do we need to ask the people who actually do this work before making design decisions?
10. Questions for the business owner: What do we need to know about the desired outcome, customer experience, employee experience, capacity, controls, constraints and priorities before designing the future state?

Do not create the future-state workflow yet.
The next step will be to validate this analysis with the people doing the work and define the experience and outcomes we want the future system to produce. Only then will we design the future-state workflow.