SAMPLE LESSON / ABOUT 20 MINUTES
Define the work before changing it
Write a process boundary that two people would interpret in the same way.
This is the first lesson as a sample. Saving exercises, progressing through the full course and receiving a completion certificate require a paid ₹49 enrolment.
Create a learning profile →A process is a route to an outcome
A process connects a trigger to an outcome through a sequence of activities and decisions. “Customer service” is a function. “Handle a customer’s request to change a delivery address” is a process we can examine. The distinction matters: a broad label hides different kinds of work, each with its own steps and exceptions.
Start by defining one unit of work. It might be a complete request, one invoice or one application. If your team counts emails while another counts customer cases, their volume and time figures will not be comparable. A single case may generate several emails.
Agree the start, finish and customer
A useful boundary names the trigger, the condition required to start, the outcome and who receives it. For an address change, does the clock start with the first message or only after required identity and order details are available? Either can be useful, but they answer different questions. Track missing-information time rather than quietly excluding it.
Define what complete means. Sending a request to dispatch is not the same as confirming the address has changed. Keep the end condition observable. Record exclusions such as orders already handed to the carrier, and agree who handles those cases. Boundaries make responsibility visible; they should not be used to move inconvenient work out of the report.
WORKED EXAMPLE
Gramin Kriti practice case: Pahad Home Supplies
This fictional business receives delivery-change requests by WhatsApp and email. Its team says requests take “too long”. A workable starting boundary is below. All figures and organisations in these courses are invented for learning.
| Boundary | Working definition |
|---|---|
| Unit | One customer request linked to one order |
| Start | First request received, including cases with missing details |
| Finish | Customer notified of the confirmed change or a clear reason it cannot be made |
| Owner | Customer-support supervisor |
| Exception | Carrier handover already completed |
YOUR TURN
Put this lesson to work.
Choose one recurring task from your own work or use the delivery-change case. Write a boundary with the unit, trigger, finish condition, customer, owner and one exception. Explain how you would treat missing information.
- One unit of work
- Observable start and finish
- Named role, not a person’s private details
- One exception and its owner
A clear boundary makes the problem small enough to investigate without hiding exceptions.