Supporting your app: how to ensure post-launch success

Building an app is hard work, and once the app goes live, it’s tempting to sit back and wait for the money to roll in. Unfortunately, there’s still work to be done. More often than not, companies tend to underestimate how much support is required after roll out.

In an effort to save you from some painful lessons, we’ve outlined some things to take into account so you can deliver your app to market successfully.

Case Management

First and foremost, a successful go-to-market strategy requires a case management system. Cases are most often the result of bugs, and no matter how thoroughly you tested your app, bugs are an inevitability. Generally speaking, quality solutions can resolve these issues quickly, but you still need a way to track and resolve your app’s inadequacies.

There are many case management solutions to choose from that offer unique options of engagement: Salesforce Service Cloud, Zendesk...and yes, even standard email. Touch points include everything from phone to email to chat, so selecting the model that is right for your budget and size is important. The more extensive the communication options, the more costly the system.

Once you’ve selected your system, you’ll need to develop a proper methodology to manage the cases. Escalation, prioritization and case categories must all be considered. Cases can be divided into four types:

1. CRM bugs: doesn't work as intended for a particular architecture. No matter how much testing you do, there are bugs that arise once you’re in a live instance.
    
2. Solution bugs: doesn't work as intended. The solution is broken and does not work as it was designed to.
    
3. Feature shortcomings: works but does not meet client's workflow process due to the solution’s lack of depth. This is usually associated with client preference. The feature may behave one way while the client wishes it would behave another. You have to decide whether you want to adapt the solution to your client's needs, or stay firm with the current features and risk losing the client.
    
4. Feature vacancy: solution does not have the features you claim it has in promotional literature. A rush to production can cause features to be overlooked. That said, you should make sure to test your solution again in production to minimize feature vacancies.

Once you’re aware of your solution’s expected inadequacies and have selected a case management solution to track them, you can then design a methodology to facilitate the escalation of the logged cases. Below is a brief methodology designed to work with standard Salesforce case management.

Keep in mind that any app development process needs ongoing refining

Case Management Process Flow:
Sample Organization

System:
Salesforce Standard Case Management

Escalation Tiers:

1. Can be facilitated by standard customer service. No technical skill required.
2. Requires some level of administrative skill to resolve.
3. Requires some level of developer skill to resolve.

Case Management Load Projection:

Most customer service falls within tier 3 (Roughly 85-90%). Roughly 15% could be facilitated at tier 2 or tier 1. Sample Organization is facilitating a case management system that will manage primarily at the developer level.

Case Management WorkFlow:

1. Sample Organization attempts to field question at tier 1 within one hour of research.
2. If unable to field question email is forwarded (with history) to tier 2 with a project case reference in the subject field: "Orgname_Broken Link_061312_2" (i.e. Name of client_case concern_date case was originally logged_tier of escalation).
3. If case is solved reply go to Sample Organization (not client). If case is not resolved case is advanced to Tier 3 for review (making sure to keep the subject field the same -- changing the last number to 3). Tier 3 will be given 30 minutes to find a resolve.
4. If case is resolved, reply go to Sample Organization (not client). If case is not resolved, case returns to Sample Organization for project development concern and moved to a road map issue.

Case Management REVIEW TIME:

1. 30 minutes to review topic. 30 minutes to research solution
2. 30-60 to repair solution (or escalate to the next tier).
3. 24 hours response time allocated for each tier escalation.

It’s important to note that the case management solution you select can have a direct impact on the methodology you deploy. This needs to be worked out with your consultant while taking time, budget, and resources into consideration.

Product Enhancement

The second step for building strong support for your app is product enhancement (or optimization). This is when you need to evaluate which feature sets are “must haves” and which are “can waits.” These features will be added to your development roadmap and promoted on your website. This will help your clients stay patient while they wait for the release and reduce the number of logged cases.

The best way to build your roadmap is through two processes: the number of cases logged toward a particular feature request, and by vote. Number of cases works best to vet the features that are most important, whereas voting determines which features are most popular. To gather votes we generally suggest Salesforce Ideas, but a survey page on your website is an affordable alternative. The key is to get your customers to help you with the evolution of your application. Give them the opportunity to comment and you’ll receive valuable information that will help ensure user adoption in the future. Best practice is to deliver releases quarterly; any more can be a burden on your team.

System Integration

Finally, once you launch the application you need to be prepared for general integration questions. A case management solution is part of this, but it is most important to have an accessible developer and a clearly mapped ERD (Entity Relationship Diagram) to share with both clients and partners. The ERD is likely the most overlooked consideration in the three mentioned here. Your ERD will help developers understand the architecture of your solution and can tell them how and where to integrate effectively. Workflow documents may also be offered as a supplement to the ERD. It is important to note that ERD can range from very high level to very specific. The more specific, the less engaged your developer will need to be during an integration effort with a third party solution.

Here’s an example of an ERD:

Source: http://www.datanamic.com/support/lt-dez005-introduction-db-modeling.html

Your system integration process will ultimately reveal your competency to those who evangelize your solution the most: consultants. If you are unable to speak clearly and effectively on this topic, the 3rd party solutions you work with will be unlikely to speak fondly of your app.

These considerations and tactics to effectively supporting an app require planning and practice. If you’re looking into building an app, let us know. We’re happy to help!

Get help with your app