I hope there are some brave souls out there willing to read the following. And suggestions would be a huge help! Thank you in advance!

Questions: 

1. When a SLX User response to a Contact’s email the ACTIVITY TYPE is listed as Received Email in the TICKET ACTIVITIES window for the TICKET entity.

2. When a Phone Call activity is inserted into the TICKET ACTIVITIES window via right-click and selecting “Insert New Activity” from the list this phone call activity does not show up in the ACCOUNT entity’s NOTES/HISTORY. However, completing a scheduled Phone Call Activity does appear in both the Account NOTES/HISTORY and in the TICKET ACTIVITY window. Is this normal? If so, is there some explanation as to why an inserted Phone Call activity would not be listed on the Accounts View, but a Scheduled Phone Call activity for a Ticket would?

3. When a contact’s email is brought into the TICKET ACTIVITIES window via Drag-&-Drop a window pops up which allows the user to “Complete E-Mail for Contact.” However the information box associating the E-Mail to the Ticket sometimes fails to populate with the Ticket Number BOX and remains blank. Shouldn’t the Ticket number associated with the TICKET ACTIVITIES window used during the drag-&-drop automatically populate the Ticket BOX for the activity? This inconsistency of Ticket association does not appear to be normal.

4. Likewise, when the Contact’s email is replied to by the user, The “Complete E-Mail for Contact” window pops up again, and again only sometimes populates the Ticket Number box with the correct Ticket. I cannot find any reason for the inconsistency of Ticket association.

5. Also the Contact BOX in the “Complete E-Mail for Contact” window always Defaults to list the Contact assigned to the Ticket, not the contact and sender of the dragged email. Shouldn’t the Contact be listed as the Sender if that sender is a contact for the account rather than defaulting to listing the contact which is assigned to the Ticket?

 
Thank you so much for your help!

David

OK, will step up !

1) Yep, should show Sent Email - correct.
2) Ticket Activities relate to any activity on the ticket that should be costed/uses parts etc. and don't show on calendar. The Activities tab relates solely to calendar items.
3) Yes, it should - although, I've not seen that - and I've been using this extensively lately !
4) See above
5) No, the dragged email is recorded against the person (the contact) of the ticket, not the person sending in the ticket (otherwise, it'd have to create a new ticket) - it could be that contact B is sending in more info that contact A created. Any drag/drop operation is always based on the thing you drop to - irrespective of where it comes from. This is the same for the general con/acc/attachments - the drag/drop reacts to the acc/con/attach you are in (not where it came from). Hence, you can drag/drop from anywhere and it just inserts it to the currently focused record.

Mike

Mike, 

 

Thanks for coming through for me again! I really appreciate the help. All of your answers were very clear. I just wasn’t sure I was clear with regards to question two (2). It appears that you are comparing what appears in the ACTIVITIES tab of the TICKET entity vs. what appears in the TICKET ACTIVITIES tab of the TICKET entity. If it’s ok I’ll try to clarify what I was comparing.

 

I am looking at how the ACCOUNT entity works with the TICKET entity. More specifically, I am looking at what appears in the ACCOUNT entity’s NOTES/HISTORY tab when activities are tracked in the TICKET entity’s TICKET ACTIVITIES tab. I noticed that Dragged emails, sent emails (Reply or New), scheduled phone calls, etc. all appear in the NOTES/HISTORY when they are entered in the TICKET ACTIVITIES tab. But phone calls which are entered in the TICKET ACTIVITIES tab via a Right-Click and “Insert Ticket Activity” function, that action is not see in the ACCOUNT entity’s NOTES/HISTORY tab. Isn’t the ACCOUNT entity’s NOTES/HISTORY tab supposed to record all of the activities which occur for that account? Thus, if a phone call occurs for a Ticket on an account, shouldn’t the phone call appear in the NOTES/HISTORY, regardless of whether it was scheduled or inserted as an activity?

 

“Curiouser and curiouser,” cried Alice.

 

David 

Hi David

Yes, it is a little confusing but what it comes down to is how the drag/drop etc. is implemented. If you notice, when you drag/drop you are presented with a Complete Activity for form. This is the default. It knows to link with the current con/acc & ticket and, on completion of the form ends up in Ticket Activities and also Notes-History (as it would if you just drag/dropped anything to a current acc/con record. This is a standard function they link to.

However, if you use the Insert New Activity option from the Ticket Activities area it brings up a completely new/different form (relating to assets/products/parts etc) - so, whilst it does get logged as an activity - it's specifically only for the ticket and not generally.

Of course, there's a counter argument that says it should appear in both.

Regards
Mike

I see. Well, at least I know what it is supposed to do and can plan for what I want. Thank you for clarifying the functionality. With these other issues which are causing the activity to inconsistently fail to associate with a Ticket I am not so lucky. I may have to get on the phone with Sage Tech Support and see if they can assist a little more.

 

Thanks again,

 

David
 

Hello all

 

I’m looking for some tips and ideas regarding usage of Tickets.

 

I really like the Area/Category/Issues fields which can be completed with a Ticket. They provide for quick recognition of issues and more reporting capabilities. But in the real world we are finding that Tickets don’t come one at a time. Usually our clients call or email with Customer Support needs which fall into entirely different issues, categories, or even areas. I have explored the “Copy Ticket Information” function to create more than one Ticket for a single call or email which comes through with multiple issues. But the end result is that handling of the Ticket requires duplication of schedule of follow-up events for both Tickets. It also makes use of the Tickets as a “reference on the fly” when a customer calls difficult since the Tech Support user would have to switch between Tickets to answer the Customers need.

 

Without adding a lot of extra work to the Tech Support team, how do you use Tickets to enter and track Customer Support needs which contain more than one need relating to more that one Area, Category, or Issue? Who can offer suggestions as to Best Practice regarding use of Tickets?

 

Thanks for the brainstorm!

 

David

David, due to the dependency of ACI on things like speed search, future lookups, reporting, statistics, charging etc. it's best (albeit a little slower) to record 1 ticket per issue. I realise this does slow the process down but, in all honesty, it's best practice.

I'm currently working in a support team right now and on 2/3 level so I frequently get issues past to me for further analysis etc. It's nice to know that I have 1 ticket = 1 problem. Once resolved, I can close it out and not worry that I've just "lost" the other 5 that were in the same ticket! It also ensures that the "closed on 1st call" can be utilised and date/time opened/closed relates to that specific issue and not all of them (leading to long open durations for each ticket).

When you have to run multiple follow-ups, multi-activites, attachments etc. you really can't just stuff it all into one ticket and hope for the best - it soon becomes cluttered up and too confusing to work on! I actively refuse to work on any other principle !

What we then do is "link" the tickets together via a simple email for the customer. This, at least, gives them multiple ref's for each of their issues.

Hope this helps.
Mike

See, I knew I would get some great answers here! Your broad view of all that is affected by the Multi Ticket approach is excellent. I am in the development process for Tickets and really have a limited amount of experience actually going through the Ticket entry, resolution search, reporting, etc. functionality of Tickets. Your points in support of the multi ticket approach provide examples of use which I have not yet encountered. Thank you for the expertise.

David
 

You're welcome - I've worked as user, then a manager of a bunch of users (whilst working for a BP), now a BP in my own right, and also, currently, back as a user so I know all the angles (in relation to tickets!). Glad it helped you !

Hi Mike,

 

Since you have been actively working with a support team, I was wondering if you might give me some tips regarding setup of the Area-Category-Issues. This question may be geared more towards understanding methodology and approach when setting up these fields for Tickets. But perhaps understanding of functionality linked to use of these fields will also help provide some ideas.

 

I have been reviewing the type of support issues which our company handles, how they originate and the path they take. (This was the source for my questions regarding review of the Long Notes portion of the Notes History. Currently Tickets is not being used and support interaction is logged in the Notes/History.) It is my understanding that the Area-Category-Issues fields are too provide a quick snapshot of what type of problems the Ticket represents. My initial thoughts are that these fields would be completed by a user at the start of a new Ticket. Then, as the problem became clear the user would be able to change the fields to better represent the type of problems serviced by the Ticket since the problem stated by the customer many times does not represent the real issue. This mode of operations would seem to direct that the fields Area-Category-Issues would be developed to list options related to the type of problems commonly addressed, not options which describe the problem as stated by the customer. But if that is the case, why are these fields listed for completion at the beginning of the entry process for a new Ticket? Wouldn’t completion of these fields at the start of a Ticket increase the risk that support staff might complete the Ticket Area-Category-Issues incorrectly and thus contaminate reporting of the type of problems being handled?

 

The methodology behind how the Area-Category-Issues are used would seem to dictate not only the type of options available in each field, but also how many options need to be developed and available to the user. In your experience, how many options is it safe to make available to the user from the pick list before you begin to loose accuracy in the type of options being chosen? And understanding of this would provide me, the developer, with an understanding how many options I am limited to in describing the types of issues I see.

 

I understand that answers to most of the above will be based on choices for your specific team, type of industry, etc., but I think some examples of usage would be a great help. What would you consider to be best practice on this one?

Ah, in that respect I have been fortunate in that the support team I'm working with is supporting SalesLogix and associated/similar products! So, in our case the Area is the product (SLX, MSCRM, Internal Dev, Scribe, Vineyardsoft etc). The Category, relating to the Area, is then the module within the product e.g, when you select SalesLogix, you can then select Admin, Architect, Network Client, Bundler etc. Finally, the Issue is free text (in other words, just a 2 tier system).

This enables the typical reporting (what issues are we facing with the network client), how many problems are open for Scribe etc.
That's pretty much how far you'd want to go at that level I'd imagine (anything else is fluff and detail) [but possible]
We use the description/resolution box to physically describe the issues and s/search to find related issues later on.

We that in mind, from the rep's point of view (don't forget, they are on the phone) they can take a call/email and immediately and quickly categorise it with Area/Category (for reporting/stats but not searching) for management purposes. The rest comes down to the workflow in the description/resolution side. But, as it's open - they can, of course, come back and change it to better reflect the issue at hand - and that's just training/professionalism on the rep's part.

Hope that helps.

Yes, that does help. So one method, if a company is product based, might be to setup categories by products and their components. I was not aware that the "Issues" field could be maintained as a free form field. This definitely takes work away from the developer who is setting up Tickets. And as you say, it may be that any more detailed structure below the second level may be unnecessary for reporting purposes.

Thanks again for the brainstorm.

 

David
 

Yep, if you go to Tools | Manage ACI - you'll see it in there (ability to free-text)

Rgds
Mike

Hi Mike,

 

I’m hoping you can shine a little light on something for me. When completing a Ticket activity, the “Complete Activities Information” box has been set to pop up for each user. This lets the user manually removing the account association of that activity with the Account. The goal in doing this is to keep the Ticket activities from adding clutter to the Account’s Notes/History tab.

 

I don’t believe that this will create any issues with our ability to Report. It seems to me that removing the association of the activity with the Account in the “Complete Activity Information” box will only keep the multiple entry of the activity in both the Account and the Ticket activities tab from occurring. The Ticket itself is still associated with the account. Are there some reasons you can think of as to why removal of the Account association for the Activity would be a bad idea or lower important functionality?

 

Thanks again for the expertise,

 

David

Hi David

This is true, you will still be able to report/show tickets per account. By not storing it in Notes-History - the only thing you will do is prevent an "ordinary" user from seeing that information (in other words, it won't be a complete view). The "clutter" as you say, is there for a complete historical view at a glance but, take your point. It means those other users will have to be taught to view the ticket tab if they want to see what's going on with an account - for account review purposes etc.

Regards
Mike

LOL. Yes, clutter may have been too harsh a word. LOL That was good for a laugh.

 

I completely agree. I see maintaining a complete historical view of the account activity as very valuable. Similar to an accountants journal entry, it provides the chronological clarity which may be needed. Part of our problem right now is that we are not using the Opportunities or Tickets entities. The user is force to go to the Notes/History for everything. With the number of entries and the limitations to scanning through those entries quickly, I don’t know how usable that historical view could be to a daily user. I believe that once the users are using Tickets for Tech Support, and Opportunities for pursing a sale having everything listed in the Notes/History will suddenly make sense to users.

 

I will need to consider the amount of time it will take to both implement and get use of both Opportunities and Tickets in place. Then it seems management will have to weigh the worth of associating all activities with the accounts during development thereby filling the Notes/History with many activities, or disassociating the activities until all entities are in place and risk loss of a comprehensive history in the Accounts entity.

David

But wait! There’s more! You get the Ginsu knives!

 

I’ve got to admit, I feel bad for having submitted so many questions. But I must also say that I am more than willing to do the research myself and then come to the GoodAnswers forum to discuss Best Practice, etc. The fact is that I find use of Sage’s SalesLogix documentation to be hard at best for finding answers which provide enough information. For example, (yes, here comes another question…)

 

I want to find out about the process of both Submission of Resolutions for SpeedSearch and Approval of Submitted Resolutions for SpeedSearch. Through the SLX documentation it is clear how a user submits a resolution for SpeedSearch. There is also information discussing how someone would go through the process of searching for resolutions although I have not been able to see this in practice for myself since there are no resolutions yet added to our SpeedSearch. But I cannot find any information showing me how I would, as a manager, review and approve a resolution which has been submitted. I have only found a few sentence in various areas of the SLX documentation which states that the manager can approve submitted resolutions for inclusion in SpeedSearch, but that’s it.

 

I’ll admit that I’m a thick-o if it’s out there and I’m just not seeing it. Until then, any comments on how the Submit Resolution to SpeedSearch process works?

 

“Give a man a fish and he eats for a day. Teach him to fish and he eats for a lifetime.”

 

PS: I imagine I am at risk of having my comments listed as abuse for having asked so many questions. :0)

DGComco:

PS: I imagine I am at risk of having my comments listed as abuse for having asked so many questions. :0)

I've got my eye on you!

He he !!

OK, here goes:

There are several items you need to setup to make this work effectively and you can choose a route that suits you best:

(a) Have items submit to S/Search but don't allow them to be entered automatically. This ensure consistency of questions and answers but increases someone's workload to review/edit/sanitise them. And, until they are approved, they don't go into the search. Generally, I don't bother with this as no-one does it.

(b) Have the rep decide whether the customers' issue is relevant or not for searching later (i.e. a common issue that may re-occur). They simply select the option "Submit to S/Search".

So, let's assume you want to do (b), firstly go into Admin and go to : System | Office and double-click the office. You will notice a tab called Service/Support - click it. On here you will see the S/Search option "Use Approval Process". Turn this Off. However, whilst you are here - Press F1 and you will see the option "Understanding the SpeedSearch Approval Process" - have a read !

If you want to do (a) - then you definitely need to read up on this option !

HTH!
Mike

 

 

 

Isn’t it great how the answers just flow out of this forum? Thank you, Mike!

 

I am new with our company and have been reviewing functionality and usage available to the user via a standard user’s login. Our IT has maintained the admin until now. I have been considering when to require admin access. It appears that time has come. I was told that I had all of the admin help menus, but I won’t be surprised if I find much more documentation when I sign on as admin. I guess I must take on the self proclaimed thick-o status for not having reached this conclusion earlier.

 

I am going to optimistically pursue use of option “a” and look at implementing a Resolution Review process. I think this will be important in guiding our Customer Service in how to recognize and submit the kind of information we would like to utilize without risking a loss in the quality of searchable resolutions. If your experience holds true here as well I will revert to option b.

 

Thanks again,

 

David

 

PS: See! I knew it!

No problem - if you haven't got access to admin - at least get IT to send you the chm (Help) file - there's a whole TON of stuff you are missing for setting up infrastructure/processes such as this ! Also, get them to send you the Implementation and Planning guides off the DVD - there's good info in there !

The client help is for the client - not the setup !

Regards
Mike

 

After I began researching SalesLogix functionality I realized that I didn’t have all of the help menus which I needed. I went to the system administrator, acquired all of the her chm help files, and place them with those I already had under C:\Program Files\SalesLogix assuming that SLX Help would now search through all present chm help files when I performed a search. Unfortunately only some of those new chm help files became searchable from the SLX Search, even when logged in as Admin. Until today I had become very discouraged with the lack of information found through the SLX Help menu. But today I manually launched the Admin.chm files from the C:\Program Files\SalesLogix and begin to find the information I had been missing.

 

Many thanks, Mike, for helping with this resolution.

 

David

 

PS: If anyone has any tips on how to incorporate the additional chm files I acquired into the field of information searched by my SLX Menu I'd love to hear them.

Wow! This one’s a tongue twister.

 

Can someone clarify the purpose of the Ticket Activity Parts tab and an example of how it would be used?

 

It appears that, for every activity for the Ticket there is a Ticket Activity Part entry listed. These entries are listed in chronological order with the first activity listed at the top of the list. The only reference to the Ticket Activity Part entry’s corresponding entry in the Ticket Activity tab is the listed activity type. It is simple to find the Ticket Activity Part for a Ticket activity if there are only a few Ticket activities for the Ticket, and if the activities types are fairly unique. But for Tickets with multiple similar activities, finding the Ticket Activity Part associated with the Ticket activity is very difficult since the only reference the user has to the original Ticket is the activity type.

 

If the purpose of this tab is to allow users to find the parts associated with a Ticket activity, how can this be done when there are multiple activities with the same activity type? I am able to organize the Ticket Activities in the same order as they will be shown in the Ticket Activity Parts tab and then manually count through the list of activities to confirm that I am looking at the right Ticket Activity Part entry? But I can’t imagine this is the expected usage of this tab? I contacted Sage who confirmed that my Ticket Activity Parts tab is working correctly, but they could not offer any explanation of how this tab would be used to show the parts associated with an activity.

 

Any ideas or examples of how this tab is used would be helpful.

 

Thanks,

 

David

Hi Mike,

 

This is a question stemming from a really old post of yours. I’m interested in how your group handles emails or phone calls which are received containing requests or information related to multiple Tickets. Do you drag an email containing information for multiple Tickets into SLX multiple times, once for each Ticket? (resulting in duplicated emails in the Account’s Notes/History containing different associated Ticket numbers.) Or do you just drag the email into the first Ticket and loose the initial email reference for the second Ticket?

 

If you have an email which references information for both a Sale and Information for a Ticket, do you drag the email twice allowing for different Category choices for each issue, or do you drag one email and allow for the possible miscategorization of the Ticket portion of the email?

 

Thanks for the tips.

Hi, despite the duplication - we do it for each one - disk space is cheap !!

Yes, disc space is cheap. But users’ time is not. :0) So...

1. Do you find the process for multiple entry difficult for your users to pick up and maintain clarity throughout handling of all Tickets? I assume that for the sake of the customer all Tickets stemming from one email will be responded to in one email or phone call. After all, the customers generally see issues as being all part of the same problem.

 

2. Also, since for each Ticket’s activity the description contains lots of information not related to that Ticket, do you find that this causes confusion or slows down any portion of your process?

 

Thanks for the Brainstorm!

1) No, after training and usage they soon get used to it.

2) Haven't found that to be the case - again, just comes down to training etc.