问题反馈信息处理方法及装置与流程

本申请涉及通信技术领域，特别是涉及提供一种问题反馈信息处理方法及装置。

背景技术：

随着电子商务交易平台的不断完善，以及传统通信、移动通信等技术的快速发展，越来越多的人们通过网上购物的方式来获取日常生活中所需要的方方面面的商品。电子商务交易平台在运行的过程中，可能会遇到某些技术问题、业务问题等，尤其在某些商业促销期间(比如，每年11月11日的“双十一”期间等)，由于业务量的大幅度增加，遇到技术问题、业务问题的几率也大大增加。

一些电子商务交易平台会将相关的工作人员(比如包括客服人员、技术支持人员等)集合在一个即时通讯应用的群组中，其中，客服人员可将卖家或买家反馈的需要解决的问题(比如，某订单出现异常、某促销价格未生效、某商品不能购买等问题)、或者运营过程中发现的问题等以消息的形式输入到该群组中，技术支持人员则需要及时查看群组中的消息，并在确认某条消息中涉及的问题属于自己分管时去解决相应的问题。但是，一方面，技术支持人员往往会因为正在解决某些问题而无法做到实时关注该群组中的消息，因此可能会漏掉某些反馈的问题，使得某些反馈的问题不能得到及时解决；另一方面，从客服人员反馈问题到技术支持人员解决问题的路径比较长，也会影响解决问题的及时性，解决问题的效率较低。

总之，如何提高电子商务交易平台运行中出现问题时的解决效率，成为需要本领域技术人员解决的技术问题。

技术实现要素：

本申请提供了一种问题反馈信息处理方法及装置，可提高电子商务交易平 台运行中出现问题时的问题收集效率，进而提高问题的解决效率。

本申请提供了如下方案：

一种问题反馈信息处理方法，包括：

获得即时通信应用预置群组中产生的用户消息；

对接收到的用户消息进行解析，判断所述用户消息中是否包含问题反馈信息；

如果所述用户消息中包含问题反馈信息，则从所述用户消息中提取所述问题反馈信息；

将所述问题反馈信息添加到预置的列表中，以便通过所述列表将通过所述即时通信应用群组提交的问题反馈信息进行汇总展示。

一种问题反馈信息处理装置，包括：

用户消息获得单元，用于获得即时通信应用预置群组中产生的用户消息；

解析单元，用于对接收到的用户消息进行解析，判断所述用户消息中是否包含问题反馈信息；

提取单元，用于在所述用户消息中包含问题反馈信息时，从所述用户消息中提取所述问题反馈信息；

添加展示单元，用于将所述问题反馈信息添加到预置的列表中，以便通过所述列表将通过所述即时通信应用群组提交的问题反馈信息进行汇总展示。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

本申请实施例中，可通过对即时通信应用进行监控以获得即时通信应用的预置群组中的用户信息，通过对用户消息进行解析并确定用户消息中包含问题反馈信息后，可将问题反馈信息添加到预置的列表中以进行汇总展示，以此，可通过自动化的方式对通过预置群组提交的问题反馈信息进行收集，可避免通 过人工收集时发生遗漏的情况，提高问题的收集效率，从而可缩短从反馈问题到解决问题的路径，提升问题的解决效率。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统框图；

图2是本申请实施例提供的方法的流程图；

图3是本申请实施例提供的方法的界面示意图；

图4是本申请实施例提供的方法的界面示意图；

图5是本申请实施例提供的装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

为了提高问题收集效率，参看图1所示，本申请实施例提供了一个问题反馈信息处理系统10，该系统主要面向的用户可以需要解决具体问题的技术支持人员等，也即，技术支持人员可以通过登录该系统，查看具体的问题汇总结果，而不需要从即时通信系统中的消息群组中自行发现待解决的问题。具体实现时，该问题反馈信息处理系统10可以与即时通信应用20对接，以对即时通信应用20进行监控，通过对获取到的即时通信应用预置群组中产生的用户消息进行解析，并确定用户消息中包含问题反馈信息后，将问题反馈信息添加到 预置的列表中并可进行汇总展示，以此，可通过自动化的方式对通过预置群组提交的问题反馈信息进行收集，可避免通过人工收集时发生遗漏的情况，提高问题的收集效率，从而可缩短从反馈问题到解决问题的路径，提升问题的解决效率。为了进一步提高问题的解决效率，还可通过对用户消息进行解析以确定出问题反馈信息对应的解决人信息并添加到列表中，以更便于通知解决人去解决问题或解决人通过查看列表以及时了解到需要自己解决的问题。此外，还可在确定解决人信息后进一步确定问题反馈信息对应的状态信息并添加到列表中，可根据所述状态信息对问题反馈信息进行区分管理，在解决人完成对问题反馈信息的处理后，还可修改对应的状态信息并通过系统向预置群组中发送通知消息，以实现一个闭环的问题反馈信息处理系统。

下面对具体的实现方式进行详细介绍。

参见图2，该实施例提供了一种问题反馈信息处理方法，包括如下步骤：

s101，获得即时通信应用预置群组中产生的用户消息。

其中，预置群组中可包括电子商务交易平台的相关工作人员，以即时通信应用为阿里旺旺为例，预置群组可为群号为“123456”、群名为“问题反馈群”的阿里旺旺群，该群中可包括淘宝的客服人员、技术支持人员等。例如，一种典型的场景可以为：客服人员通过与交易平台中的第一用户(买家用户、消费者用户)或者第二用户(卖家用户、商家等)进行沟通，接收第一用户或者第二用户提交的反馈的问题，并在该群组中发送群消息。当然，也可以是技术人员自行发现的系统运行中存在的各类问题，并通过发送群消息通知给其他技术人员，等等。

在本申请实施例中，问题反馈信息处理系统可通过访问阿里旺旺服务器的预置接口，对特定群消息向阿里旺旺服务器进行轮询请求,并获得“问题反馈群”中产生的用户消息，然后可将获得的用户消息加入到预置队列中等待进一步处理。

在具体实现时，获得用户消息的方式，比如可通过轮询方式来读取“问题反馈群”中的用户消息，即每隔第一预置时间读取一次“问题反馈群”中产生 的用户消息，第一预置时间可根据实际需求进行设定，在本实施例中，可将第一预置时间设置为5秒。

再比如，也可以通过接收由即时通信应用(即阿里旺旺服务器)每隔第二预置时间发送来的“问题反馈群”中的用户消息，第二预置时间可根据实际需求进行设定，在本实施例中，可将第二预置时间设置为8秒。

s102，对接收到的用户消息进行解析，判断所述用户消息中是否包含问题反馈信息。

在本实施例中，可通过多种方式判断用户消息中是否包含问题反馈信息。

例如，其中一种方式是，判断所述用户消息中是否存在预置的第一格式字段信息，如果存在，则可判定所述用户消息中包含问题反馈信息。

具体实现时，可以预先对第一格式进行定义，并提供给群组成员，这样，群组成员在发送群消息时，如果其中包含有问题反馈信息，则可以按照该第一格式对待发送的用户消息进行编辑，并发送到群组中，这样，系统在接收到这样的用户消息后，就可以通过对第一格式的判断，确定其中是否存在问题反馈信息。具体的，所述预置的第一格式字段信息可以有多种具体的形式，例如，其中一种方式下可设定为，以“#”开头，并以“#”结束的内容，等等。这样，群组成员在编辑用户消息时，如果该条用户消息是用于表达某问题反馈信息，则可以先输入“#”，然后输入具体的问题描述文本，之后，再以“#”结束，这样，系统就可以将其中两个“#”之间的内容可确定为与问题反馈信息相关的内容。

比如，用户消息中包括“#酒店无线分会场的问题，举例idxxxxxx、xxx83791703，是否平台标签“狂欢价”没生效#”，则可表示用户消息中包括预置的第一格式字段信息，以此，可判定出该用户消息中包含问题反馈信息。

另一种判断用户消息中是否包含问题反馈信息的方式可以是，通过对所述用户消息进行语义分析，判断所述用户消息中是否包含问题反馈信息。

具体实现时，可通过现有的语义分析方法对用户消息进行语义分析，比如可通过对用户消息进行分词、给各分词配重、提取分词中的关键词等步骤进行 语义分析，从中判断出用户消息中是否包含问题反馈信息。由于语义分析的实现方式，属于现有技术且并不属于本申请实施例的发明重点，因此，在此不做详述。

在实际应用中，可直接通过此种方式来判断所述用户消息中是否包含问题反馈信息，也可在所述用户消息中是不存在预置的第一格式字段信息的情况下，再通过此种方式来判断所述用户消息中是否包含问题反馈信息。

s103，如果所述用户消息中包含问题反馈信息，则从所述用户消息中提取所述问题反馈信息。

在通过格式判断或者语义分析等方式确定出用户消息中包含问题反馈信息后，可以直接从该用户消息中提取出问题反馈消息。比如，用户消息为“#酒店无线分会场的问题，举例idxxxxxx、xxx83791703，是否平台标签“狂欢价”没生效#”，以此，可从该用户消息中提取出问题反馈信息，即“酒店无线分会场的问题，举例idxxxxxx、xxx83791703，平台标签‘狂欢价’没生效”。

s104，将所述问题反馈信息添加到预置的列表中，以便通过所述列表将通过所述即时通信应用群组提交的问题反馈信息进行汇总展示。

在将问题反馈信息添加到预置的列表后，可将列表中包括的各条问题反馈信息进行汇总展示，以便后台管理人员可随时统计、管理问题反馈信息，根据问题反馈信息的处理情况进行后续操作，也可便于问题解决人员等可及时查看到列表中的问题反馈信息。

在实际应用中，可通过多种方式对问题反馈信息进行汇总展示。

例如，其中一种实现方式可以是，提供用于查看所述列表的第一操作选项，通过所述第一操作选项接收到查看所述列表的请求时，展示所述列表中包括的各条问题反馈信息。

参看图3所示，可在系统中与所述列表相关的界面31中提供第一操作选项，比如，可为“查询”按钮32，同时可提供用于选择“业务线”的操作选项(比如可为下拉菜单形式)33、用于选择“状态”的操作选项(比如可为下拉菜单形式)34，当用户点击“查询”按钮32，即为接收到查看列表的请求，则可展示所述列表中包括的问题反馈信息。当然，可根据对“业务线”、“状态” 的选择不同而呈现出不同的展示结果，可设定默认选择“全部业务线”、“所有状态”，即对应展示出所述列表中包括的所有问题反馈信息。

或者，为了方便技术人员通过多种途径查看问题列表，还可以提供其他的展示问题列表的方式。具体的，可以提供用于通过所述即时通信应用的用户消息发起查看所述列表请求的格式信息，本申请实施例中的问题反馈信息处理系统在监控用户消息的过程中，如果监控到一条用户消息符合该格式，则可以展示出问题列表中包括的各条问题反馈信息。

例如，查看所述列表请求的用户消息格式信息，可以可设定为“@机器人”。这样，当技术人员想要查看问题列表，但是并没有登录到问题反馈信息处理系统，而是恰好已经登录即时通信系统，则可以通过在即时通信的该群组中发送内容为“@机器人”的用户消息。问题反馈信息处理系统在检测用户消息的过程中，就可以检测到该消息，之后就可以向群组中发送一条消息，该消息的内容就是当前的问题汇总列表。这样，技术人员不需要登录到问题反馈信息处理系统，也可以进行问题汇总列表的查看。在这种方式下，相当于是将问题反馈信息处理系统看作是即时通信应用的用户，用户名为“机器人”，该“机器人”也可以在群组中发消息。

本实施例提供的问题反馈信息处理方法，可通过对即时通信应用进行监控以获得即时通信应用的预置群组中的用户信息，通过对用户消息进行解析并确定用户消息中包含问题反馈信息后，可将问题反馈信息添加到预置的列表中以进行汇总展示，以此，可通过自动化的方式对通过预置群组提交的问题反馈信息进行收集，可避免通过人工收集时发生遗漏的情况，提高问题的收集效率，从而可缩短从反馈问题到解决问题的路径，提升问题的解决效率。

此外，为了进一步提高问题反馈信息处理系统的智能性，还可在对用户消息进行解析的过程中进一步确定出问题反馈信息对应的解决人信息并添加到列表中，以更便于通知解决人去解决问题或解决人通过查看列表以及时了解到需要自己解决的问题。

在具体实现时，可根据所述用户消息确定所述问题反馈信息对应的解决人 信息；在将所述问题反馈信息添加到所述预置的列表中时，还将对应的解决人信息添加到所述列表中。

其中，具体在根据所述用户消息确定所述问题反馈信息对应的解决人信息时，也可以有多种具体的实现方式，例如，在其中一种实现方式下，可包括如下步骤：判断所述用户消息中是否存在预置的解决人信息提示符，如果存在，则将根据所述提示符，从所述用户消息中提取所述解决人信息。

所述解决人信息提示符，比如可设定为在“@解决人姓名”，也就是说，“问题反馈群”中的用户在编辑与问题反馈相关的信息之后，如果知道该问题对应的解决人，则可以在问题信息的结尾加上@解决人姓名。在这种情况下，可判断用户消息中是否存在“@解决人姓名”，如果存在，则可根据“@解决人姓名”提取出解决人信息。

或者，如果用户消息中不存在解决人信息提示符，则也可以通过其他方式来确定解决人信息。具体的，由于问题反馈信息通常可以被划分为不同的问题类别，系统内部通常也会对哪些技术人员解决哪类问题具有预先的责任划分，因此，可以预先保存问题类别与解决人之间的对应关系，这样，在用户消息中没有明确指明解决人的情况下，可以首先确定所述问题反馈信息所属的问题类别，然后再根据预先建立的问题类别与解决人之间的对应关系，确定所述问题反馈信息对应的解决人信息。

其中，关于确定所述问题反馈信息所属的问题类别的方式，也可以有多种。例如，其中一种方式下，可先判断所述用户消息中是否存在预置的第二格式字段信息；如果存在，则根据所述第二格式字段信息，确定所属的问题类别。

比如，可设定用户消息中的“【业务线】”为第二格式字段信息，如果用户消息中存在第二格式字段信息，即用户消息中包括“【业务线】”的内容，则可根据“【业务线】”的内容确定问题反馈信息所述的问题类别。

比如，用户消息中包括“#【业务线】平台_【问题描述&影响范围】酒店无线分会场的问题，举例idxxxxxx、xxx83791703，是否平台标签“狂欢价”没生效#”，则可判定该用户消息中存在第二格式字段信息，且第二格斯字段信息的内容为“【业务线】平台”，即可据此确定所述的问题类别为“平台”。

或者，如果用户消息中不存在明显的第二格式字段，也可根据所述用户消息中包括的关键词信息等，来确定所述问题反馈信息所属的问题类别。

比如，可设置关键词为“业务”，如“平台业务”、“业务线”等，可先判断用户消息中是否存在“业务”相关的关键词，如果存在，则可根据“业务”相关的关键词来确定问题反馈信息所述的问题类别。

比如，用户消息为“平台业务中的标签‘狂欢价’未生效”，该用户消息中包括关键词信息“平台业务”，因此可确定所述问题反馈信息所述的问题类别为“平台业务”。

在确定了问题类别之后，可进一步根据预先建立的问题类别与解决人之间的对应关系，来确定所述问题反馈信息对应的解决人信息。

所述问题类别与解决人之间的对应关系可以表的形式预先保存于数据库中，具体的保存形式可如以下表1所述：

表1

同一问题类型可能会对应一个解决人或多个解决人，在确定所述问题反馈信息对应的解决人信息为多个时，比如，可通过从多个解决人中随机选择一个解决人的方式来确定解决人信息，或者根据各个解决人已经分配的问题数量等信息，选择已分配问题数量较少的解决人，并添加到列表中的方式来。

总之，在确定出问题反馈信息并添加到类别中的情况下，还可继续对用户消息进一步解析以确定出问题反馈信息对应的解决人信息并添加到列表中，一方面，更加便于由系统根据解决人信息通知解决人及时去解决相应的问题，另一方面，通过查看列表，问题反馈信息及对应的解决人信息一目了然，解决人可通过所述列表及时了解到需要自己解决的问题，由此，可进一步缩短从客服 人员反馈问题到技术支持人员解决问题的路径，提升问题的解决效率。

另外，在所述列表中还可包括状态信息项，即问题反馈信息对应的状态信息。由于，根据确定解决人信息的步骤并非一定能够确定出解决人信息，因此，还可根据是否确定出了问题反馈信息对应解决人信息，来确定问题反馈信息对应的状态。

比如，在确定出所述问题反馈信息对应的解决人信息后，则可将所述问题反馈信息确定为第一状态，在未确定出所述问题反馈信息对应的解决人信息时，则可将所述问题反馈信息确定为第二状态，并且所述问题反馈信息对应的状态信息添加到所述列表中。

其中，第一状态可设置为“处理中”，第二状态可设置为“待处理”，也就是说，在能够确定出所述问题反馈信息对应的解决人信息时，可确定该问题反馈信息对应的状态信息为“处理中”；在不能够确定出所述问题反馈信息对应的解决人信息时，可确定所述问题反馈信息对应的状态信息为“待处理”，以通过状态信息对所述问题反馈信息进行区分，以便于后续的统计、管理及对问题反馈信息的处理。

进一步的，在确定所述问题反馈信息对应的状态信息为“待处理”后，还可通过后台工作人员将所述问题反馈信息指定相关的解决人去解决，以使得一时没有确定出解决人的问题反馈信息，也能够得到及时妥善地处理。

在具体实现时，可提供用于指定所述问题反馈信息的解决人信息的第二操作选项；在通过所述第二操作选项接收到第一用户指派解决人的信息时，将指派的解决人添加到所述列表中，并将该问题反馈信息的状态修改为第一状态。

参看图4所示，可将第二操作选项设置为第一下拉菜单35，也即可通过操作第一下拉菜单35来指定所述问题反馈信息的解决人信息。在问题反馈信息对应的状态为“待处理”的情况下，第一用户(在本实施例可对应为系统的后台工作人员)可触发第一下拉菜单35以显示下拉菜单中包括的解决人信息(比如，解决人a、解决人b等)，当后台工作人员选定某一解决人后，则可将选定的解决人添加到所述列表中并进行显示，在选定解决人后，还可将该问题反馈信息的状态修改为第一状态(即为“处理中”)。

其中，在问题反馈信息的状态信息处也以提供第二下拉菜单36的方式实现对状态信息的修改，当后台人员可通过触发第二下拉菜单36以显示第二下来菜单36中包括的状态信息(比如，待处理、处理中、已处理等)，通过选定第二下拉菜单36中的“待处理”，即可将问题反馈信息的状态修改为第一状态。

此外，在解决人将其负责的问题反馈信息处理好之后，还可进入所述列表所在的界面，将问题反馈信息的状态修改为已处理。

在具体实现时，还可提供用于修改所述问题反馈信息的状态信息的第三操作选项；在第二用户完成对所述问题反馈信息的处理后，通过所述第三操作选项接收第二用户的状态信息修改请求，并将该问题反馈信息的状态修改为第三状态。

参看图4，所述第三操作选项也可为上述第二下拉列表36，在第二用户(在本实施例可对应为该问题反馈信息对应的解决人)完成对所述问题反馈信息的处理后，可通过触发第二下拉列表36以发出状态信息修改请求，并显示出第二下来列表36包括的状态信息，第二用户可在第二下拉列表36包括的状态信息中选择“已处理”，即可将问题反馈信息的状态修改为第三状态，以此表示所述问题反馈信息以完成处理。

以此，可根据解决人的确定情况、问题反馈信息的处理情况等来确定及修改相应的状态信息，后台人员可根据所述状态信息及时的对无解决人且处于待处理的问题反馈信息分配解决人，解决人可快速获知属于自己负责且处于处理中状态的问题反馈信息，且在完成问题反馈信息的状态信息修改为已处理，在可更好的对列表中的问题反馈信息进行区分管理的同时，还可提高问题的解决效率。

进一步的，在将所述问题反馈信息的状态修改为第三状态后，还可向所述即时通信应用的所述群组中发送通知消息。

也就是说，在解决人完成所述问题反馈信息的处理且将所述问题反馈信息的状态信息修改为“已处理”之后，还可向即使通信应用的预置群组(比如“问题反馈群”)中发送通知消息，比如通知消息可包括“某某问题已处理”，以便群组中的用户及时获知到该问题反馈信息的处理状态。

为了实现更有针对性的通知反馈人，还可根据所述用户消息确定所述问题反馈信息的反馈人信息，并在发送所述通知消息时，指定通知给所述反馈人。

在具体实现时，可在获得用户消息后，从用户消息中提取出该用户消息的发送者(比如，旺旺号为87654321的用户)，在该用户消息中包含问题反馈信息的情况下，该用户消息的发送者即为所述问题反馈信息的反馈人，在确定所述反馈人后，在发送上述通知消息时则可指定通知所述反馈人，比如可在通知消息的结尾加上“@87654321”，以更有针对性的通知该反馈人，以此，反馈人们只需关注指定反馈给自己的通知消息即可获得其反馈问题的处理情况，而无需从群组中每条消息中辨别出是否为自己反馈的问题。

与上述实施例提供的问题反馈信息处理方法相对应，本申请实施例还提供了一种问题反馈信息处理装置，参见图5，该装置可以包括：

用户消息获得单元51，用于获得即时通信应用预置群组中产生的用户消息。

解析单元52，用于对接收到的用户消息进行解析，判断所述用户消息中是否包含问题反馈信息。

提取单元53，用于在所述用户消息中包含问题反馈信息时，从所述用户消息中提取所述问题反馈信息。

添加展示单元54，用于将所述问题反馈信息添加到预置的列表中，以便通过所述列表将通过所述即时通信应用群组提交的问题反馈信息进行汇总展示。

在具体实现时，所述解析单元52，可具体用于：

判断所述用户消息中是否存在预置的第一格式字段信息，如果存在，则判定所述用户消息中包含问题反馈信息。

所述解析单元52，还可具体用于：

通过对所述用户消息进行语义分析，判断所述用户消息中是否包含问题反馈信息。

在具体实现时，所述添加展示单元54，可具体用于：

提供用于查看所述列表的第一操作选项；

通过所述第一操作选项接收到查看所述列表的请求时，展示所述列表中包括的各条问题反馈信息。

所述添加展示单元54，还可具体用于：

提供用于通过所述即时通信应用的用户消息发起查看所述列表请求的格式信息；

在接收到的用户消息中存在符合该格式的信息时，展示所述列表中包括的各条问题反馈信息。

进一步的，所述装置，还可包括：

第一确定单元，用于根据所述用户消息确定所述问题反馈信息对应的解决人信。

第一添加单元，用于在将所述问题反馈信息添加到所述预置的列表中时，还将对应的解决人信息添加到所述列表中。

其中，第一确定单元，可具体用于：

判断所述用户消息中是否存在预置的解决人信息提示符；

如果存在，则将根据所述提示符，从所述用户消息中提取所述解决人信息；或者

确定所述问题反馈信息所属的问题类别；

根据预先建立的问题类别与解决人之间的对应关系，确定所述问题反馈信息对应的解决人信息。

其中，在确定所述问题反馈信息所属的问题类别时，所述第一确定单元，可具体用于：

判断所述用户消息中是否存在预置的第二格式字段信息；

如果存在，则根据所述第二格式字段信息，确定所属的问题类别；或者

根据所述用户消息中包括的关键词信息，确定所述问题反馈信息所属的问题类别。

此外，所述装置，还可包括：

第二确定单元，用于在确定出所述问题反馈信息对应的解决人信息后，将所述问题反馈信息确定为第一状态；

第二添加单元，用于将所述问题反馈信息对应的状态信息添加到所述预置的列表中。

其中，第二确定单元，还可用于：

在未确定出所述问题反馈信息对应的解决人信息时，则将所述问题反馈信息确定为第二状态。

进一步的，所述装置，还可包括：

状态修改单元，可用于：

提供用于指定所述问题反馈信息的解决人信息的第二操作选项；

在通过所述第二操作选项接收到第一用户指派解决人的信息时，将指派的解决人添加到所述列表中，并将该问题反馈信息的状态修改为第一状态。

此外，所述状态修改单元，还可用于：

提供用于修改所述问题反馈信息的状态信息的第三操作选项；

在第二用户完成对所述问题反馈信息的处理后，通过所述第三操作选项接收第二用户的状态信息修改请求，并将该问题反馈信息的状态修改为第三状态。

在实际应用中，所述装置，也可包括：

消息发送单元，用于在将所述问题反馈信息的状态修改为第三状态后，向所述即时通信应用的所述群组中发送通知消息。

为了更有针对性的将通知消息告知反馈人，所述消息发送单元，还可具体用于：

根据所述用户消息确定所述问题反馈信息的反馈人信息；

在发送所述通知消息时，指定通知给所述反馈人。

通过本申请实施例，能够与即时通信应用对接以对即时通信应用进行监控，通过对获取到的预置群组中产生的用户消息进行解析，并确定用户消息中包含问题反馈信息后，将问题反馈信息添加到预置的列表中以进行汇总展示，以此，可通过自动化的方式对通过预置群组提交的问题反馈信息进行收集，可避免通过人工收集时发生遗漏的情况，提高问题的收集效率，从而可缩短从反馈问题到解决问题的路径，提升问题的解决效率。为了进一步提高问题的解决效率，还可通过对用户消息进行解析以确定出问题反馈信息对应的解决人信息并添 加到列表中，以更便于通知解决人去解决问题或解决人通过查看列表以及时了解到需要自己解决的问题。此外，还可在确定解决人信息后进一步确定问题反馈信息对应的状态信息并添加到列表中，可根据所述状态信息对问题反馈信息进行区分管理，在解决人完成对问题反馈信息的处理后，还可修改对应的状态信息并通过系统向预置群组中发送通知消息，以实现一个闭环的问题反馈信息处理系统。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的问题反馈信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。