Could your customer support portal use some flowcharts and diagrams to help customers trouble shoot problems? If you're in the Hi-Tech or manufacturing sectors, the answer is probably yes.

Visio has been my tool of choice for several years, but today I stumbled on a web-based flow chart designer called Gliffy that really impressed me.

I evaluated Gliffy by recreating the channel lead registration workflow I published a few days ago, and as you can see from the image below, the result isn't too shabby for 10 minutes of effort.



Gliffy can host the JPEG images for you. I can easily envision using Gliffy in customer portal knowledge base articles to help with trouble shooting.

I also use Visio when chatting with customers on the phone to help remind me of a customers business process requirements or campaign workflows. With Gliffy, I can simply email customers a link to these flow chart sketches to get some quick feedback.

The site says it's in Beta, but you would have to have some pretty high expectations to even notice. The workspace behaves and reacts just like a desktop application. Even the CTRL-Z undo key combination works! Although, I did find it more useful to rely on frequent saves and versioning as a wiser recovery option.

Gliffy definitely follows the Pareto Principle of determining which 20% of desktop features provide 80% of the value.

Very cool.... I give Gliffy a big thumbs up.

For those who are interested; the i-Dialogue change log can be found here.

A typical dialogue between channel sales managers and indirect sales representatives is the management of Leads and Opportunities.

The Channel Manager has oversight of each partners opportunities and acts as a referee in situations where 2 partners are pursuing the same opportunity.

i-Dialogue PRM Portal helps to mitigate channel conflict with a database of Channel Registrations that associate Leads and Opportunities with specific partners. i-Dialogue also sends email alerts to partners, such as reminding a Sales Rep that their opportunity registration will expire in 60 days unless updated.

Here is a typical channel registration workflow managed by the portal.

The process is not completely automated. An internal Account or Channel Manager must intervene in the early stages to determine if a submitted registration conflicts with an existing registration.

The ability to identify and resolve conflicts is directly associated with the quality of data collected by the portal. "Company" or "Account Name" is the most common identifier of exclusivity, but territory, industry, or product type may also be used.

To this end, the first report created in the CRM system should be a quick list of all open channel registrations by Company name. The portal could "attempt" to identify a conflict based on Company name, but because of variances in spelling (such as "IBM" or "I.B.M") this task is best left to human intervention.

Once a registration has been assigned, the portal loops 1-N times over step 6, sending out emails every 30 days (this is customizable) to help gently "prod" the partner to touch the prospect and update the CRM record.

What happens if other Partners register the same opportunity? In this dialogue flow, the conflict may be noted as an activity and later re-assigned to other partners on a "first come, first served" basis.

Because the registrations are managed as Opportunities in Salesforce, existing reports can be leveraged for forecasting and demand planning.

Thanks for posting this list of Salesforce Partners Mark! Time to update my blogroll.

Here's a quick tip for high traffic eContact Centers:

The first question on every Web-to-Case form should always be "Have you already searched the knowledge base? Yes/No" with a link to the KB immediately following.

While I haven't done a page abandonment analysis on this to prove it, I estimate it reduces the total number of submitted cases by 10%-40%.

Tip #2 (even better):
Prior to submitting the web-to-case form, have the customer enter a problem description then search the KB on the customers behalf; showing the top 10 most relevant articles. Then ask the customer if the articles did not address their problem before allowing them to submit.

Jennifer makes an observation that she'd like to see a collaborative online scheduling service that supports a customers ability to make appointments online with the business owners ability to publish available dates, times, and resources.

Funny you should mention this Jennifer, as I was just contemplating this service myself. In addition, I think the service should send automated appointment reminders. I know my Dentist and Accountant could use such a service as "no shows" cost them money.

All of the basic components are available to do this (we did something similar a couple years ago for a Healthcare Patient Self-Service Portal). Maybe it's time to seriously revisit this solution within a Salesforce.com context?

I was working with a Salesforce account hosted on their new NA3 instance (NA=North America) when it suddenly stopped working. No.... I'm not blogging to complain about the brief outage, but it did give me a moment to reflect on various technology inflection points over the past several years and their likely quarks that were dutifully suffered, knowing that things could only improve.

Inflection Points and their related detracting comments:

1) "Use the public utilities for electricity? No way. What happens when they go down or the power is not clean?" (OK. Maybe a little before my time)
2) "Personal computers? Those are just toys."
3) "Graphical User Interfaces? I can type faster than I mouse. Real programmers don't use GUIs."
4) "Windows in business? Rebooting from the 'blue screen of death' 10 times a day will actually make you less productive."
5) "The Internet is too slow and limited to just web forms. Client-server business apps are much better."
6) "Don't the frequent Salesforce.com outages bring your business to a halt? I wouldn't run a business on hosted software."

Of course, the detractor making the final comment is viewing their latest pay stub online from a Windows business laptop that is plugged into the public power grid.

A quote from this article caught my eye:

"If SAP sells a system today for $1 million, they recognize the million dollars on the day they sell it and it goes into the revenue for that quarter," he said. "If they were to sell that same system as a software as a service, they may get $20,000 per month for the next 10 years."

Hmmmm... my experience with $1 million+ ERP solutions is that a significant portion of that revenue is in Professional Services, which must be recognized incrementally anyway.

Also, the larger ERP vendors are deriving the majority of their revenue from annual maintenance contracts, not new license sales. So they essentially have to resell their solution to the customer every year, creating a volatile environment for forecasting future revenue.

Yes... a month-to-month SaaS model means that a customer can leave at their convenience anytime. Is this what vendors are concerned about? The benefit of this model is that it drives innovation, higher quality of service, and forces vendors to deliver a dollar of value for every dollar billed.

Having spent the past 12-18 months working with Salesforce.com and other web services, I can't help but wonder if i-Dialogue's core competency is drifting away from Software Development and gravitating more towards Systems Integration (SI). Or is it a combination of both?

Designing and developing solutions using a Service Oriented Architecture (SOA) requires a certain external locus of control that SIs are more accustomed to, whereas traditional Software Development is more about internal control.

Does SOA inherently force a balance of these two skill sets, or is it just the "portal hub" nature of our solutions that require these skills?

I must admit that having the resources of thousands of other Developers and solutions at my disposal is a much more attractive option than attempting to re-invent everything myself. I love "looking out" to the solutions available and leveraging our core portal integration platform to bring multiple applications and services together.

It's all about the "whole solution" concept. It's irresponsible, in my opinion, for SMB business software vendors, to require clients to take their solutions across the finish line. The IT staff at many companies are already over worked. I believe the entire deployment process of an on-demand solution should be easily managed at the business decision makers level within an organization.

The art in SOA systems integration, I believe, is in writing code that completely hides the seams. Perhaps I'll itemize the lessons learned later in this blog, such as my conformance criteria for single-sign-on, data types, ETL, IDS monitoring, user interface, SOAP interface, and database persistence.

OK.... I think I get it now... I've fielded 3 calls in the past week asking about i-Dialogue Live Chat. What is the integration with Salesforce? How much is it? How does it integrate with our current site?

The original intent was to include chat as an add-on to i-Dialogue Suite, but clearly people would like to see this as an independent solution.

So, here's the roadmap for the next release:

• i-Dialogue Live Chat will become an independent solution and published on the AppExchange
• You can add a "Chat Now" image or link to your own web site
• Chat visitors automatically become Leads in Salesforce (assuming Email is collected)
• Chat transcripts are associated with Lead records.
• Administrators can grant Salesforce users with Live Chat Operator privileges
• Chat will be independently priced with a per user monthly subscription

For .NET Developers, I recommend checking out Absolute Live Support (ALS). Our chat solution is based on ALS... we're providing the systems integration to Salesforce and on-demand hosting through an agreement with ALS's Developers.

Bill Gates announced today that he will step down from a full-time role at Microsoft over the next 2 years. So what is the impact?

I believe the subsequent promotion of Ray Ozzie to Chief Software Architect signals that Microsoft is sincerely focused on web services. Had Gates successor been someone too tied to the Windows OS or Office, I would have been concerned that they weren't aligned for the upcoming "Web 3.0".

So kudos to Bill.... I agree with Steve Ballmer when he says Bill Gates will probably become the greatest Philanthropist in recorded history.

Best of luck Bill!

That might be what "The Dalles" Oregon is renamed to once these Google data centers go online and start reving up the local economy. The datacenters, each of which are about the size of a football field, are about 90 minutes away from our office in Portland, OR.

Some "pros" about this location:
+ Plenty of hydropower. No chance of brown outs
+ Direct access to Columbia river for cooling servers
+ Sits on a dark fiber loop that has gone unused for years
+ Low year round avg temperature relative to California
+ Within an hour (or so) of major airport
+ Within a couple hours of Intel fabrication plants

Some "cons" about this location:
- The local hiring pool knows a lot more about windsurfing than computers
- Gets isolated during Winter ice storms (salting the roads to Portland is not allowed)
- Windy!
- No gourmet chefs
- You won't find any O'Reilly books in the local bookstore
- Really really close to Mount St. Helens

Salesforce.com has great Case Escalation rules that give Support Managers peace of mind that cases will not go unattended for too long. But how do Sales and Channel Managers get the same peace of mind that their assigned Leads are not going untouched?

I first started trying to solve this problem using the Salesforce workflow capabilities, which are excellent for initial lead assignment, but I quickly ran into issues trying to escalate a Lead.

For example, if I assign a Lead to a Partner, I want the following rules to apply:
1) The Partner has 48 hours to Accept the Lead (in case they're on vacation)
2) The Partner has 1 week to update the Lead record
3) If the Lead is not converted in 30 days, send the Partner an Alert
4) If the Lead is not converted in 60 days, send the Partner and Account Manager an alert
5) If the Lead is not converted in 90 days, reassign the Lead to Account Manager

I came up with some semi-workable solutions using available tools in Salesforce that were limited to internal users, but didn't work for Partner contacts (of course, now that I post this, someone will probably publish some clever way to accomplish this ).

The solution I ultimately came up with was to develop an escalation rules engine using custom objects and the AppExchange API. The design is patterned after the best features in Salesforce Case Escalation Rules and Workflow and targeted specifically at sending email alerts to Users and Contacts at predetermined intervals when certain criteria are met.

Creating a workflow engine in a forms-based user interface environment presents a unique set of challenges. Graphical flowchart visualizations are usually best for depicting complex Lead escalation rules, but this wasn't an immediate option.

(As an aside, we did develop a prototype graphical workflow engine for i-Dialogue last October using Windows Workflow Foundation, but this lacked a web-based interface. Salesforce Product Managers also have this feature on their roadmap, so who knows... It could be available within 12-18 months from someone.)

As you can see in the screenshot below, the forms-based rule designer didn't turn out so bad. In fact, you could argue that this approach is easier for most business users since the rule reads from top to bottom like natural language English:

"If a Lead is not accepted in 48 hours, reassign it to the Account Manager".

I've run the gamut on net neutrality, sympathizing (and even empathizing) with every view point, but I'm now of the opinion that everyone's best interests can be served without any legislative regulation.

Why? Because I think an open and free market will simply take care of telco's that create Internet "slow lanes".

I can just imagine the marketing campaign now with a Tortoise and Hare making their way down an information super highway:

"Is your Internet access provider moving you into the slow lane?
Signup for XYZ Internet access today. No slow lanes!"


Now, there is one catch. What happens if there isn't a competitive market? A telco owning a majority stake in the Internet backbone infrastructure could effectively monopolize the network and successfully create a multi-tiered Internet.

In this case, existing monopoly and fair competition laws would address this issue, as was done in 1984 with the Baby Bells.

It looks like the Salesforce NA1 migration window is going to be next Saturday, June 17th starting at 10am PDT.

Salesforce is recommending that all API integration processes be stopped during this window. We will comply by suspending all hosted NA1 portal integration processes during the migration window.

I don't anticipate any problems, but will personally monitor the situation over the weekend to ensure integration resumes on Sunday the 18th.

Google Spreadsheets appears to be carefully crafted at both the Marketing and Engineering levels.

First off, you need a Gmail account to use spreadsheets (correct me if I'm wrong on this), which feeds well into Google's identity management strategy.

Secondly, you can only share Google spreadsheets with other Gmail users, forcing you to invite others into the inner circle to view and edit the spreadsheets.

Third, Google obviously has the future option of publishing AdWords in spreadsheets, calendars, and writely, leading to more PPC revenue and growth.

It's a viral and virtuous cycle, but the privacy and security questions still remain.... how much are you willing to trust your spreadsheets on Google?

I might be tempted to email quotes to customers, but probably wouldn't pull the trigger at this early stage.

I signed up for Google Spreadsheets beta launch this morning and received an invite to test it this afternoon.

All I can say is "Holy Cow" .... simply amazing.

It's been a few years since releasing our last channel management solution (which was for Epicor CRM), so it was an obvious choice to integrate i-Dialogue with Salesforce.com to develop a Partner Portal solution.

Salesforce seeded the AppExchange with some spectacular PRM Channel Management solutions earlier this year that quickly got my creative juices flowing. So now, in addition to Lead and Opportunity management, there is also support for online requests for Marketing Development Funds, Refunds, Special Pricing, and Demo Units.

Also, some there's some clever email escalation, lead forwarding, and reassignment features built-in. It looks like a formal release and announcement will be the week of June 19th. Pricing is already available.

Service Level Agreements (or SLAs) for Software-as-a-Service models (SaaS), as it turns out, can be quite tricky. On one hand you need to address the customers right to "get what they paid for" and on the other hand you need to limit the businesses exposure to risk so that it stays operational through good times and bad.

There's really no precedent in the industry for these types of SLAs. Salesforce.com does not have a SLA, while others guarantee 99.9% uptime and credit claims. With such extremes and lack of precedent, where does one begin to craft a SLA?

Firstly, i-Dialogue is a software-only company. We've outsourced the network and server infrastructure to a secure datacenter operation that lives, breathes, and sleeps with details that software developers don't need to worry about (like which RAID level configuration to use on database server disk drives).

This infrastructure provider takes great pride in their 99.9% uptime guarantee and offers a SLA with credit claims, so it's only fair to pass this on to our customers, albeit in a pro-rated form.

Secondly, i-Dialogue portals integrate with other 3rd party services, such as Salesforce.com and Google.com. Our services will continue to work just fine if these 3rd parties go down for planned/unplanned maintenance, but service oriented SLAs must be crafted in a way to reflect this.

Finally, there are lots of layers to SaaS applications and traditional Internet key performance indicators (KPIs), such as Page Response time, can't be tied to just one layer of responsibility. For example, a 10 second page response time with 1,000 concurrent users is a clear indication that the network or hardware service layer needs to be upgraded. But with only 10 concurrent users, this would very clearly be an application layer problem.

Our current SLA is a step in the right direction. I believe it conveys the right message to both customers and employees that we're vigilant in maintaining quality services and solutions.

But there is room for improvement and more balance; not only in our SLA, but the industry as a whole. Do you have any thoughts on fair KPIs for SLAs? Let me know.