Support

Maintain

The Maintain sec­tion of sup­port is in­tended to pro­vide cus­tomers with on­go­ing sup­port and main­te­nance for their ap­pli­ca­tions. Engagement with Support needs to be con­sis­tent so that you have some­one with a good un­der­stand­ing of the pro­ject avail­able to quickly re­solve ap­pli­ca­tion and in­fra­struc­ture is­sues. Infrastructure sup­port (via a Managed Service Provider) in­cludes en­sur­ing your ap­pli­ca­tion is up and run­ning, as well as main­tain­ing the server, data­base and other ser­vices used by the ap­pli­ca­tion. Application sup­port is gen­er­ally fo­cused on prob­lems dis­cov­ered by users that are hin­der­ing them from en­gag­ing with the ap­pli­ca­tion as they ex­pect. In soft­ware prod­ucts these types of de­fects and in­fra­struc­ture is­sues can arise of­ten and should as a re­sult be pri­ori­tised based on their im­pact to the user.

Underpinning the sup­port phase are three lev­els that de­fine how a sub­mit­ted ticket will be han­dled, and by whom.

Level 1: Basic help desk sup­port

Level 1 sup­port is the first sup­port tier within any op­er­a­tion. It is usu­ally pro­vided by lower-level IT sup­port per­son­nel but can change de­pend­ing on the con­text and re­quire­ments. Typically, tasks re­quired here are col­lect­ing cus­tomer re­quire­ments, han­dling calls and ba­sic trou­bleshoot­ing to mit­i­gate the im­pact of user cen­tric prob­lems.

Level 2: In-depth tech­ni­cal sup­port

Level 2 sup­port is han­dled by a trained sup­port de­vel­oper able to triage, es­ti­mate and re­solve is­sues with an ap­pli­ca­tion. Pre-requisites for han­dling these re­quests is hav­ing knowl­edge of the sys­tem, un­der­stand­ing its ex­pected be­hav­iour and hav­ing ac­cess to rel­e­vant in­for­ma­tion or peo­ple. It’s im­por­tant that any res­o­lu­tions are han­dled us­ing stan­dard de­vel­op­ment, test­ing and qual­ity prac­tices.

Level 3: Expert prod­uct and ser­vice sup­port

An is­sue is typ­i­cally de­ferred to level 3 once all lay­ers of sup­port de­vel­op­ment have been ex­hausted and the orig­i­nal, or a more se­nior soft­ware de­vel­oper needs to ad­dress the re­quest. These de­vel­op­ers will have the most ap­pro­pri­ate level of knowl­edge and in­for­ma­tion avail­able to them to re­solve the is­sue. To save time and ef­fort, it’s im­por­tant that all in­for­ma­tion cur­rently gath­ered through the first 2 lev­els is trans­ferred to level 3.

External ven­dor and sup­plier sup­port

Outside of the lev­els de­fined, some­times ap­pli­ca­tion prob­lems come from out­side the or­gan­i­sa­tion that de­vel­oped the ap­pli­ca­tion. In these cases, level 2 and 3 sup­port need a mech­a­nism to iden­tify ven­dor or sup­plier is­sues that need to be de­ferred to the sup­port mech­a­nism of the rel­e­vant par­ties. If you source any­thing from ex­ter­nal ven­dors or sup­pli­ers, it’s im­por­tant to have a chan­nel avail­able to gain sup­port in these in­stances. A good ex­am­ple here is in­te­grat­ing with a pay­ment gate­way, where that gate­way’s API re­quires its own fix to work on other ap­pli­ca­tions.

Continuous sup­port

Even though a build has en­tered sup­port, this does not mean that a cus­tomer needs to stop work with a Delivery Team. Once a ver­sion of the ap­pli­ca­tion has been re­leased to pro­duc­tion, the sup­port team will be able to han­dle the ac­tive main­te­nance and im­prove­ment of that build. Meanwhile, this al­lows the other teams to be­gin fo­cus­ing on the next prob­lem state­ment, scope and sub­se­quent it­er­a­tion of the prod­uct. Once that sub­se­quent de­vel­op­ment cy­cle is ready for pro­duc­tion, a sim­i­lar flow can be­gin, to han­dover the next ver­sion of the ap­pli­ca­tion for sup­port.

Request Types

Product Owners, or in some cases their users, can sub­mit tick­ets to sup­port. Tickets tend to come in the form of de­fects, gen­eral ques­tions or im­prove­ments. Submitted tick­ets re­quire time to triage, repli­cate, di­ag­nose and at­tempt to re­solve the is­sue. Tickets that are im­prove­ments will be de­ferred to a sep­a­rate Enhance process for proper elab­o­ra­tion prior to de­vel­op­ment. To man­age the pri­or­ity of re­quests, prod­uct own­ers are asked to as­sign one of the sever­ity lev­els de­fined be­low.

• Blocker: Produces an emer­gency in which the soft­ware is in­op­er­a­ble, pro­duces in­cor­rect re­sults, or fails com­pletely. 

• Critical: Produces a detri­men­tal sit­u­a­tion in which per­for­mance of the soft­ware de­grades sub­stan­tially un­der re­spon­si­ble loads, such that there is a se­vere im­pact on use.

• Major: Produces an in­con­ve­nient sit­u­a­tion in which the soft­ware is us­able but does not pro­vide a func­tion in the most con­ve­nient or ex­pe­di­tious man­ner.

• Minor: Produces a no­tice­able sit­u­a­tion in which the soft­ware use is af­fected in some way but can be cor­rected by a doc­u­mented change or by a fu­ture re­lease.