Hi folks!
I’m looking to beemind a few things that other people trigger, but I respond to. I’m a little stumped.
The first thing I’m looking to do is to reduce the time it takes for me to ship out orders. The second thing I’m trying to do is reduce the time before a human responds to a support request.
Thoughts?
You’ll need a separate beeminder goal for each.
Some questions:
What are the time units for these? Minutes? Weeks?
How are you currently measuring them?
What is your current typical time for each?
Do you need a fully automatic solution or are you happy enough entering numbers manually?
are you thinking more of a “gradually improve over time” goal or an “i always want to respond within 24hours” goal?
I know I’ll need individual goals, and I can scrape the data automatically and post it to the API, but I’m not sure how to best phrase the goals, essentially.
I’m thinking more of a “gradually improve over time” goal.
My first thought would be to do a “do less” for “minutes to respond after initial support contact”. However, on days when I get no support emails (whooo!), I look better than days when I respond quickly to three emails, which is reasonable, but only in a second-order way, which is where I’d rather get no support emails. On the other hand, a day where I get 20 support emails, and respond to them within an hour each, it looks worse than a day when I get 1 email and sit on it until the end of the day.
Additionally, I want to make sure that for the “orders should ship fast” goal, there isn’t a perverse incentive–if it has to be biased one way or the other, I want more orders, not fewer!
Excellent question! I look forward to hearing what you come up with.
For ourselves at Beeminder, we track how often the support email inbox gets to zero. That’s not time-to-response, but may be a usefully related outcome.
For my own urgent tasks, I beemind the sum of the square of the tasks’ ages. This forces me to tick things off or to deprioritise them. There’s no direct system support for that, so you’d need to roll your own.
Perverse incentives are hard to avoid; try to be conscious of their influence, adjust as necessary, and create counter-balancing goals, e.g. something that will tend to increase the number of orders.
I am still thinking about this.
I think the biggest issue here is that I don’t want anything to happen due to time passing. If I have a day without any “things” happening, I can’t be able to fail or gain safety buffer.
Okay so the thing you can directly measure is time per shipment or response in units of [time/thing].
The inverse of that would be [things/time], or rate.
Your example day with 20 emails in 20 hours would have a rate of [1 thing/hour], while the slow day has a rate of [1 thing/ 24 hours].
You want the derivative of that rate to get larger as a Do More goal [things/(time^2)], or the rate of change in the rate.
On days with no “things” the value input would be zero. Given a positive slope, too many zeroes means derailment, so you’re long-term motivated to increase the number of “things.”
It should be possible to, over time, increase your Thing-Doing-Rate by learning/practicing to increase efficiency. Many businesses practice Continuous Improvement ideas with this as a stated goal.
I think you need to beemind distance from the ideal rate.
If R is the ideal rate, and T is the actual time, your data value for each response will be: R-T
You beemind this using a Do more goal.
(Because all the other goal types tend to do odd things when you try non-vanilla goals.)
Set your road rate to 0.
(You’ll need to do this after you’ve created the goal.)
Work out how much buffer you want (in time units) and enter an initial datapoint at that value.
Enter your data as the work comes in and just stay above the road.
When you want to get better, adjust your ideal time used in the calculation.
Advantages:
It doesn’t matter how many you have a day.
The data value calculation is easy.
On a day with no requests you score 0.
You can save yourself from a derailment by responding to the next ones on a day more quickly (if you have them.)
Disadvantages:
You don’t have a normal looking upward sloping graph. (This is fixable with more math.)
Adjusting the slope of the graph can give you more or less buffer but wont effect your target rate of getting things done.
You won’t derail by never reporting any datapoints. (may be an advantage)
Ideal rate changes will not be obviously visible in the graph.
Example:
Your ideal response time is 4 hours.
Start a goal with a rate of 0 and an initial datapoint of 4.
Request comes in at one a day, you respond:
Time : Diff : Data value
4 hours : 0 : 4
3 hours : 1 : 5
None : 0 : 5
8 hours : -4 : 1
Now you will derail if you take more than 5 hours to answer the next one.
The extra math:
To get a regular upward sloping graph, you need to add a datapoint with the value of the Ideal Rate once each day. This can happen independently of any datapoints you enter as a result of processing tasks. As you process the tasks you still only enter the difference from the Ideal Rate.
This may be a better solution as now your road rate will match your target ideal rate and will allow you to derail due to non-entry of data.
I think I might try this. For this goal, I’m fine losing the “derail if you don’t enter data” as I’ll script it so I won’t be entering the data anyway.
Be sure to let us know how you get on with it.
(and post a link to the goal if you don’t mind sharing it.)