当用户提出操作上的疑惑或者bug的时候，思路要清晰：
第一，用户做这些操作目的是什么，有没有其他的功能或者渠道可以先解决用户当前的期望
然后，手机在界面或数据上的错误反馈，排查是由什么原因导致的
接下来，如果判断出错误的基本方向或者找寻不到原因的时候，可以先将这个bug或者问题记录下来，等后面研发有时间了再进行根本原因的排查；如果是需要优化的功能或操作项，进行收集汇总，待下次优化功能的时候一起进行。如果第一点无法马上找到替代的解决方法，而这件事情对于用户而言是紧急的（即当下就要出结果的），可以临时插入研发的进程，进行处理。
举例：
1、用户在app上注册分销商账户失败的时候，了解用户的第一需求是为什么要注册分销商账户，如果是希望使用该账户进行下单，那是否可以用现有的账号帮用户下单；
如果就是需要注册一个账户，那除了app是否有其他途径进行注册，答案是有，还可以通过PC端注册，可以让用户先进行注册；
了解bug产生的操作步骤和页面反馈（一直提示验证码次数超过和不断加载），自行评估产生问题的原因是由于 验证次数的限制 、app的稳定性等引起的，是原生页面需要找app项目组解决。
联系对应的项目组解决，并告知用户以及相关关注此事的人员该问题处理的一个进度。
2、系统对接某第三方的票务资源进行预订
当用户反馈某个订单的 pdf票件说明文档无法下载，导致无法确认该订单是否出票成功的时候
（1）了解用户的第一需求是确定该订单是否出票成功，已决定该用户是否需要重新下单。因此，此刻最重要的不是找到bug产生的原因，而是确认订单是否有效。确认订单是有效的方式有3种：能下载pdf文档、查看接口日志返回成功、查看第三方票务系统有该订单，所以当下pdf确认失败、接口日志不能百分百保证的时候，就应该直接联系第三方进行确认。然后给用户及时反馈：成功或失败，需要重新下单。
（2）向用户收集页面提示无法下载pdf文件的截图、收集页面链接，和订单编号。初步评估订单产生问题的原因（由于超时产生订单问题），然后交与研发处理（讨论能否延长时间限制、或者减少给用户的付款时间，多留一些时间给接口调用）
（3）功能优化：需要一个明确的信息反馈给用户，该订单是否真正出票成功，而不是仅靠pdf这个非决定性的判断因素。
*出票成功提示：直接获取票编码显示在页面上，用户能直接看到票编码即出票成功
*出票失败提示：由于系统原因导致的用户出票失败，即向下单用户发送短信消息 和 系统消息，确认失败的请重新下单，不确定失败的请让用户直接联系客服
（4）功能优化：下单的机制
讨论是否由于现在下单机制的不合理导致失败的订单增多，如果是，应该怎么修改。
比如多张票一起预定的时候，部分成功，部分失败后，由系统进行重新提交出票申请，页面反馈给用户正在下单，请稍等；由于库存不足导致失效的，反馈给用户库存的原因部分失败，由用户确认是否继续完成交易。
