Addressing updates to Banno User Guides, Banno Docs and Banno Knowledge

Addressing Documentation Requests

Find a gap in our available documentation?

As you are working with customers on using our tooling and reviewing the documentation we have currently available, it may be determined that we need to adjust current documentation, add to what is already available, or write new documentation to better outline a product, feature, or process. In that case, we can engage our documentation teams to help get the information needed written and posted to our Banno User Guides, Banno Knowledge or Banno Docs.

When a need arises, start by conducting some initial research into what information we do have available and where it lives. Be prepared to provide direction for the documentation teams on what you’ve found, what needs to change, what needs to be added, and where it makes sense to add the new/updated information to ensure it’s available to the right people, whether that be for our internal teams or customer-facing.

Our teams can use the following resources to review what information exists today and help plan for the new/updated information to be added.

• Banno Knowledge
• Banno Docs
• Banno Admin
• Banno User Guides

Once you have dug into what information currently exists, check current open issues in both the Documentation Request project in Jira Service Desk as well as the Documentation Team project in Jira. This will give you a full scope of the work currently in the hands of the Banno documentation team for updates/additions to be made to Banno Docs and Banno Knowledge and will allow you to see if any similar requests already exist.

If needed, ask team members within your team’s or the relevant team’s Slack channel, to see if others have input to provide or can help confirm an update to current documentation is needed:

• Banno Apps Support: #team-support, #org-support, @support
• Banno Apps Implementation: #team-implementation, #org-implementation, @implementation
• Banno Apps Operations Team: #team-operations
• Banno Content Support: #team-tech-support, @cwas
• Banno Content Implementation: #team-project-coord, @pcs
• Banno Content Web Team: #team-webteam-talk
• Product Managers: #org-prod-mgmt

If you are not the subject matter expert, be sure to engage those who are in the conversation. Gathering team input helps ensure all team members are engaged in the finding and can provide background information and context to make the most out of the documentation available to our teams and our customers.

When background information has been gathered:

Once background information has been gathered, requests will be handled in a couple different ways, based on the documentation that needs to be adjusted. See below for information on how to request changes to Banno User Guides. The rest of the information outlined in this document relates to submitting documentation change requests to the Banno documentation team for changes to be made to Banno Docs or Banno Knowledge. These requests will all be managed through Jira Service Desk.

Requesting Changes to Banno User Guides

When you have found a gap in or issue with current user guide documentation, loop your Team Lead into a Slack discussion in your team’s channel, providing details on the finding. They will be able to further validate, ask any questions to understand the need, and submit a request to the JHA documentation team through the Documentation Action Request portal.

1. Visit https://documentation.jackhenry.com/.
2. Complete the fields:
   1. Contact Information: Provide your contact information.
   2. Product: List specific product name. Include “Banno”, followed by the product (Banno Support, Banno Content, Banno People, etc.).
   3. Supporting Core: Choose Other, unless for specific core.
   4. Release Level: Enter current year.
   5. Topic Title: Type path/location for the affected topic. Example: Banno Content > Pages > Page management -or- Banno Support > Inbox > Responding to conversations
   6. Description: Describe the needed updates or corrections. Include any of the following details that are applicable to the change request:
      1. Feature name
      2. Deadline for changes or go-live date for feature
      3. Details about the feature or issue, outlining how to review or reproduce
      4. Environment the feature or issue is accessible or reproducible in
      5. Additional information that may not be evident from looking at the feature in the affected environment, client feedback for documentation, specific details that would be helpful to add, and so on.
   7. Attach one or more files: provide screenshots, if relevant or helpful to understand the request
3. A JHA documentation team member will reach out when the request has been received to acknowledge the request and ask any clarifying questions, if needed.
4. When the updates have been made and are ready for review, the JHA documentation team member will reach out via email requesting approval.
5. Once approved, a request will be made for the changes to be pushed out to the live user guide(s). These pushes typically occur at the end of each month. If there is a need to have the updates made on a specific date, be sure this has been requested both in the original submission and with your approval of the completed work.

Once the requested updates are live on the user guide, the team lead will notify the team of the changes through the team’s Slack channel and provide a link to the updated portion(s) of the guide.

Requesting changes to Banno Docs or Banno Knowledge

For changes needing to be made to Banno Docs or Banno Knowledge, we will use Jira Service Desk to create an issue and engage the Banno documentation team.

• New issue will be created on the Documentation Requests board.
• Issue will follow the outline for submitting documentation requests (found below), when created, to provide information for the documentation team to prepare updates to our current documentation.

The original reporter will monitor progress on the original ticket and follow progress of any linked tickets created to manage the request. The original reporter and any other relevant team members will work with the documentation team through the Jira Service Desk ticket to provide more information, as needed, as they begin making updates to our documentation. Discussion about the issue should happen within the Jira Service Desk ticket that has been created. When the updates have been made, the original reporter and/or subject matter expert will review the updates and approve to post. Once posted, the original reporter will verify and resolve the issue.

Further details on this process can be found under Managing documentation requests through Jira Service Desk.

Submitting a documentation request in Jira Service Desk

When it has been determined that an update to the documentation found within Banno Docs or Banno Knowledge is needed and all relevant background information has been gathered, create a Jira Service Desk issue to engage the Banno documentation team. All of our documentation requests being handled internally should be routed through this repository, so we have a single place for Documentation to manage incoming requests.

Banno Knowledge, Banno Docs, and Jira Service Desk should be searched prior to creating a new request, to see if there is information already written, related to the request or a related request in progress with the documentation team. When submitting the request, please provide any relevant resources or links to current documentation to help the documentation team best understand the need and prepare the updates to our documentation. If there is a current task open related to the request and you have additional details to add, additional information can be added to the description and the additional details can be included in a comment on the standing task.

Creating an issue in Jira Service Desk

1. Access the Documentation Requests board.
2. Select Create (+) in left-hand panel. Note: Each issue should cover only one concern.
3. Project: Documentation Requests
4. Type: Documentation Update
5. Summary: title the issue using a succinct but specific description of the documentation being requested. Summary should begin with the product name (ex: ‘Mobile: Documentation being requested’ -or- ‘CMS: Documentation being requested’ -or- ‘Operations-Implementation: Documentation being requested’). Note: A very generic issue title makes managing the requests more difficult. Issues can always be renamed, if needed, as we understand more about the documentation updates being requested.
6. Description: provide a thorough description of the update to current documentation or the new documentation needed. Explain where this should live within Banno Docs or Banno Knowledge, what product/feature the request is related to, how it relates to current product or process documentation. Provide background on the request being made and context around what specifically is needed and why.
7. Attachment: attach any files (screenshots, videos, etc.) related to the request to help the Documentation team better understand the need.
8. Related Resources: provide link(s) to any supplemental resources related to the request - design specs, operations documents, user guide details, and so forth. This ensures the documentation team has as much context and information relevant to the request as possible.
9. Product: indicate the product where the feature is being requested. Note: more than one product can be selected.

• CMS
• Form Builder
• History
• Marketing
• Mobile
• Monitor
• Online
• People
• Reports
• Settings (Users/Groups/Logins)
• Support

10. Feature: indicate the specific feature where the feature is being requested, within the product noted above.

• Bill Pay
• Cards
• Change User Info
• Documents
• Enrollment
• Login
• My Card Rules
• Password Management
• PowerOn
• Remote Deposit
• SSO
• Stop Payments
• Transactions
• Transfers
• Travel Notices
• Zelle

11. Audience: identify the audience the documentation should be prepared for. Will this be internal-only documentation or will this be customer-facing?
12. Approvers: identify other members of the Banno team who are subject matter experts, who may be able to provide more detail around the request and approve the update to documentation.
13. Notification Email: if applicable, select the group email address(es) that should be notified when the documentation request is complete and the new document is live.
14. Priority: indicate priority of the request. By default, the field should be set to Medium. If necessary, adjust the priority to help Documentation prioritize requests.

• High: This should be done as soon as possible, potentially moving in-progress work. This should only be used if the information is vital to our customers or if a customer is blocked or at a very high temp without this document.
• Medium: This document is important, but doesn’t need to be done ASAP. This is the correct priority for a standard request with a due date more than a week out and includes requests such as updates to existing incorrect documentation or a document that must be done to finish a launch.
• Low: Generally, these documents are “nice to have” rather than “must haves.” This includes most internal docs or updates to existing docs that are accurate but could be improved.

15. Linked Issues: select relates to, then search for and select each relevant issue or enter the issue key directly to provide context and background information for the Documentation team, if applicable.
16. Linked Issues | Related FI: if applicable, indicate the institution(s) requesting the documentation. Under Linked Issues, select Related FI, then search for and select each relevant institution found in the Customer FIs project or enter the FI’s issue key directly. If there are multiple requesters, include all institutions who have requested documentation. Note: Institutions are synced regularly from the implementation status sheets and can be searched by institution name or Company ID.

Institution Name: if you are unable to find the appropriate institution from the Customer FIs project, indicate the name of the institution(s) requesting the documentation. If there are multiple requesters, include all institutions who have requested the documentation, separated by comma.

17. Click Create.

This opens the issue in the Documentation Requests project in Jira Service Desk and creates a link that can be used to track progress and as a reference point for discussions with the Documentation team.

Tips on linking issues: when creating an issue, the linked issue field searches only your recent history or allows you to enter the issue key directly. If you are having trouble finding the issue you are wanting to link, skip this step and create the ticket. Once created, you can link issues directly from the open ticket, and this will search all open Jira tickets, rather than only your recent history. Direction for linking issues can be found in the Using Jira Service Desk guide.

Managing documentation requests through Jira Service Desk

Once an issue has been created within Jira Service Desk, the issue will be managed here until there is a resolution. The documentation team will review all issues submitted, communication about the requests will happen within Jira Service Desk on each ticket, we will use workflows to indicate status of the issue as it is being worked on, and issues will eventually be resolved.

Documentation Review Process

The documentation team will use Monday as their triage day to sweep through requests coming through the Documentation Requests board. Once the request has been reviewed, a comment will be made on the ticket, acknowledging that it has been reviewed. The documentation team will also create an issue on their board to manage their workflow and will link the new issue on the original request.

Each new documentation request added through Jira Service Desk will result in a notification in the #org-documentation Slack channel, once created. If you have a high priority request, ping @documentation in this Slack channel, using the :urgent: symbol and referencing the Jira Service Desk ticket.

In Slack, discuss individual topics within a single thread to help keep the channel cleaned up and easy to navigate. The documentation team will filter and manage incoming requests and loop in other team members, when necessary.

Communication on Documentation Requests

Where possible, discussions in regards to Jira Service Desk issues should take place in Jira Service Desk. Operations team members can comment on the ticket, when needed, to engage with Documentation. The documentation team will also comment on the ticket within Jira Service Desk as progress is made, so the operations team knows the current status of each request.

At times, discussions about a request may happen outside of Jira Service Desk (e.g. Slack, email). When this happens, relevant details from the discussion should be captured as a comment on the original issue, so the history is complete and can be easily referenced later. This may include screenshotting, linking to Slack archives, or summarizing a discussion/email thread.

If a member of the operations team wants an update on a request and aren’t getting one through Jira Service Desk, they should put a note in the #org-documentation Slack channel, with a link to the referenced request from Jira Service Desk. Any conversations in the Slack channel should be summarized as comments on the issue itself.

Workflow Status

We will use workflow statuses within Jira Service Desk to keep the documentation and operations teams informed with where we are on each particular request. As progress is made, the status should be updated, as well.

Below is an outline of the various statuses and corresponding descriptions of how and when they should be used.

Closing Tickets

It is the responsibility of the person who creates the issue to verify that the request has been completed and the ticket gets closed, once there is a resolution. Issues should be swept through on a weekly basis by the creator to ensure resolved issues are closed in a timely fashion.

To close a ticket, update the status to Issue is Closed. You will be required to select a Resolution in order to indicate why the ticket is being closed and should always leave an internal comment outlining specific details of the resolution.

Below are the resolution options that should be used for these requests and a description of when to use each.

Note: only one resolution can be selected and the issue will have to be reopened to change a resolution. If you reopen an issue, the Resolution will be cleared.