Define Requirements for Each Service Item
Forms should be defined as much as practical before actually developing the form. Time spent during the definition stage will be saved at least two-fold during the development stage.
To begin this blueprinting process, it is important to start with accurate use cases. From accurate use cases, the rest of the process can flow, including defining the desired user interface and process, reporting, and the all important post implementation step of defining and running test cases.
The next step is to use the use cases to create a process map. The process map is a visual representation of the process as it will be built. While you can begin with a visual representation of the business process, it is important to re-work the process map into a diagram of the process as it will be built. For example, if there are 3 business process steps that are being done by one group and there is only one Incident being created, it only gets one box on the process map. To the process being built, that’s one step (the Incident). As a general rule, if it’s not something you are creating in the system (Service Item, Approval, Work Order, Incident, Notification), it doesn’t get a box on the diagram.
You can capture the business process steps taking place within these process flow steps in a narrative that goes along with the diagram that explains how the users experience interaction with the system. Creating this narrative is part of the process map step.
Once the Process Map is complete, the details of the Service Request can be defined.
- What the service request should look like: What questions should be asked and what are the details of the events/user interface interactions (ex. insert/remove, data validation, page branching)
- Question details can include length (max or required), data validation, help/hover, question name vs visible name (if different), required vs not, read only vs read/write, etc.
- Question details can also include what events changing, populating, blurring, etc that question may cause.
- Keep review request (what might need to be different when a person looks at a request after submission) in mind. Do things need to look/act differently in this case?
- Who can access the service request? What are the entitlements for the request?
- Where/how is the service request seen? What is the categorization for the service request and what languages is it available in?
- Supporting information?
- What data/data sources will be used/needed for this service request?
- What system(s) is this data in?
- How will it be retrieved/used?
- What does the user need to see on the screen other than the questions? Does their need to be other guidance like text or hovers?
- What notifications are needed for this service item? A common example is a reminder when someone saves as draft and hasn’t come back to complete in X number of days.
- Where to Start? Is there a template to start from? And if so, what are any differences needed from that template?
Then the definition of the fulfillment process can begin. During this process, it may be discovered that some modifications are needed to the definition of the Service Request and/or Process Map. Everything is really in flux until it’s all completed.
The first questions to ask around fulfillment are around approval. Does the process require approval? To define an approval you need to determine:
- Who should get the approval. If this is not a single person for all requests then how the approver is derived also needs to be included. Also, if not a single person, does one or some or all need to approve?
- What should the approval email say? This email often has some details of the request, along with a link to approve/deny the request.
- What the approval should look like: Is it a review request of original form with an additional “Approval” section on the bottom? Is it a simple text listing of the answer from the original form?
- What questions do you ask of the approver? This could just be a single question of “Is this request approved” with another “Reason” free text question if denied.
- What to do on a denial? Typically an email is sent to the requester stating the reason for the denial.
Outline what an email should say and how it should look for the emails that get sent out during an approval process. The typical approval emails are:
- Approval Invite: The original email that gets sent to an approver. It includes a link to the form for approval.
- Approval Backup: Do you need to define a process to set up backups for your approvers? This can be for a specific time period or after an approver hasn’t responded for a particular period of time. An email gets sent to the backup when this occurs. Your requirements specify the time period (when the email should be sent).
- Approval Reminder: This is a reminder to the original approver that they have not completed their approver. Often a group will have a Reminder fire after a day or two, and then a day or two later, configure the backup approver to be sent an email.
- Approval Denial: When an approval is denied, an email can be sent out to notify one or more people that the request is denied. In the requirements, indicate who should get the email (Example: requester and approver #1, etc) and what it should say. The comments that the Approver who denied the request are available in these emails.
Once the approvals are complete, the request moves into whatever the next type of fulfillment will be:
- In what system will we be creating the fulfillment? Kinetic can reach out to other systems and may be reaching out to Incident, Change, Work Order, JIRA, etc. It is very important to note that if you are reaching out to a new external system that there may be additional development steps necessary to make the systems communicate effectively.
- If the system completing fulfillment is not Kinetic, things to keep mind: How do the questions asked in a request map to fields on the form you are pushing to? Are there required fields on the destination form? Are there field length limitations on the destination form? Should the next task in line continue after creating a record or wait for something to happen on the destination form (such as closing the ticket)?
- If the system completing fulfillment is Kinetic: What questions should be asked and what are the details of the events/user interface interactions? Is there a template that can be used? If so, what is the necessary variance from the template (if any)?
- Who should get the fulfillment record(s)/assignment?
- What should the fulfillment emails say? This email often has some details of the request, along with a link to the fulfillment request. This is usually sent by the fulfillment system, so is usually only sent by Kinetic if Kinetic is doing the fulfillment.
For all of these fulfillment processes, what is the necessary supporting data? Where is that data stored? What notifications are sent? When?
And finally, once people have begun using this process, what will the reports need to look like? What data will need to be retrieved from the system after the fact? This is important to consider during requirements gathering because it can determine how you build the items, mapping certain fields/storing data in certain locations to make this reporting easier.
The result of this process is a "blueprint" document that captures requirements. You can refer to the form and presentation available here.
Improving Our Service
One objective of undertaking a service request process is improved visibility, timeliness and overall experience of making requests for your customers. Having an avenue for them to report good or bad experiences with the portal and the underlying fulfillment activities is crucial.
- Including the estimated time to fulfill the service somewhere prominent within the form itself
- Include a link to a survey on all of your confirmation pages. This link can pass information to the survey about what form/situation was accessed using Kinetic Survey
- Include the ID of the submission on the confirmation page for easier follow-up