企业电子化的专家 Ragic 教你如何利用各种软件、
云服务让公司快速升级!
加入 Ragic 企业电子化的行列!
云工作术
各类应用演示
案例故事
逃离恶梦
关于 Ragic
云数据库
博客
关于Ragic
云工作术
各类应用演示
案例故事
逃离恶梦
关于 Ragic
云工作提案
软件比较
表格技巧
数码新鲜事
3C小学堂
免费范本
产业应用
理财
健康
职场 / 生活
制造业
零售业
服务业与其他产业
工程地产
政府 NGO
职涯与合作伙伴故事
电子化迷思破解
逃离 Excel 灾难
告别 ERP 恶梦
打印件恐怖故事
职场日记
我们的故事
Ragic教学
社群与客服
公告

如何问问题才能让客服有效地协助你?

作者:Amy Tsai

使用信息产品/软件遇到问题,你会去问客服吗?有没有一种经验是,原本以为问题很清楚,把问题丢给客服就可以得到答案了,结果客服不但没办法马上给你一个满意的答案,还反过来一直问你问题,跟你要东要西(更多的信息)?

我自己其实也有同样的经验,我写信问脸书客服时就是如此!

当时我写信给facebook询问使用上遇到的bug,对方也是要我提供详细的信息,例如我的帐号、有问题的页面网址、操作步骤、画面截屏等,看到需要做那么多事情、要提供那么多信息,就会觉得,蛤~太累了吧!怎么那么麻烦?怎么那么啰唆?(的确当时我最后是直接放弃解决此问题的)

但是我自己当客服之后,看事情的角度转换,会发现有些信息真的是必要的。有时候从订户的角度来看,自己的状况很显而易见,但客服不是你肚子的蛔虫也看不到你的很多设置跟画面,那就完全不一样,不要期待客服会通灵。

这里给大家看个两方的心声对比图:

以上,是数不清的两方的心声(也是两方的心酸处)

以Ragic的产品为例,Ragic是一个不用写程序就可以设计数据库的软件,基本上建置设计的方式就是根据需求来决定可以用哪些设计工具来达到。而Ragic的客服都在做什么?其实主要就是协助客户使用Ragic数据库,协助的部份例如指引设计建置的方向、数据导入的注意事项、意见及需求搜集、Bug疑难排解等。但是在我们不熟悉客户的产业、工作流程下(我们的客户来自全世界,各行各业),我们可能就需要范例材料,来了解实际上客户想要达到什么样的事情,才能依此提供进一步设计上的建议;亦或是有bug需要疑难排解时,我们会需要详细的信息来了解用户是如何复现问题的,才能请开发人员协助修正。

在累积了很多跟客户交手的经验之后,发现很多客户都有“没办法把问题问清楚”的症头,虽然我们可以理解,但你之所以会跑来问问题,就是有需求,而且很可惜的是,那些后来放弃问问题,或是一直鬼打墙的客户并不知道,其实只要掌握一些要点/撇步,就可以大幅减少这种来来往往彼此耗损的时间 ,所以我把我的经验整理成要点,相信对你有帮助,请看!

1. 需求/问题

今天之所以会寻求一套软件、系统,会问问题,回到最根本的源头,就是因为有了需求!因此身为客户,知道自己要什么很重要。

其实我最怕的不是不会问问题的客户,而是不知道自己要什么的客户

例如有些新公司,觉得公司成立后就马上要一个数据库系统,这个观念固然是好的,但是却不知道要用自己为什么要用数据库,有什么需求才要用数据库,那可就不行了

例如:你们提供哪些应用? 别人都用什么?

或是,有些人很高兴地写了落落长的内容,其中交代了时空背景、个人的愤慨及心声等,但客服看完了以后,还是不知道他的问题在哪里,反而会不知道要回覆客户什么,这样子其实也是蛮尴尬的!

⟡换个角度举例:

你去电影院买票时,卖票员的第一句话一定是问:“今天要看哪部电影?”

而你的第一个回答通常是:“今天3:30的疯狂亚洲富豪 2位”而不是“其他人都看哪部电影?”或是“你建议我看哪部?”(如果真的要建议,至少也要知道你喜好的电影类别,才能给予进一步建议)

⟡情境举例:

以下是客服与客户的对话内容

客户:“我1/1-1/2的出货单都不见了”

客服:“请问出货单是哪一张表单呢?我这边只有看到‘销售订单’,是有1/1-1/2的数据的,没有看到‘出货单’,是否能提供表单网址以利我们了解呢”

客户:“www.ragic.com/test/1/1”少了大概10笔以上 (其实就是销售订单)

客服:“请问原本是几笔数据呢?是什么时候发现的呢?”

.

.

.

当问题内容不够完整或是详细话,很可能就会需要一直来来往往的回信,以上述的例子来看,如果可以单击照这样的方式描述,客服也能很快地掌握问题:

1.有问题的表单网址

2.问题描述及说明(例如原本应该是几笔数据,在什么时间点开始遇到问题,遇到问题前是否有操作什么样的步骤,或是可以用什么样的步骤复现问题)



如果你只是单纯想知道我们有没有支持一般性的功能,像是“Ragic也可以套公式吗?”、“Ragic可以搜索数据吗?”、“不小心删掉的数据可以救回来吗?”等其实一句话就可以概述的问题,掌握第一个要点-需求/问题,将问题详细明瞭的写下并送出就可以了,但是如果你想要问的问题,是有特定情况、规则等的话,就会需要再提供更细的内容以利我们了解,例如以下几点:

2. 范例(实际的数据范例)

当你的问题是比较情境式的话,像是在什么样的情况或条件下,想要达到什么样的事,这样的话,除了提出需求以外,如果能搭配一个例子,总是比凭空描述更容易让人了解。

但又为了避免例子举的不对或是不好而造成方向错误,能以实际要问的数据作为描述的范例的话会更好。

例如:

①我有一张表单,我希望有些人可以看到,有些人不行

②我有一张表单,我希望有些人可以看到A,有些人不能看到A但可以看到B

③我有一张客户表单,我希望有有些人可以看到客户A,有些人不能看到客户A但是可以看到客户B

以上三种表达方式,你觉得哪一个更为清楚且更为好懂呢?


如果有现成的数据范例文件,除了以描述提出的范例以外,也可以提供文件给我们参阅(这部分可以往下滑到第5点辅助材料-截屏及视频或是现成的数据文件



3. 步骤/流程说明

数据不会自己凭空出现,或是没有做任何设计或设置就可以做到流程自动化,经过哪些步骤才会有这样的结果/问题,或像是数据从哪里来、会因为经过哪些流程而做了哪些转换、如何影响到其他数据,以上这类整体的数据使用流程对我们来说都是很重要的!

⟡情境举例:

收到客户的问题信,内容附上了有问题的数据或表单网址,告诉我们哪个字段值错了并授权我们进入查看

以上信息看似充足,但我们进到数据库以后发现,这些字段都是只读的,那他数据从哪里创建的?怎么创建的?这个值是怎么计算出来的?正确的值应该是什么呢?

毕竟不同的数据库是根据不同用户/组织自己的工作流程创建的,数据也是根据自己的工作流程输入的,如果只有单一片面的信息,客服比较难凭自己理出完整的问题!像是有时候客户的数据库换了一个系统管理员,可能因为没有交接等各种因素,新接手的人并不熟悉整体的数据使用流程甚至是自己的业务流程,所以输入或使用数据的步骤与原本设计应该要走的流程不同而生成了问题,这时求助于我们的话,我们会比较难给予完整的协助,因为这个数据库不是由我们建置的,数据也不是我们熟悉内容,或者也无法了解原本各个地方如此设置的用意及原因为何等。(交接很重要啊!)

又或者也许客服可以像抓漏师傅一样,针对客户的整个数据库做个场勘,自己一点一点去追溯问题的源头在哪里,但花费的时间相对就会比较长了(而且往往大家想像的或是实际的操作方式都还是不太一样的,因此有可能客服怎么样都无法测出与客户描述相同的问题)

⟡情境举例:

客户写信来问说:“我的这张表单数据新增保存时公式没有触发”

而我进到他的表单测试怎么测都没有问题,只好再回信询问:“请问数据是如何新增的呢?,否能详细描述步骤或是提供画面截屏呢?”

客户回了信:“没有什么特别的方式,就是正常新增”

因此我只好自己努力奋斗,拼命测试,想尽各种不同的方法来操作,百思不得其解直到最后才发现,原来是因为我们新增数据的方式不一样呀!

他是从列表页快速新增数据的,而我一直测试以上方的红色"+新增"单击钮来从表单页创建一笔数据的方式,自然也就无法复现...



当你的问题是根据步骤就能复现,要请我们查看确认的话,就不需要再提供下面第4点的规则细节,但有时候能有下面第5点的辅助材料-截屏或视频,对我们来说也是会有很大的帮助的!但如果你想做到的事情,是要根据特定规则判断来达到特定的目的的话,就要提供下面第4点规则细节

4. 规则细节

除了了解问题、整体的流程以外,还有一些问题是比较偏向想要做到特定性的事情,因此就会有特定的规则,例如今天某个字段要利用公式计算总额,但这个计算是要经过特殊判断的,那总额是哪个/些字段值的加总呢?如果是有条件的,那详细的条件内容是什么呢?

⟡情境举例:

客户来信询问,如何针对他们的客户及产品数据,自动产出这样的内容?(附上了字范例)

信件来往了几封以后,我们还是没有成功了解详细的规则细节,例如实际上是要根据哪张表单的哪个/些字段,及什么样的条件下等详细说明来达到他想要自动计算的部分,最后客户问了我们“那你们建议怎么做/做成什么样子?”

根据上述的情形,由于数据库是客户的,其中数据也是客户输入的、要用的,因此想要怎么呈现,想要以什么样的规则运作,不应该是由客服来决定,尤其如果这是特定性需求,像是因自己的公司内部或是行业而有的客制化类的内容,规则细节应该是由客户自己订定的而不是客服,因为不是由客服来决定客户的工作流程及数据产出。若是一般性需求,各个产业都会用到的功能,例如想要做到报价单转订单,询问我们设计上会如何建议,那当然是没有问题的!



5. 辅助材料-截屏及视频或是现成的数据文件

大家对各个功能或是名词可能用的用语跟我们都不一样,因此往往无法了解彼此在讲什么(这里也附上我们的名词解释),像是“子表格”,“子表单”,傻傻分不清楚— 大家常常讲“子表单”,是想用来表达“子表格”,甚至有时候连“子表格”都不是,可能是想表达其他东西,这时候我们可能就会理解错误,也就很难快速了解实际的问题是什么了!若是怕表达的不对,或是可以更确切地给予信息,有个画面截屏也能帮助到我们!

⟡情境举例:

客户打电话来询问问题,在电话中他是这样描述的:“其他字段都是A1,A2,A3,或是你看C1,C2,C3,那你看下面那个A,B,C,D怎么做出来的?”

我因不太确定他的意思,又请他再重新描述,他跟我说:“我的意思是,其他都是从上到下,那个从左到右怎么建的?”

在看不到任何画面的情况下实在是不知道客户在讲什么,在电话中我们折腾了一番以后,我最后终于知道他要问的是什么了!原来是“子表格”呀!我在电话中跟他描述了一下“子表格”是怎么设计出来的,但是用电话实在是太难表达了,因此客户也是有听没有懂,只说自己再试试看好了...

以上述的情况为例,其实客户直接利用专人协助 > 客服信件来发送问题信,附上一张画面截屏询问这个是怎么设计的,我们就能马上掌握问题的内容,并附上我们的功能文档,让客户能够根据文档内容一步一步操作,这样是不是比电话沟通来得有效率呢!

提供截屏的时候,请尽量以完整的画面做截屏,例如一看到截屏画面就能看到表单的网址、表单名称、识别得出是哪一笔数据、有问题的地方的位置(标记出有问题的字段),这样会比只截取了有问题的那一小块画面来的详细。当然,信件内容中如果直接提供了有问题的表单/数据网址,让我们能直接进入并跟着截屏操作,那是客服最感激的了!

若是觉得比较难用字来表达整个操作的步骤或流程,也可以利用屏幕录制来录成视频,有需要的话可以参阅我们的这篇文章:新手教学:屏幕录像怎么做?(手机/计算机/Windows/MAC/iOS/Android)

有些人可能会担心数据的隐私问题,因此不愿意提供现有的数据文件给我们当作参阅的范例,有这类的疑虑的话,其实可以把数据改成假的内容再提供给我们就可以啰!有些客户甚至也会要求我们签保密协议才能将文件提供给我们参阅,这部分当然也是没有问题的!



以上这5大要点,希望能够帮助到大家!根据这些方向来提出问题,我们客服团队也能更有效率地抓中您的问题要点并给予进一步协助!这里也提供寻求Ragic客服协助的四种方法,让准备好要问问题的你可以联络到我们!


请记得,发送问题信时请不要:

一句简短的信件主旨 没有任何问题的信息

一段非完整画面的视频只试范了步骤 但没有其他详细信息

一张非完整画面的截屏及问题 但是没有给其他详细信息

博客背后使用 Ragic! : 最强大的 No Code 企业电子化工具
    把数据放在Excel上不只是拖累团队的行政效率,他也很容易出错并且无法进行任何内控。
    当您的团队成长时,使用Excel管理数据就会越来越痛苦。
    创建你们的第一个云数据库!

    马上登记
    免费试用 Ragic!

    用 Google 帐号登记

    北京立即科技有限公司
    京ICP备2022003680号
    用户条款 | 隐私权政策