Dear Bob ... Thanks for replying to my question (What scales, what doesn't, what's relevant, and what isn't). As usual, everything you say is true. Unfortunately, it isn't what I need. I do understand what "truly scaling well" and "not scaling well but salvageable" mean. And the processes I have in mind are documented strategies, not "figuring out ad-hoc". In fact, when people reject these strategies often they' Dear Bob …Thanks for replying to my question (What scales, what doesn’t, what’s relevant, and what isn’t).As usual, everything you say is true. Unfortunately, it isn’t what I need. I do understand what “truly scaling well” and “not scaling well but salvageable” mean. And the processes I have in mind are documented strategies, not “figuring out ad-hoc”. In fact, when people reject these strategies often they’re only offering up “figuring out ad-hoc” as a replacement.As an example, following your help-desk lead: a help-desk application accepts tickets for issues automatically in response to e-mail to a specified address. A new ticket is always created for each e-mail, because the automated gatekeeper can’t read the messages. As a result, many new tickets are created that are actually follow-ups from an original, where the originator, having received a confirming e-mail with a ticket #, is trying to add new (helpful) information into the issue.Current status: there are many bogus tickets, literally destroying help-desk metric reliability, *and* the information related to a particular issue is scattered among many records. Because of the second item, help-desk people almost never research an issue by looking into existing tickets to see if a remedy is already recorded. Proposed remedies: whether replaced by a human or re-written program, the gatekeeper has to be more intelligent. Also, help-desk procedures should have a “research” step, queries into existing data, preferably at gatekeeping point as well as during resolution. These proposals are independent of one another; both are considered “not to scale well”. I think you can see what the answers to “why” would be in this example, as well as why they would be mostly-specious. Unfortunately executive patience with the discussion would have already been exhausted by the first round of the exchange.– Still Scaly after all these years Dear Scaly …Sometimes this happens – I give a great answer, but to a different situation than the one you were asking about. Before giving up, let’s take another run at it.Having recently re-engineered a client’s incident management process, a few thoughts occur to me: 1. Another possible response to, “But it doesn’t scale,” might be, “I can see some weaknesses to this, but I don’t think they’re scaling problems.”2. “Okay, I’ll buy that my recommendation doesn’t scale. But I think if we start over we’ll just be replacing one set of problems with another set of problems. We have one major weakness with the one we have – the process doesn’t connect follow-up inquiries to the original ticket. Let’s see if we can fix that instead of starting from scratch.”3. We went down the e-mail ticket submission path in our redesign and rejected it, in part because of the potential for what you describe. Instead we went with an on-line form on the intranet, which included the ability to connect a new inquiry with an existing ticket. I hope that’s more helpful.– Bob Technology Industry