About to do a call with someone from Crisp in Sweden.
Oh my god, their documentation is exquisite and markdown!
e.g.
The Bun Protocol
The Bun protocol ("Bullprotokollet" in Swedish) is a lightweight, decentralized request routing protocol. It is designed to be the simplest possible way to handle requests that are shared by a distributed group of people. We use it mostly to handle incoming client requests.
We introduced this to Crisp a few years ago because we had just created a lightweight recruitment process, and later when we were creating a lightweight sales process we noticed many similarities. So we did an extract to interface refactoring and created this "Bun Protocol" :o)
The metaphor
When a bun (= issue or request) comes in it is warm, juicy and soft. If it sits around for a day it will get cold. If it sits around several days it will become dry and hard. You can warm up an old bun in the microwave oven as long as it hasn't become too dry.
So, a bun should be eaten fairly quickly or thrown away. No use stuffing it in a box. If you can't eat it yourself, offer it to someone else - before it gets cold, dry and hard!
Sample buns
- You get an email "Hi, we want a TDD course at company X. What will it cost and when can you come?". Now you have a bun!
- You meet someone at conference who says "I want to join your company!". Now you have a bun!
How the protocol works
A bun is born when someone asks you for something and you decide that "hey, this is a bun". Typically through email, but sometimes a phone call or a conference mingle.
A bun always has an owner - the person who received the bun. Or more specifically, the person responsible for the communication channel through which the bun appeared. For example, you are of course responsible for any emails sent directly to you, while the office team is responsible for requests to info@crisp.se, etc.
When you have a bun, you are responsible for taking care of it before it gets too dry! Preferably within 1 working day, definitely within 2.
You have 3 options:
- Eat it yourself. For example "Sure, I can come and do a TDD course at your company". The bun is now consumed, i.e. it has found a home and will not be routed anywhere.
- Give it to somebody else. For example to a colleague who is more suitable than you, or another company. If you don't know exactly who should take it, email a broadcast to your colleagues or trusted partners: "Hi folks, does anybody want to take this bun?". Note that the bun is still yours until someone else takes it! Allow a day so that your colleagues have time to react, but if that takes more than a couple of days you need to keep the bun warm (for example tell the customer that you are searching for someone who can help). So you can't push the bun to someone, you can only offer it. The receiver has to pull the bun from you.
- Throw it away. For example someone emails me "Can you come and teach a Cobol course?". I answer "No". Or I answer "No, we don't do Cobol courses, but I recommend you speak to Mr CobolGeek". That still counts as throwing away the bun, since I let it go and won't follow it up. Someone else might take it out of my garbage, but I don't need to know or care if that happens :o)
The one thing you should NOT do is just let the bun sit and dry. Better to explicitly throw it away in that case (i.e. tell the sender that we can't help).
So initially a buns appears through a "push" protocol, i.e. the initial recipient gets the bun whether he wants to or not. After that, however, everything is "pull"-based.
... (it goes on)