I like the idea, but a lot of other factors are missing from the analysis.
1. I’ve yet to find a service that saves 5 hours per week per employee. How do I estimate the actual savings in time?
2. Work expands to fill available time. Will my employee use that time to the company’s advantage?
3. How much does this increase or decrease my personal time required as supervisor?
4. From a financial point of view, I’m still paying the employee and the service, so either I need enough services and time savings that I can eliminate a job, or the service has to have positive ROI of its own.
And probably many more. I often receive proposals of this type, that I could be “saving” so much by buying something. The money goes out up front, the savings are supposed to trickle back in these hard to quantify and use ways.
> I’ve yet to find a service that saves 5 hours per week per employee. How do I estimate the actual savings in time?
Sure you have, albeit by another name likely.
GitHub/Gitlab as a service easily saves more than 5hrs a week.
I have custom slack bots that easily save me a couple hours a week in aggregate.
Then there’s services such as managed CI or, heck even things like the “search” function on a wiki, those are all things that can be provided by a service.
But a tool like this will show you much much it might be worth investing in a service vs hiring someone dedicated and running something yourself.
> Work expands to fill available time. Will my employee use that time to the company’s advantage?
There’s two points to this argument;
1) if I save an employee time, what value does that give me?
2) if I’m an employee, and efficiency is improved; I still have to be in the office 9hrs per day.
The first argument is at odds with the notion that most knowledge worker jobs tend to only be around 40% productive.[0]
There’s no evidence that it goes lower than that; most of the reasons that percentage is so low, though, is friction. Friction can take many forms such as a bureaucratic process for approvals to change things- all the way to “needing to talk to that one guy who knows the thing, and teams is having an outage”. It’s hard to quantify, but there are so many frictions and there is evidence to suggest that removing these frictions increases productivity, not lessens it. (To a value of 80% which represents a significant increase).
(I will supply citations when I get to my pc, this comment is from a phone)
Problem 2 goes into the expectation that if you’re in the office you must be busy- there’s no value to you the employee of the company gets more efficient! Except obviously that’s not true in a more macro sense; I wouldn’t argue that. I would instead argue that the feeling of empowerment that comes with doing actual work and not busywork will make people more engaged and not less.
You wouldn’t feel motivated in your job if you had to assemble your chair each time you wanted to sit in it, it would be tedious and not challenging and certainly cause you to mentally check out.
> GitHub/Gitlab as a service easily saves more than 5hrs a week.
> I have custom slack bots that easily save me a couple hours a week in aggregate.
> Then there’s services such as managed CI or, heck even things like the “search” function on a wiki, those are all things that can be provided by a service.
These are three highly subjective, very unconvincing statements. I use Github, Gitlab, multiple slackbots (some I wrote, some others wrote), managed CI, and a few search services internally in my company every day. I have no confidence that any of them are timesavers in the way that you state.
Slackbots in particular have been shown to use more time than they save (context switching is extremely costly). Github is a source-code host that ads distracting social features, notification queues, etc. all which can add to an employees distraction load and decrease productivity when compared to a more basic code-host.
I'm not saying they don't save time in aggregate, but there's certainly arguments on either side.
I know a company which I will not name, that was passing source-code around with a USB drive.
Their version of an SVN lock was basically 'who has the USB stick right now'. And while this is an absurd and extreme example (and a true one, crucially) you can't deny that github would have saved those developers countless hours.
Maybe even enough hours to pay a person full time to manage something on-site: but that's why this topic (and the OP's site) is interesting, how do we quantify it?
This is such a bad faith comment I don't know where to begin.
Of course no reasonable person is saying that you have to compare against the worst thing, that's stupid- I was simply stating that I've seen things that have easily quantifiable returns.
I'm comparing it against the 'nothing' that I would otherwise have.
If you're comparing something then that's yours to compare, and this is a tool for doing that.
if you're not running github or gitlab, what are you running?
Maybe SVN+jira? or gogs? or gitea? what about teamcity?
I'm not going to break down the cost savings and expenses of each of those, I'm just saying we're all already using services that have saved us many hours a week compared to those services not existing in any form.
Its up to you to debate the 'many forms' a service takes, and remember that server hosting and human time is not free, so something self-hosted that requires some hours of time to maintain needs to be cost controlled for.
It’s bad faith because it speaks to the content of what I said and not the point.
I am one of those people who managed code hosting repositories: but it’s completely absurd to assume that code hosting was without any cost involved at all, and to remove all of the other integrated features too? No. Absurd.
And anyway. The point was making is that we are already paying for services that save us a lot of time- they are of incredible value, and thus universal.
And yes, you might not spend 5hrs a year on _just_ code hosting but code hosting and web view and merge request portals and issue tracking and so on- should those services not be provided somehow (or be provided by something like jira/swarm etc); would easily cost more than that in time.
Hell, even running gitlab is an hour/w job just ensuring that backups are well tested and CI machines are purged, running updates and so on.
It has a low cost, because it’s just one person doing it, but the overall _point_ was that we already have some services that save us time and the parent was not speaking about them.
> it’s completely absurd to assume that code hosting was without any cost involved at all
Noone in this thread is arguing this.
Your original post made some statements about services saving time, as matter-of-fact statements that are apparently self-evident. I replied saying that these statements are not necessarily self-evident nor always true.
It's possible that Github saves you 5hrs a week. This doesn't mean you can say that this is obvious and universal.
I’m not sure if you’re intentionally missing my point or if I’m ineffective at communicating it.
I’m saying that services that are like GitHub are ubiquitous because they save time, easily 5hrs a week- and creating them anew would cost more than those services do if you buy them as a user (gitlab enterprise or github “pro”)
You can argue the minutia of “this service” vs “that service” but at the end of the day those suite of things save time.
> I’m saying that services that are like GitHub are ubiquitous because they save time
Popular services are ubiquitous for many reasons, some of them based on actual value, some of them based on perceived value, and others based on things orthogonal to day-to-day value like organisational inertia, aspects of network effects, etc. They may save time for you. Others may have chosen the service for different reasons: either wise or ill-advised.
> easily 5hrs a week
Subjective. But also, more importantly, subject to error based on your metrics. How have you quantified time saved by Github?
> creating them anew would cost more than those services do if you buy them as a user (gitlab enterprise or github “pro”)
This is, I think, where you're missing my point. Of course creating them anew would cost more than those services do. That's not the question being asked here though. What's being discussed is whether using Github will save you time over not-using Github.
Not using Github does not necessarily mean maintaining an equivalent service itself, because that presupposes that the features provided by Github save you time as is. The only reason you would host an equivalent service yourself is if they definitely do, which isn't a certainty.
What do you propose as an alternative to github/gitlab/code hosting?
I can break down reasons for github/gitlab as a service being aggressive value, however I would be shot down with "but that's not reality, you should compare competitors!" as it was in this comment chain... So I'd love for you to pontificate on the point you're making.
Before git and mercurial I used CVS. It’s pretty easy to set up a server if you have ssh or telnet access. For personal things I used RCS because it was integrated nicely in emacs. So I think one needs to at least compare it to those.
RCS had almost no configuration required. It just wasn’t easily shareable. So, going to git costs cycles for personal projects with the hope of a return from better management of sets of changes, etc.
> notification queues ... which can add to an employees distraction load and decrease productivity when compared to a more basic code-host.
If you think your employees would be less productive if they didn't have a queue of work items to address and co-worker comments to look at and respond to... let's just I wouldn't work at your shop. You running a room full of air-gapped code production units or something?
I think you're oversimplifying. There's a world of difference between "all notification queues decrease productivity" and "some notification queues can decrease productivity in some cases".
Seems something of a divide in interpretation of comments here between people who get subjectivity and people who insist everything is necessarily a binary.
> all which can add to an employees distraction load and decrease productivity when compared to a more basic code-host.
Is a bit naive to think those features are the ones distracting the employees, when if you watch a developer at work 98% of the time-wasters are the strongly attractive ones: YouTube, Instagram, etc.
This is reductionist, I am not the first to fall in line to support github here, but lets expand on what github is instead of assuming.
Github is, primarily, managed source code hosting- but it has more components, so lets break them out:
1: Source code hosting
2: Web view
3: Issue tracking
4: Project management tracking
5: Search
6: Authentication and identity (oauth2 and "applications")
7: Documentation rendering
8: Web hosting (a-la github pages)
9: CI pipeline (github actions)
SVN replaces point 1, and poorly. How many hours do you need to manage an SVN server? Very few I would wager but it at least behooves to ask the question. And it certainly behooves to understand that you're not replacing 1:1; you're replacing many things with one, and managing the above yourself can be done cheaper, but poorer, so that "poor" imitation could cost more time for using it too.
It's a very nuanced topic but an interesting one, and reductionist questions like this are not helpful.
Pull request management, code reviews, CI flows, github actions, github does have many features that other git clients don't, certainly not a self hosted git or SVN repositories, and those features save a lot of time just in the ease of initial setup.
Permissions. I specifically remember talking to Tom and Chris about how that was really the main point of rage that spawned the idea of GitHub (and its original slogan “Git hosting: No longer a pain in the ass”).
Setting up and managing keys, spinning up new repos, etc. would suck up an inordinate amount of time. This was especially true when I worked at consultancies. Blocking developer work with “Sorry gotta wait on Todd to add you to the server and set you up on Git,” when Todd would avoid it like the plague because it sucked would lose a lot of time.
If you averaged the time out, it may not have hit the five hour per week mark, but it combined with other time savers (linking Git directly with the issue tracker for example instead of having to figure out how to cross reference them) easily did/does.
> Setting up and managing keys, spinning up new repos, etc. would suck up an inordinate amount of time.
The claim was 5 hours per employee per week. I found that it took far less than 50 hours a week when working at a 10 person company. And if it did, I'd question the competence of whoever was doing that maintenance.
I'd pin it at closer to 3 or 4 minutes per employee per week, with maybe 8 hours of setup once. That's still a bunch of work, but it's a whole different ballgame.
Maybe not managing permissions directly. But I could easily see a number like that, or higher, being plausible if you consider clean up from junior devs accidentally pushing to development/main branches thinking they were on their feature branch. Which is an issue directly solved by permissions.
> Work expands to fill available time. Will my employee use that time to the company’s advantage?
Take a management class or three, it'll save you a lot of money.
Seriously. If that needs to figure into the evaluation of the service, something is deeply broken in the culture of your company. Not because employees goof off - it happens, and only some amount of that is under your control. But because you assume that given any chance, people would goof off more.
That's far from normal. It usually happens if employees feel mistreated, or if they're not given a fair share of the value they create. Possibly if they're already halfway to leaving.
You’re adding value judgements into it that are not there. A person can be working, accomplishing the same amount, and take 35 or 40 hours to do the task, without goofing off.
> 4. From a financial point of view, I’m still paying the employee and the service, so either I need enough services and time savings that I can eliminate a job, or the service has to have positive ROI of its own.
More likely, there's other work that the employee could be doing that will help your company grow
Under "Service cost" it could use an option for "one time purchase fee". Obviously that is going to create special cases for the "amortizations" output
Cheers, a few people of suggested this. As you note, it rather depends on the amortization period.
At the moment it assumes 1 year for training costs to be amortized over, so I guess one-time purchase would be similar - configurable assumptions (or at list, visibility into the assumptions) is on the list of things to do.
Might be interesting to have a line items for "cognitive cost of having to deal with the crappy in-house tool when you know a good SaaS alternative exists" and "time spent wrangling the finance department"
A cynic might suggest 'cognitive cost of having to use overblown SaaS tools instead of a simple list, calendar event or email/chat message' and 'time spent making additional records in or collecting vanity metrics from the SaaS to justify its continued existence' ought to be in there in the interests of balance.
I was going to say. The biggest cost for most organizations is the recruitment and training costs of an employee that leaves due to demotivation stemming from having to do "robotic" tasks.
An employee who struggles with that is, by definition, no longer at the organization.
So, there is nobody who would tell a decision-maker about that cost.
Another example:
Let's say Company Z has a mailing list with all 200 engineers on it.
Folks such as the CTO and senior leadership use it to announce important events, to send out recordings of meetings. Let's also say that the company has their alerting infrastructure set up so that whenever any service had an exception (server or browser), it emails the stacktrace to this same list.
How does this affect people? There is a wide range:
* Group A: Is naturally unbothered by it. Their inbox is always full but it is no big deal.
* Group B: Finds it to be a minor annoyance.
* Group C: Is seriously frustrated by it, but they just filter all the emails to a folder and accept that they'll miss a bunch.
* Group D: Finds it actively difficult to not pay attention to this, especially because they've heard too many stories about Alert Fatigue. They feel bad about just ignoring all alerts, including the ones for services they maintain.
Group C is going to be less productive and less tapped-in to whats going on. So they will be less influential at the company. Groups A and B are going to be more visibly productive and successful. they will gain seniority and influence. Any member of Group D who does not teach themselves to ignore the alert emails will be so unproductive that they will be fired. They certainly won't have any influence, especially if they keep bringing up niche issues like emails when there are more important things to deal with.
Therefore, from the perspective of Company Z's decision-makers (members of groups A and B), there is not really any cost to continuing to send email this way.
Oh god, those cases when you'd love to try some tool or increase the plan to go over an auditing line but no-one has the energy to push it through the bureaucracy
Hmm, cost of meetings (similar to training costs) is a good idea, definitely an issue I've seen before - thousands of dollars wasted arguing over $50/month for a tool.
Let's plug in numbers. This says that if a service costs 125$/month/employee and I have 1000 employees ($125000/month) I will save ~5 million a year.
However a service costing 1.5 million at such a company has other costs.
Namely that a product that costs that much almost always needs an in house support team. I have never seen the case where an expensive product also didn't need 2-3 people in just to maintain and support it. But the employee time savings is still worth it.
The next cost is much harder. In the tool we said this will save everyone 1 hour a day. However saving people time is not normally what a tool actually does. PagerDuty for example doesn't save people any time, it just sends alerts. Alerts that come from another tool that must be set up. At 40/person/month for 1000 people, that is 40,000 a month for zero "saved time." The value of pagerduty for very different.
But anyone who has been in the field has seen, that list hidden cost is that a paid service isn't normally a perfect fit. It is missing something, or your particular use case doesn't map cleanly. You then have an army of people working around the tool, saving negative time. The business might have reasons to still use that tool. But saving time is not one of them.
So seeing this tool tell me that a service which cost $2,000,000 a year is going to save me $5,000,000 feels like naive marketing nonsense. And it isn't even marketing a product.
> PagerDuty for example doesn't save people any time, it just sends alerts.
Have you tried building a pagerduty in house? That is literally the time save. The "value of pagerduty" is still measured the same way as any other tool.
Do I build it custom in house? Do I pay someone else a modest amount?
That is what this tool is doing and is geared towards startups who make this decision very regularly. It's got 5 question boxes - of course, there's no way it's going to cover an enterprise consideration that needs 3 analysts to decide whether buying that SAP module is really worth $3mm/year.
Someone made a free tool and you're complaining about it as if it shouldn't exist. Very unsupportive.
Perhaps I was overly grumpy. But I get pulled into these discussions a lot. The company now has a very strong newly (2 years) developed "buy not build" mentality.
Half the products we have bought have had full internal teams to support. And many don't suite our needs, so we have enitre development teams building abstractions that are more complex than the product we bought so we can use the product we bought. And some of those abstractions have been in development for 2 years so no one can use the product yet.
My only point is that buying vs building is complex. When you boil that down to a tool that essentially says always buy, it causes a bit of PTSD for me.
I see this alot too. Products that are forced from above and not used, used under gun point etc. Also products that kinda don't fit in and where it would be just better to build it in house since the subset of functionaliy that is needed is quite small, and so on.
Sounds like your company needs to do a little more evaluation and due diligence before buy an off the shelf product. I work at “Megacorp” and it took way less than 2 years to get 20k employees and an equal number of customers onto our off the shelf ticketing platform.
Even if it does boil down to that, there might still be value in ranking the savings per service you buy in. Except for a core product, it is almost always going to be the case that buying in is cheaper than building it. However, having limited resources, it's valuable to work out what tools could give you the best value for money, and which others are a more marginal call (given the uncertainty about support work etc.)
Yup. Took an afternoon. I was being cheap, so you had to give it the name of the cell phone provider along with the phone number.
Most of what pagerduty does was unnecessary for the use case, so the clone was really simple.
Also, pagerduty is harder to manage than the clone (it just had a single text file with a line per user), again, for that use case.
So, time saved is negative per user. However, the clone probably would have been harder to admin over time. It might have needed about a developer-day per month.
Most enterprise tooling I’ve seen is really about shifting work between cost centers. It’s hard to model that in a simple calculator.
Agreed. Pagerduty and similar notifications systems can be life savers for support people. Especially if they are integrated into a ticketing or event management system.
I feel you missed the point (or maybe that the landing page for this tool should better communicate the value and when you should use it).
If you're a relatively small company looking to use a plug-and-play SaaS product with a modest subscription fee to serve some business purpose this is a great tool to get some quick and dirty numbers on whether it would be better to use or maybe build in house or go another route.
If you're purchasing some large, highly configurable enterprise tool (with high implementation and support costs) that all 1k of your employees will use daily and you'd like to understand cost/benefit, other means of calculating this should be used (and it would likely require days to weeks of multiple people's time to make such a calculation).
I see this exact same thing. Let’s take Splunk into consideration. Administrating splunk, all of our feeds into splunk, and trying to keep us from overrunning our quotas is about 1 full time person, and half a full-time person worth of DevOps work yearly. That’s in addition to the subscription costs we pay to Splunk directly.
Every piece of software requires in-house support; even pagerduty and their ilk require management time to set up schedules, adding and removing people. It’s not a lot of time, about .1 to .2 of a person’s time for all of our pageable employees, but a manager’s or leader’s time is not cheap.
Also, splunk is considerably more difficult to use (no CLI, loses jobs, etc) and less powerful (no joins, incomplete results) than a farm of Linux log servers and some ssh tooling, such as cluster ssh, or whatever.
There’s also the question of whether the splunk log agents are more or less of a pain to administer than whatever log management they replace.
Finally, there’s the question of how the resulting reports shape people’s behavior and productivity.
If you add that all up, learning it is a waste of time for people that can code up a join in perl from muscle memory, but it saves training time for people that can’t.
In the end, every one less productive than they would be with some other tool.
What's this type of calculator often misses is how nuanced and complex is to estimate the cost of employee time.
It's not just the cost of an employee salary per hour... Is the opportunity cost of everything that employee could have instead done.
After all it isn't as though with more money you can just immediately get more fully ramped sophisticated employees to add value... All of that is complex.
There is also the cost of not understanding details that you left to someone else. If you save time but no longer know what is happening you can get into big trouble when those details matter.
This looks really cool. I put in some numbers for a service that I am considering, and the answer was the opposite of what I was intuitively expecting, which proves the need for something like this.
Some feedback:
- s/(one person)/(per person)/g
- The "cover costs" section doesn't really make sense to me. For example, in one example, the breakdown says that I will burn $10000 extra, but that I will also cover costs with 23 hours of use. How does it know how much use it will take to cover costs? How does it know how much profit is generated per hour of use? Am I misunderstanding something?
- It would be nice if the formula used was displayed in small text or in a tooltip or something.
The "cover costs" assumes your people will use the tool 8 hours a day. By the productivity you gain, it calculates how much you save in salary.
The "free up an hour" also assumes your people will use the tools 8 hours a day.
The "cover costs with" calculates how much your people must use the tool for it to eventually pay for itself. If it's larger than 8 hours, then the tool will never pay up.
I've been going back and forth on whether or not Hey is worth it for me. I really liked my trial, but $100 just feels like a high price. But according to this calculator I'd only have to value my free time at $3/hour to start "saving money".
For simplicity there are a whole host of underlying assumptions about what a work day is, what time spent means , etc.
Explaining at least some of those assumptions is on my list of improvements, but there will never be a 'correct' answer in a generic form like this. It's more intended as a quick investigation/conceptual check.
Okay I really like the idea. I think the bottom line whether the SaaS is worth the cost with the premise is that the SaaS saves time. However, time saving (item 4) is pretty difficult to gauge. Therefore, I suggest having a version where time saving is the output.
So then the question become, I have to believe that this SaaS will save XXXmin per employee for me to consider buying it.
I think a lot of users are missing the point. I don't see this tool as a final decision maker and it can never be one. The final decision has a lot of nuisances to that it is difficult to capture in one tool, so might as well just open a spreadsheet and bang it out.
I see this tool as a quick a simple way to eliminate all the tools that might look shiny and slick or save a few clicks, but doesn't actually save employee's time at all.
So the decision becomes, I like the way this new SaaS feels or looks than our current one, but is it really worth the additional cost?
Exactly, and scale is important too. The initial target audience was small (as in very small, maybe 1-10 people) businesses, whose owners often don't intuitively understand how beneficial small services costs can be.
In 99% of the cases, I rather buy the service than develop it from scratch and support it long-term. Most consumer-facing services I've seen are relatively cheap. I only tend to develop existing things if I find there are some functionalities which either I cannot buy directly or they require a special setup that does not go well with security and other constraints.
This is look at the cost, but what about value? Say, the total cost per hour (salary, insurance, benefits) is 50$, but how mych value does he/she create?
I used to do this calculation with 2x assumption. Say, a new IDE plugin saves 100 engineering hours, so it's 50 000 in cost and another 50 000, because they spend time creating features.
The two biggest line items are not easily measured and thus not included: The removal of an external dependency that you don't control and may not evolve with your needs, and the loss of the continuous improvement in that dependency without continuous investment from you.
but there's a hidden cost, that's never spoken of. cost of forgotten knowledge or expertise. say you use AWS RDS | Aurora, on paper it's cheap. AWS runs everything for you. what happens, when one day you need the knowledge to run your own db ? or migrate to something different altogether ?
If you're honestly appraising costs, the same evaluation would apply to on-prem as well. 3-year refreshes, software updates, support, power, bandwidth, etc
Good tool, but, as someone mentioned, there are a number of other factors.
1) Brand reinforcement/damage.
This one is really hard to quantify, but can mean the difference between the life, or the death, of the corporation. If the tool we choose causes some damage to the brand (like not giving us the ability to display the brand in an appropriate manner), or introduces a brand-damaging problem (like causing a particular kind of service to have an extra step or two, or even amplify customer pain), then there could be issues.
On the plus side, it could also significantly fortify a brand, by doing things like having the brand appear in places that were disregarded, or considered "out of reach," or it could amplify the advantages of a brand-connected service.
Branding is a "dark art" to many literal-minded folks like engineers, but it is unbelievably valuable. It should always be considered, when thinking about things like this.
This morning, I had this demonstrated to me in a visceral manner. I made an order yesterday, and asked for expedited delivery. When I made the order, it said the expedited delivery would arrive today, but when I received the confirmation, it said the order would arrive tomorrow.
Sound familiar? Amazon is notorious for this nasty little trick. Most of the time, it's Prime Delivery, which means we don't really have much room to complain.
It wasn't Amazon. I won't name the corporation, but it is one that is synonymous with extremely high (arrogant, even) quality.
This silly little trick, with a cheap, third-party item, caused brand damage with a loyal customer that has spent six figures with them. I won't drop them, and the world won't stop turning because I won't get my item until tomorrow, but the simple fact that they did the "shipping bait and switch" on me, means that I'll never use them again for this kind of purchase.
That's brand damage.
To add insult to injury, when I tried contacting them about it, I had to run the gauntlet of what I call the "AI Picador," which throws as many roadblocks as possible in your path, before allowing connection to a human.
This workflow ensures that I will be steaming mad before I get to the human, and it's all I can do to avoid venting to them (it isn't their fault -it's their bosses').
2) Staff morale.
Will bringing in the service reinforce or damage staff morale? It may help folks do their jobs a lot easier (good), or it may result in a lot of folks losing their jobs (bad, or very bad, depending on many factors, like how the layoffs are done, and how the folks that remain are treated).
3) Dependence/Addiction
If bringing in a dependency ties us to a corporation/language/toolset, is that good or bad? It may be quite good, if it's a good service, and a good corporation, but it could also be incredibly bad.
If you're big enough for your brand image to be damaged by your bug reporting tool, customer analytics or payment flow having a third party logo, you're probably more in the realms of paying for the enterprise grade white labelling offering than 'are ten seats worth the money' anyway. Of course you can definitely wreck your sales with spammy use of email automation tools or evasive customer service, but that's more to do with how tools are used than the third party involvement.
And if SaaS is valuable enough to actually replace staff you've outgrown the simple decision making aid too, although I agree that you can dent morale at the margin by introducing SaaS oriented towards micromanagement or somewhat improve it with less crappy processes even with the simplest of software changes.
For smaller organizations, the "plus" could outweigh the "minus."
For example, if the "beancounter" calculation says that the SaaS tool is "not worth it," but bringing it in might significantly project the brand, then it may be worth it, in a big way.
Same with advertising, but advertising is a bit easier to measure (after the fact, as opposed to before). Brand value is really difficult to measure in any kind of empirical manner.
But a bug reporting tool, if exposed to customers, is a very important branding surface.
Error handling/reporting is a huge deal that is often neglected by tech folks. For many of us, a console print or log entry may be quite sufficient, but for an end user, they may need a lot more HI.
I've encountered some ghastly bug reporting tools that were obviously designed by techs, for techs.
ha, awesome! I've had this idea so many times from the xkcd comic (which I see was inspiration). I'm glad someone actually built a tool for it. It could be a fun learning project for a simple mobile app too.
This is great! Walking through the numbers mentally kinda works, but it seems people are always suspicious they're being had. Seeing it live will be very reassuring.
1. I’ve yet to find a service that saves 5 hours per week per employee. How do I estimate the actual savings in time?
2. Work expands to fill available time. Will my employee use that time to the company’s advantage?
3. How much does this increase or decrease my personal time required as supervisor?
4. From a financial point of view, I’m still paying the employee and the service, so either I need enough services and time savings that I can eliminate a job, or the service has to have positive ROI of its own.
And probably many more. I often receive proposals of this type, that I could be “saving” so much by buying something. The money goes out up front, the savings are supposed to trickle back in these hard to quantify and use ways.