Assembla is a Project Management tool with integrated repositories (subversion, git, hg and perforce) with an integrated bug and issue management tool.
You can interact with each other in the system via @mentions or emails to get focus directly to the questions of your customer for your engineers.
Furthermore, your customers can follow the status of the fix, without having to ask, they can just view the status in the system.
As a point of clarification, it sounds like your process is flowing like so:
1- Client calls up "help desk" or whomever and requests a change to your software. 2- Call recipient inputs, verbatim, the request into your bug tracking system. 3- Recipient of bug contacts client and gets more details on the request. 4- After the details are worked out, often times the original request looks no longer like the actual request.
Does that seem right?
It sounds like you need to separate your bug tracking system and your CRM system and better train the people that communicate with the clients to ask better questions and log more details.
You should set up your bug tracking software to notify appropriate people each time some one touches the bug. This way the "10 emails back and forth" are generated on changes from the software.
No, of course you don't add a client's email to the bug tracking software (JIRA, bugzilla, etc) but you do forward to the client the changes you think appropriate, and you do incorporate the client's requests into the description of the proposed fix.
FogBugz allows you to email the client through its interface, and will track correspondence through FogBugz. It will only show the client the emails to or from them, but show internal users (developers) internal bug communications as well
发布评论
评论（4）
免责声明：我是 Assembla 的 CTO
Assembla 是一个具有集成存储库（subversion、git、hg 和 perforce）的项目管理工具）具有集成的错误和问题管理工具。
您可以通过@提及或电子邮件在系统中相互交互，以便直接关注客户向工程师提出的问题。
此外，您的客户可以跟踪修复的状态，无需询问，他们只需在系统中查看状态即可。
Disclaimer: I am the CTO at Assembla
Assembla is a Project Management tool with integrated repositories (subversion, git, hg and perforce) with an integrated bug and issue management tool.
You can interact with each other in the system via @mentions or emails to get focus directly to the questions of your customer for your engineers.
Furthermore, your customers can follow the status of the fix, without having to ask, they can just view the status in the system.
作为澄清一点，听起来您的流程是这样流动的：
1-客户致电“帮助台”或任何人并请求更改您的软件。
2- 将收件人逐字输入的请求输入到您的错误跟踪系统中。
3- 错误接收者联系客户并获取有关请求的更多详细信息。
4- 确定细节后，通常原始请求看起来不再像实际请求。
这看起来对吗？
听起来您需要将错误跟踪系统和 CRM 系统分开，并更好地培训与客户沟通的人员，以提出更好的问题并记录更多详细信息。
As a point of clarification, it sounds like your process is flowing like so:
1- Client calls up "help desk" or whomever and requests a change to your software.
2- Call recipient inputs, verbatim, the request into your bug tracking system.
3- Recipient of bug contacts client and gets more details on the request.
4- After the details are worked out, often times the original request looks no longer like the actual request.
Does that seem right?
It sounds like you need to separate your bug tracking system and your CRM system and better train the people that communicate with the clients to ask better questions and log more details.
您应该设置错误跟踪软件，以便在每次有人触及错误时通知相应的人员。这样，“来回 10 封电子邮件”就会根据软件的更改生成。
不，当然，您不会将客户的电子邮件添加到错误跟踪软件（JIRA、bugzilla 等）中，但您确实会将您认为适当的更改转发给客户，并且确实将客户的请求合并到建议的描述中使固定。
You should set up your bug tracking software to notify appropriate people each time some one touches the bug. This way the "10 emails back and forth" are generated on changes from the software.
No, of course you don't add a client's email to the bug tracking software (JIRA, bugzilla, etc) but you do forward to the client the changes you think appropriate, and you do incorporate the client's requests into the description of the proposed fix.
FogBugz 允许您通过其界面向客户端发送电子邮件，并将通过 FogBugz 跟踪通信。它只会向客户显示发送给他们或来自他们的电子邮件，但也会显示内部用户（开发人员）的内部错误通信
FogBugz allows you to email the client through its interface, and will track correspondence through FogBugz. It will only show the client the emails to or from them, but show internal users (developers) internal bug communications as well