How to create a process from scratch (without being a process engineer)

You don't need to be a process engineer

There is a persistent myth in the corporate world: that to create a business process you need to master notations like BPMN, hold a process management certification, or hire a specialized consultancy.

You don't.

Most processes that keep a company running — employee onboarding, contract approval, credit analysis, request triage — were created by people who simply needed to solve a problem. Someone noticed work was disorganized, sat down, and defined a sequence of steps.

The problem isn't a lack of technical knowledge. It's the lack of a simple method to turn what already happens in practice into something documented, repeatable, and visible to everyone.

This article presents that method. Seven steps to create a process from scratch, without jargon and without complex tools.

Step 1: Start with what happens today

The most common mistake when creating a process is starting with the ideal. Someone sits in front of a blank screen and tries to design the perfect process, with every exception accounted for and every path mapped.

Don't do that.

Start with reality. Go to the person who does the work and ask:

• What do you do when a new request comes in?
• What steps do you follow, in order?
• Where do things usually get stuck?
• Who do you need to talk to along the way?

Write down the answers without editing. Don't try to organize yet. The goal is to capture reality, with all its imperfections.

If three people do the same work, interview all three. You'll discover that each one does it slightly differently. That's not a problem — it's valuable information. The differences reveal where clarity is lacking.

Step 2: List the stages

With your notes in hand, identify the distinct phases of the work. A stage is a block of activities that happen together and serve a clear purpose.

For example, in a contract approval process:

1. 1Intake — The contract arrives for review
2. 2Legal review — The legal team examines clauses and risks
3. 3Financial review — Finance validates payment terms
4. 4Approval — The responsible manager approves or rejects
5. 5Signature — The contract is formalized
6. 6Archiving — The final document is stored

Don't overdo the number of stages. If you have more than 8 or 10, you're probably going too granular. Stages represent phases, not individual tasks.

A good rule: if you can explain each stage in one sentence, the level of detail is right.

Step 3: Define who does what at each stage

For each stage, answer: who is responsible?

This doesn't mean assigning a specific person. It means defining the role. Who analyzes? Who approves? Who executes?

In the contract example:

When nobody is responsible for a stage, it becomes no-man's-land. Tasks sit idle without anyone noticing. Defining owners is what turns a list of steps into a real process.

Step 4: Identify the information needed

Each stage needs inputs to function. These can be:

• Data fields: vendor name, contract value, term duration
• Documents: commercial proposal, legal opinion, proof of payment
• Prior approvals: stage 4 only starts when stage 3 finishes

List what is mandatory and what is optional. Processes that demand too much information at the start stall right away. Processes that demand too little create rework later.

Balance comes with practice. In the first version, ask only for the essentials. You can add fields later, once you know which information actually makes a difference.

Step 5: Set deadlines per stage

Every stage needs a deadline. Without deadlines, there's no urgency. Without urgency, things stop.

It doesn't need to be exact. A range works:

• Legal review: 2 to 3 business days
• Approval: 1 business day
• Signature: 5 business days

Deadlines do two important things:

1. 1Create expectations — everyone knows how long each step should take
2. 2Reveal bottlenecks — when a stage consistently exceeds its deadline, you know where to focus

In the first version, set deadlines based on what happens today, not what you wish would happen. You optimize later.

Step 6: Define what triggers the next stage

What makes a case leave one stage and enter the next? This is the question that separates functional processes from confusing ones.

The most common answers:

• Approval: someone reviews and approves to move forward
• Document upload: a required document is attached
• Form completion: pending information is filled in
• Time: after X days, the case advances automatically
• Decision: someone makes a formal decision (approve, reject, request changes)

Defining clear triggers eliminates ambiguity. Nobody needs to ask "can this move to the next phase?" — the criteria are set.

In practice, most stages advance through manual approval. That's fine. You don't need to automate everything on day one. What matters is that the criteria exist.

Step 7: Test with a real case

You have the stages, the owners, the information, the deadlines, and the triggers. Now test.

Take a real case — a request coming in today — and run the process from start to finish. Observe:

• Where did it stall? Did any stage sit idle without a clear reason?
• Was information missing? Did someone need something that wasn't planned for?
• Was there unnecessary bureaucracy? Does any step seem redundant in practice?
• Does the flow make sense? Does the order of stages reflect what actually happens?

Write it all down. Adjust. Test again.

A good process isn't born perfect. It's born functional and improves with use. The first version will have flaws. The second, fewer. By the third, you have something solid.

Common mistakes (and how to avoid them)

Over-engineering the first version

The temptation is strong: map every exception, predict every scenario, create alternative paths for everything. Resist.

The first version should cover the main path — what happens in 80% of cases. Exceptions can be handled manually until you understand which ones are frequent enough to justify their own path.

Trying to automate everything at once

Automation is powerful, but premature when you don't yet understand the process well. Automate after running the process manually for a few weeks. When you know where the bottlenecks and repetitions are, automation solves real problems instead of creating new ones.

Not involving the people who do the work

The biggest mistake of all. A process designed by someone who doesn't do the work is a process nobody will follow.

The people who execute tasks daily know things no top-down analysis will capture. They know where the information lives, which steps are truly necessary, and which ones are pure bureaucracy.

Involve them from step 1. The process will be better and adoption will be natural.

How CaseFy helps

CaseFy was built for people who need to create and manage processes without relying on technical knowledge.

Visual template builder: create stages, define fields, configure permissions, and set transitions by dragging blocks. No BPMN diagrams, no modeling languages.

Custom fields per stage: each stage can have its own mandatory and optional fields. The system ensures the right information is collected at the right time.

Deadlines and SLAs per stage: set deadlines for each phase. When a deadline approaches, responsible parties are notified automatically.

Configurable transitions: determine which stages can advance to which other stages, and what conditions must be met for the transition to happen.

Complete timeline: every action is recorded automatically — who did what, when, and in which stage. Full traceability without manual effort.

Quick test and adjust: create a test case, run the process, identify adjustments, and modify the template. No code, no deployment, no waiting for IT.

You go from zero to a working process in minutes, not weeks.

Start for free →