Guide to reporting issues
So you've launched a subscription with one of our products and ran into an issue or have a question that you couldn't find the answer for on this community. Don't fret - we've got you covered! It's our mission to ensure your support experience is seamless and effortless. If you have access to the Case Portal, you might have noticed a lot of fields on the new case submission page. Why is all of this information necessary / required? We understand that not everything you submit to us will merit this information. For example, if you have a simple request or a question, providing steps to replicate or describing the expected and actual behavior may not be relevant. However, the more information you can provide from the start, the faster your experience will be. For all service requests, whether to report a defect or simply a question, there are some fields that will help us solve for your query more effectively. Subject - Just a brief summary, a tweet if you will, about the request Description - Here's where your novel goes, with the entirety of the request Customer Priority - By default, this is "normal" but sometimes there's a High or Low priority request. These should be compared to your others, meaning 90% of your request would typically be "Normal" in priority. Severity - These are contractual levels, but take a look at our Support Page for some definitions. This is a field you can't change once submitted, but our support team can if appropriate. When reporting a defect or issue to Khoros Support, please provide the following information: URL of Khoros Product and/or URL(s) of where the problem occurs Steps to Reproduce Expected Behavior Actual Behavior Browser and OS Username, Roles, or Ranks When asking a question or making a request to Khoros Support, please provide the following information: Subject Description / Request / Question URL of Khoros Product Providing the above will eliminate the chance for any confusion or unnecessary back-and-forth that may lengthen the time your case stays open. On a final note, a picture is worth a thousand words - if you're able to attach screenshots to your case submission, it will be extremely helpful to the team in getting your case moved along even faster. And if a picture is worth a thousand words... a video is worth a million! If the issue you're experiencing is intermittent or rather involved, capture it on a quick video. There are several applications out there that offer video capturing of your screen - Jing is a great free tool to try and works on both PC and Mac.12KViewsSign in to react to this post0Comments
Understanding common industry terminology
API: Application Programing Interface: A source code interface that a computer system or program library provides in order to support requests for services to be made of it by a computer program. More Breadcrumb: A set of links at a the top of the page that (1) show users where they are and (2) allow uses to retrace their steps up a hierarchy. More CGI Script: Common Gateway Interface script: A standard protocol for interfacing external application software with an information server, commonly a web server. More CNAME: A CNAME record or canonical name record is an alias of one name to another. The address record that the alias is pointing to can be either local or remote - on a foreign name server. This is useful when running multiple services (like an FTP and a web server) from a single IP address. Each service can then have its own entry in DNS (like ftp.example.com and www.example.com.) CSS: Cascading Style Sheets: A stylesheet language used to describe the presentation of a document written in a markup language, the most common application of which is to style web pages written in HTML and XHTML. More DNS: Domain Name Service: DNS stores and associates many types of information with domain names; most importantly, it translates domain names (computer hostnames) to IP addresses. More htaccess: The .htaccess file is a configuration file for web server directory configuration and control. At Khoros, this file is most often used in the context of granting or restricting access to a web site via an IP address range. HTML: HyperText Markup Language: The predominant markup language for the creation of web pages. More IE: Internet Explorer: Microsoft's web browser MX Record: An MX record or mail exchange record maps a domain name to a list of mail exchange servers for that domain. Query String: The part of a URL that contains data to be passed to CGI programs. More Query String Parameters: Data to be passed to CGI Programs in a Query String. REST Representational State Transfer: a style of software architecture for distributed hypermedia systems such as the World Wide Web. The term is also often used in a loose sense to describe any simple interface that transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies. More RFP: Request For Proposal: A formal request submitted to a vendor for a product or service. Typically meant to form the basis of any subsequent SOW. More RSS: Really Simple Syndication (et al): Family of web feed formats used to publish frequently updated digital content, such as blogs, news feeds or podcasts. More SEO: Search Engine Optimization: The process of improving the volume or quality of traffic to a web site from search engines. More SOW: Statement Of Work: A formal document describing in detail the work about to be undertaken for the customer, the responsibilities of each party and the acceptance protocol. SSL: Secure Sockets Layer: cryptographic protocol which provides secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. More SSO: Single Sign On: A specialized form of software authentication that enables a user to authenticate once and gain access to the resources of multiple software systems. More XHTML: eXtensible HyperText Markup Language: A markup language successor to HTML designed to allow for automated processing to be performed using a standard XML library. MoreViewsSign in to react to this postCommentWorking with Khoros during Major Events
We know that there are events that specific communities consider "major" for their business -- whether this is the Superbowl , Black Friday/Cyber Monday, a live event, a new product launch, a relaunch of your design, a demo for executives, or any one of a dozen other scenarios, it is our goal to work with you to ensure that events are as seamless as possible. Outages Khoros is committed to ensuring that you are supported 24/7/365 on any outages. We have a comprehensive guide to outages and information about our general status page available for you to take a look at, but the summary of this is that if you or your customer's are down or unable to work, let us know and we'll quickly take a look to see what's going on! You can always keep up to date on our status page where we do our best to provide insight to outages impacting multiple customers. Being Proactive Assuming you know ahead of time that you have a major event coming up, please let us know as early as possible - at least a week - if not more - is ideal! Although we have monitoring in place to help mitigate issues as best as possible, the best situation is where we can proactively review allocated resources, your server side setup, and make sure that there simply aren't any issues! Reaching Out If you have a Technical Account Manager or CSM, please make sure that they and Support are aware of your impending event so that they can pay attention to it. If you don't, don't despair! Open a support case letting our team know that you have an event coming, what the date and time of it is and that you'd like us to take a look to see if there's anything that needs to be done to help prevent an impact on you or your customers. If you can add Proactive to the case subject, it'll help us organize the solution as well. Depending on need and contracted level of support, this may require some additional conversations to figure out what is necessary to help you be successful. The above applies to whether you're a Care, Communities, Marketing, or JX customer!ViewsSign in to react to this postCommentsKhoros Care Downtime & Impacts to Bot Customers
At times, Khoros will perform scheduled maintenance on your Khoros Care instance. You will receive an email notification for the maintenance approximately 3 days beforehand. This email will contain the date, time, and length of the maintenance. Note your specific date and time from the email Khoros maintenance windows are designed so that any downtime maintenance we perform is done during times that are least impactful to your Khoros Care teams and your customers. You should plan for up to an hour of downtime where agents won't be able to sign in to your Khoros Care instance. Review the maintenance windows. For most of our customers, this impact is minimal and potentially completely invisible to your customers. For a very small group of our bot customers, the downtime could translate to an impact to bot interactions if your bot is connected to the Care API to retrieve messages vs. network APIs directly. The former may mean that your customers won't receive messages from your bot during the downtime and won't receive messages afterward unless they re-engage again subsequently. This can also have an impact on the continuation of bot flows that started before the downtime that got interrupted. Those customers may experience a restart of their conversation journey with the bot, such as a bot response that ignores the context the customer already provided. To minimize the disruption now, consider one of these options: Welcome Response message Bot Holding Work Queue Welcome Response message Set a Welcome Response message in Care for the affected bot channels 1 hour before the downtime, informing customers they might experience a disrupted bot journey. This will trigger a Welcome Response as well as starting the bot journey. Don’t forget to disable this new Welcome Response after the downtime. Alternatively, you could update the welcome bot flow directly within Flow, and then remove it after the downtime. Here’s a sample message: "As we make security improvements to our servers, the bot may be impacted over the next couple of hours. If the bot fails to respond to you, please simply re-engage with us after 1 hour to continue the conversation. We apologize for the impact this may have." Bot Holding Work Queue If customers don't re-engage the bot after the downtime, you might have to take conversations out of your bot holding queue and deliver them to agents without waiting for automatic agent handoff by the bot. Follow this guide to achieve this. Note: If you use bots other than Khoros Flow, confirm with your bot provider how a downtime of Khoros Care might affect you. The steps above should also be of value to you. If you have any concerns or questions regarding this, raise them with your Account team. If you don't know who they are, simply ask Maia, our chatbot, on Atlas 'CSM' and they will let you know who you can speak to. Also, don't forget that our Support Team works 24/7/365 in urgent cases.ViewsSign in to react to this postCommentsHow We Built the KB Audit Flow Pt. 1
Trust in the accuracy of your Knowledge Base articles is essential to building trust and confidence between your visitors and the content they're interacting with within your knowledge base. One way of ensuring that each KB article is current and accurate is frequent and routine audits on that content. The audit process should be straightforward for your authors, administrators, and moderators, and transparent for your readers. To make this process as seamless and easy as possible on Khoros Atlas, we created an auditing solution that enables members with the appropriate permissions to set the article as "audited" and to display the date and time of the last audit to visitors. In this three-part series, we're going to take a detailed look at how we built out this auditing solution in Khoros Atlas. We highly recommend reading the next two posts in this series to get a better understanding of the other components and prerequisites required for this component to function properly. How We Built the KB Audit Flow Pt. 2: Audit Checkbox How We Built the KB Audit Flow Pt. 3: Review Date Display Concept Our 'Last Reviewed' component enables members with the appropriate roles (defined in the 'Last Reviewed' component we will create in this guide series) to see a checkbox in the sidebar of each KB article enabling them to indicate that the article has been audited. This "Audited" checkbox. When the box is checked, the time and date are saved as part of the audit trail. Note: The role(s) required to see the Audited checkbox are set within the "Last Reviewed" information component we will create in the second part of this blog series. Once that data has been saved, it is then displayed in the sidebar. This enables visitors to see when the article was last reviewed. This enables them to gauge how up-to-date the information in the KB article is. Member Flow For permissioned members, auditing an article is as simple as reviewing it on the front end and selecting the Audited checkbox. Once done, a confirmation message appears enabling the member to confirm the audited state by selecting Yes, or cancel it by selecting No. Once confirmed, the date and time data is saved and that date and time become the new "Last Reviewed" date displayed to all visitors in the sidebar. Prerequisites Before this functionality can be added to the Khoros Communities instance, we need to make a few changes on the back end to create a space where metadata containing the audit timestamps and status for each message will exist. This requires a few steps that Support can assist you with. To get your instance ready to work with the Audit Flow, simply submit a support request using the Case Portal and request that your Communities instance be configured to support Audit Flow. Case Study: Khoros Information Experience Team Our Product Content Experience Team is responsible for writing and maintaining the knowledge base (KB) articles for Care, Community, Marketing, CX Insights, and Khoros Flow. This includes a library of hundreds of articles, each focused on information that evolves alongside the products. The Challenge As you could imagine, keeping all of this content updated is a huge responsibility. Outdated information in our knowledge base leads to confusion and wasted time. We needed a solution that accomplished the following: Instill confidence in visitors that the article they're reading is updated and accurate Enable team members to record their audit of existing KB articles from the front end Provide a visible label on each audited article with the time and date of last review Create a process for determining which articles should be prioritized for audit Execute audits in coordination with internal engineering and product teams The Technical Project To reach these goals, we partnered with the Atlas team, as well as our internal engineering and product partners, to create both a technical solution and team workflow. The technical side of the project required some development work on Atlas. This included: A new table in the database to store the "last reviewed" information Metadata fields to represent the information in each article A component that enables the frontend audit checkbox for users with specific roles A component that displayed the "last reviewed date" of each article to all visitors With these additions in place, our team members with the Administrator or Documentation role can mark a KB article as audited from the front end, and have the date and time of that review displayed to all visitors, regardless of their assigned role(s). This accomplished the feat of both simplifying the review process and making a functional improvement that our visitors can benefit from. Tackling the Audit Process The next thing we needed to achieve was the active auditing of over 1,000 TKB articles currently in Khoros' knowledge base. Many of these articles were written years ago, and our team (at the time) was very small. We partnered with various teams across Khoros to assign articles to subject matter experts, so it wasn't just our content team that was reviewing content. If the content was 100% accurate, it would be marked as audited. If not, we created a ticket in Jira and assigned a content team member to update it. This cross-functional auditing pass enabled us to audit ⅓ of the KB articles in our library in six months. This approach brought with it a number of challenges. It was a logistical feat to coordinate with all of the teams and ensure deadlines were met. Additionally, we weren't entirely sure that every article receiving the bulk of our focus was actually being used by our customers. So, we adjusted our approach for the second phase of our audit. Instead of tackling the entire library of articles at once, we instead focused on the following articles: Articles with the highest average views per day Articles with an average of at least one view per day since it was published This was accomplished by examining the publishing date of each article, as well as its total views. With this information, we could determine the average number of views for each day since the article was published. Articles with the most average views per day received the highest priority. The rest of the articles with at least one visit per day would receive an audit once the first batch of articles is complete. Now that our team has grown, we are able to set achievable goals and divide the work amongst our writing staff so that our efforts are targeted so each audit has the maximum possible impact on our overall customer experience.ViewsSign in to react to this postCommentHow We Built the KB Audit Flow Part 2: Audit Checkbox (Updated)
The KB Audit Flow requires two components to work. The first is an audit checkbox that enables members with specific roles to mark a KB article as "audited" from the front end. This checkbox includes the initial check and confirmation. The second component is the 'Last Reviewed' Information component which displays the date and time of the last audit of the KB article. That component is displayed for all visitors, regardless of their role(s). It does, however, check the member's roles to determine whether or not to additionally display the audit checkbox featured in this post. In this post, we will create a new audit checkbox component. Note: These instructions cover the method for creating the component using the Community Plugin SDK. For an easier UI-based approach, we recommend using Studio to create the component. The content of the file below remains the same. We highly recommend reading the other two posts in this series to get a better understanding of the other components and prerequisites required for this component to function properly. How We Built the KB Audit Flow Pt. 1 How We Built the KB Audit Flow Pt. 3: Review Date Display Create a Custom Endpoint A custom endpoint enables the audit checkbox component to send the "last reviewed" timestamp to Khoros, updating the date and time the article was last audited. To create this custom endpoint: Navigate to Studio > Endpoints Select the New Endpoint button Enter last-reviewed-date in the title field Select Save Enter the following in the View Content field: <#assign msg_id = http.request.parameters.name.get("msg_id", "")?string /> <#assign date_time = http.request.parameters.name.get("date_time", "")?string /> <#if msg_id != ""> <#assign lastReviewedDateResponse = restadmin("/messages/id/${msg_id}/metadata/key/custom.message_last_reviewed_date/set?value=${date_time}") /> </#if> Select Save This creates a new custom endpoint which passes the message identifier and datetime to Khoros. It is utilized by the Audit checkbox component we are creating next. Create LastReviewed-Audited-checkbox.ftl file The process for creating the checkbox component is pretty straightforward. To start, create the LastReviewed-Audited-checkbox.ftl file as a component. For example: /res/components/LastReviewed-Audited-checkbox.ftl. Here are the contents of that file: <style> .audited-component-checkbox{ margin-top: -20px; margin-bottom: 35px; } label.lia-form-label.audited-label-set { padding-top: 4px; font-weight: bold !important; float:left; } .litho-audited-checkbox-style{ float: left; } .lia-form-label-wrapper.audited-label-float{ float: left; } .lia-inline-confirm.confirm-label-float{ float: right; margin-top: 4px; margin-left: 12px; } a.litho-tkb-audited-deny { cursor: pointer; } a.litho-tkb-audited-approve { cursor: pointer; } .hide-article-component-here{ display:none; } </style> <#-- <#import "article" as com> --> <div class="hide-article-component-here"> <@component id="article"/> </div> <#assign message_uniqueId = -1 /> <#if env.context.message??> <#assign message_uniqueId = env.context.message.uniqueId /> <#assign lengthOfDomain = env.context.message.webUi.url?index_of("/t5") /> <#assign communityDomain = env.context.message.webUi.url?substring(0,lengthOfDomain) /> </#if> <#assign communityId = community.id /> <#-- REST call to get the user's roles --> <#list restadmin("/users/id/${user.id?c}/roles").roles.role as role> <#-- Look for the role name you want to display content for --> <#if role.name?? && ( (role.name == "Administrator") || (role.name == "Documentation") )> <div class="audited-component-checkbox"> <div class="lia-quilt-row lia-quilt-row-standard lia-quilt-row-first lia-quilt-row-last"> <div class="lia-quilt-column lia-quilt-column-24 lia-quilt-column-single lia-input-edit-form-column"> <div class="lia-quilt-column-alley lia-quilt-column-alley-single"> <div class="lia-form-row lia-form-auto-subscribe-to-thread-entry lia-form-row-reverse-label-input lia-form-row-checkbox litho-audited-checkbox-content"> <div class="lia-quilt-row lia-quilt-row-standard litho-audited-checkbox-style"> <div class="lia-quilt-column lia-quilt-column-24 lia-quilt-column-single"> <div class="lia-quilt-column-alley lia-quilt-column-alley-single"> <div class="lia-form-label-wrapper"> <input class="lia-form-auto-subscribe-to-thread-input audited-checkbox" id="LastReviewAudited" name="auditedCheckbox" type="checkbox"> </input> </div> </div> </div> </div> <div class="lia-form-label-wrapper audited-label-float"> <label for="LastReviewAudited" class="lia-form-label audited-label-set"> Audited </label> </div> <div class="lia-inline-confirm confirm-label-float confirm-label" style="display:none;"> Confirm? <a type="submit" class="litho-tkb-audited-approve"> Yes </a> / <a type="submit" class="litho-tkb-audited-deny"> No </a> </div> </div> </div> </div> </div> </div> <#break> </#if> </#list> <@liaAddScript> ;(function($){ $(".audited-checkbox").click(function(){ $('.confirm-label').toggle(); }); $(".litho-tkb-audited-approve").click(function(){ $(".audited-checkbox").attr("disabled", true); <#if message_uniqueId != -1 > <#assign aDateTime = .now?iso_utc> $.ajax({ type:"POST", url:'${communityDomain}/plugins/custom/lithium/${communityId}/last-reviewed-date?date_time=${aDateTime}&msg_id=${message_uniqueId}', contentType: 'application/json', success: function(res) { console.log(res); console.log("Added"); location.reload(true); }.bind(this), error: function(xhr, status, err) { console.error(xhr, status, err.toString()); console.log("unable to add last_reviewed_date field into DB"); }.bind(this) }); </#if> $(".audited-checkbox").prop("checked", false); $('.confirm-label').hide(); }); $(".litho-tkb-audited-deny").click(function(){ $(".audited-checkbox").prop("checked", false); $('.confirm-label').hide(); }); })(LITHIUM.jQuery); </@liaAddScript> Code Breakdown In this section, we will examine some of the parts of the component's code to better understand how the component works. <style> ... </style> This section of the file sets the CSS styling for elements within the component. <div class="hide-article-component-here"> <@component id="article"/> </div> This section loads the current article in this component to get the message information, including the message's unique identifier. <#assign message_uniqueId = -1 /> <#if env.context.message??> <#assign message_uniqueId = env.context.message.uniqueId /> <#assign lengthOfDomain = env.context.message.webUi.url?index_of("/t5") /> <#assign communityDomain = env.context.message.webUi.url?substring(0,lengthOfDomain) /> </#if> <#assign communityId = community.id /> This section extracts the message's uniqueId, enabling the component to fetch information for the specific article. It also references the community ID, which we use later in a POST call to update the last reviewed timestamp. <#list restadmin("/users/id/${user.id?c}/roles").roles.role as role> This section initiates a REST API call to retrieve the member's role. <#if role.name?? && ( (role.name == "Administrator") || (role.name == "Documentation") )> This section compares the retrieved role name to pre-defined names of roles that we want to enable access to the Audit checkbox. <input class="lia-form-auto-subscribe-to-thread-input audited-checkbox" id="LastReviewAudited" name="auditedCheckbox" type="checkbox"> ... </input> Here we create the checkbox with the audited-checkbox class which is referenced in the liaaddscript Freemarker section at the bottom of the file. <#if message_uniqueId != -1 > <#assign aDateTime = .now?iso_utc> $.ajax({ type:"POST", url:'${communityDomain}/plugins/custom/lithium/${communityId}/last-reviewed-date?date_time=${aDateTime}&msg_id=${message_uniqueId}', contentType: 'application/json', success: function(res) { console.log(res); console.log("Added"); location.reload(true); }.bind(this), error: function(xhr, status, err) { console.error(xhr, status, err.toString()); console.log("unable to add last_reviewed_date field into DB"); }.bind(this) }); </#if> Here, we are creating a variable containing the ISO UTC date and time and applying it to an endpoint dedicated to updating the last reviewed date through a POST request to a custom endpoint we configured in Studio. Note: This post's script examples and descriptions have been updated to the latest method used by our Atlas team. The new method uses a custom endpoint to handle the data transfer.ViewsSign in to react to this postCommentsCan Technical Writers Exist in an Agile Dev Team?
Technical writers are an important part of any software development team working on projects or products with customer-facing components. Whether you're creating a simple UI-based tool for customers without any technical experience or an API with complex parameters that pose a challenge to even the most experienced developers, a technical writer bridges the information gap between your development team and the end-user. So, how do you integrate a technical writer into your agile development environment? What role(s) does a technical writer perform within your organization's development team? In this post, we will cover some tips for doing just that! Scrum and Planning Meetings Technical writers are often considered outsiders within an engineering environment. They are typically outnumbered by engineers and frequently work with multiple engineering groups at the same time. This makes it easy to see them as an outside entity rather than a member of the scrum team. However, this perception doesn't take into account the many hats a technical writer wears. A technical writer is like an embedded reporter, writing stories about the projects the scrum team(s) are working on. Those stories benefit from having detailed knowledge of not only what the project is about, but what decisions went into its creation. Knowing why it made more sense to create a feature with one set of parameters over another helps the writer to explain the benefits (and potential snags) to the audience. Consider including technical writers in scrum meetings, as well as in planning sessions where new projects are conceptualized. This will not only provide much-needed context to the writer but save your team time explaining these details later on. Location One common mistake organizations make in their office layouts is to group technical writers in with marketing, design, etc., and sit them with those teams, away from the engineering department. In an in-person working environment, you should consider sitting your technical writers with the engineers. Separating them physically prevents the writers from hearing and absorbing the day-to-day discussions that happen, often resulting in missed opportunities for documenting changes as they occur. Development Environments It's important for technical writers to have access to the same level of development/testing environment as the engineering teams. Even if it's a local deployment of a nightly build, being able to explore and see the code in advance of the documentation being required gives writers a head start on their work. The amount of time the writer has to use and document the upcoming release, the better the documentation. This also allows technical writers to fill another important role that they often do: testing. In order to document a new feature, writers test their documented steps. This enables them to not only discover bugs in their documentation but often to uncover bugs in the code and/or product ahead of release. Time The most valuable commodity of any professional's day is time. Putting aside time for the technical writer to interview members of the team is essential to good documentation. Not only does it allow the writer to ask questions to gain a better understanding of the product, but it also gives your team the opportunity to discover and correct any inaccuracies in the documentation prior to its publication. Product managers, project managers, engineers, and architects should set aside a block of time to work with technical writers on any new significant release. This time may be used doing technical checks of documentation drafts or simply syncing up with the writer to go over any upcoming changes they need to be aware of. Forums and Chat Channels Especially in larger organizations, engineering scrum teams often have private channels where they can share information with one another outside of in-person meetings. This may be internal boards within your Khoros Communities site, team chat channels, issue tracking platforms, collaborative software, etc. Inviting the technical writer into this space is a great way to ensure they stay informed about what the team is working on, and whether or not changes are in the works that may require additional documentation. It also gives them the ability to ask questions outside of scheduled meetings and emails that can be quickly answered without the need to set aside a set time. Summary Technical writers are a unique part of any organization. They are not themselves engineers, but they typically work best in an environment where they are amongst them. In an Agile environment, technical writers don't just provide documentation. They perform multiple roles that touch on engineering, quality assurance, product management, and of course documentation. Do you have technical writers on your team? What are some of your tips, tricks, and best practices? Share them in the comments section below!ViewsSign in to react to this postComments
12KViews
0Comments
You’ve seen all recent content