Key accounts

[m.vandun]

Hi,

We have a few customers where the customer is supported by a key engineer. Is there a way to automatically assign / CC a key account engineer to a specific customer?

Kind regards,

Mark

[Steven Boardman]

Hi @m.vandun

Thanks for your post.

I hope i am assuming correctly that your customer are external organisations?  if so maybe some of this will help? 

Against an organisation record you can add custom fields, so possibly you could add if the org is a Key Account (maybe a Yes / No) or more options if you need them.  You may also then have a field which contains the support engineer for that account - something �like below.

 

Once you hold this information you can evaluate it using the Business Process Designer (BPM) and the Requests > Get Information > Organisation Details Node, before a Decision node at the start of your business processes which handle assignment and or the use of the Connections nodes. 

More info on the BPM here:  https://wiki.hornbill.com/index.php/Business_Process_Workflow

In the BPM you could have something like below

1. Use the Request > Get Information > Org details node

2. Add a Decision Node, and use a Custom Expression to evaluate the content of the custom field which you added above - Something like Custom x (Key Account) = No Then Assign as Usual, and if Custom x (Key Account) = Yes then branch to another Decision node

3. If you branch to another decision node, you can evaluate the other custom field which will contain the support engineers name, and then have an assignment node off each decision which will assign the request to the named engineer, if it is one of their accounts. 

In the example below i have 3 engineers who look after key accounts so i have 3 outcomes, but you could have less or more as needed.   By having or evaluating these org attributes, i don't need to evaluate the name of every org to see if and who should support them.

I hope that helps and is one potential route to consider?

As an aside you could also if you wanted too, use the Requests Connections > Add Connection Node to add the Support Engineer automatically to a Request, if you didn't want them to own the request - using the same sort of logic above. 

You could then insert a Request Connections > Email Connections node after key milestones in your business process, and this could automatically keep the added Support Engineer informed via email of the progress of the request for their Key Accounts 

Again more info here on the Request Connection options in the BPM: https://wiki.hornbill.com/index.php/Business_Process_Workflow

Hope this helps

Steve

 

 

 

 

 

 

[m.vandun]

Hi @steven boardman

Thanks for your reply. I've tried your suggestion and it seems to work properly. The only downside is the limitation of custom fields you can create for the organisations. I had to sacrifice a field to add a key engineer. Are there any plans to expand the amount of custom fields for an organisation?

Kind regards,

Mark

[Ryan]

I have asked the team if there are plans to increase the number of custom fields for an organisation. 

Should have a response for you soon.

Ryan

[Gerry]

Hi Mark,

There is no immediate plan to expand the number of custom fields in the organisation entity, primarily because we are not really aware of any use cases that would require so many fields against an organisation record.  We alway aim to keep our data schema efficient to ensure that performance (which is directly linked to MariaDB memory availability), and the more columns in a table definition, the more memory is used when working with that table. 

Could you please expand on your requirements in a little more detail, I would like to understand exactly what you are trying to achieve so I can feed that back into our product development process, we are always happy to take ideas/requirements on board and accommodate them if they contribute to the greater good for our customers. 

Gerry

[m.vandun]

Hi Gerry,

We currently have the following fields in use:

Escallatienummer : This number is used to forward calls when a phone line is dead (we are a telecom company).
Onderhoudscontract: Service level
Services : These are all the services a customer has with us. Possible we can remove this when there is a better way to see this per customer.
Notes : All kinds of extra notes
Container IP : Server IP
Containernummer: Server name
Inloggegevens: Login details
Adviseur: Account manager
Automatiseerder: External IT company
Key Support Engineer: Our new field for our key engineers per customer.

Extra info i would like to add for example are:
* Install date
* Customer number
* Head quarters or subsidaries

Kind regards,

Mark

[Gerry]

Hi Mark,

Thanks for the info, ok it all makes sense now. It seems you are supporting external customers and are wanting to use the organisation records custom fields to hold key information about the support contract/parameters you have with each organisation.  The problem with that approach IMHO is you will never quite have enough custom fields, things will change - I know this because this is how we first tried to use the Organisations in Hornbill and it just did not work.   The Organisation entity is really only designed to hold information about an Organisation, if it goes beyond that you end up with a messy data model that will ultimately lead to a clunky sub-optimal workflow for your users. 

There are a couple of much better options that might help you out a lot here. 

• One option is Customer Manager is an application we make that is designed to assist with external B2B customer support and falls more into the CRM category than the IT Support category. In its short term roadmap for Customer Manager  we are looking to add two relevant concepts, which are Contracts and Supported Items.  Contracts will allow you to store information about a specific contract, start date, end date, value, primary contact, supported contacts, contact roles and so on.  And a Contract can contain one or more Supported Items. A Supported Item can contain things like make/model/serial number/product name/version etc... basically the goal will allow any item that one would support to be defined. 
• Another option would be to use Service Manager Assets which I believe (but please don;t hold me to it because I am not 100% sure) there is a roadmap item to make it possible to associate Assets to a Contact. This really is geared towards outsourced IT support where the service provider is an outsourced IT function. I would say Option 1 is a more natural fit 

Perhaps someone from the SM product team will be able to put some clarification around Option 2 which may work for you. 

I will ask one of our developers to look at what are the practical restrictions on expanding the maximum number of custom fields and see what they can come up with. I can see more fields will help you here but I am not so sure its a good idea to try to manage your contracts data like this


Gerry