How best to use Companies & Customers for End User Support

[cairey]

Hi all,

Firstly, I'm new to OTRS and the forum but have tried searching for info to help to no avail so far - apologies therefore if this post has been addressed before. To be clear, I am also not a developer, but do have access to LAMP developer resources internally, if required.

We are a B2B solutions & service provider, and as such deliver 24x7 remote end user technical support on behalf of a high number of customer venues across the globe. I am very keen on replacing our existing in-house ticketing system with one based as much as possible on OTRS. I have installed V3.1.11 on Windows and on Linux and have customised it to suit our needs (additional dynamic fields, queues, agents, groups, roles, auto-responders, services and SLAs), all of which works fantastically well. However, its probably a really simple implementation decision that is holding me back.

Scenario:
Our "customers" (companies) have "venues" (unique address & site name). The "venues" are occupied by "end users" (who are a transient public audience). Our "customers" also have "estate managers" who need to oversee incidents attributed to their estate of "venues". Presently, end users call or email in with a support issue, and may call in from multiple unrelated "venues" over time. The incidents are queued (one queue for phone, one for email) and handled by internal Agents. The tickets record end user detail and are associated with the "venue". An "estate manager" can login but can then only have visibility of his/her estate of venues and associated tickets. I'm comfortable with most of that, but its the segmentation by venue & estate that I'm not sure how best to deploy.

Question:
How do I make the OTRS customer ("end user") independent of a company venue in terms of repeat calls whilst linking that back to the venue for reporting and escalation purposes with our customers?I'm trying to use the standard fields of customer_id & customer_user_id if possible. Is it as simple as amending the ticket input method to "break" the automatic link and have this as a user input? If so what are the implications to reporting and visibility? How do I then best limit visibility for the "estate managers"?

Hope that makes sense, and that its an inappropriate post! Apologies if not.

Chris

[crythias]

Summary:
"customer" = company that has a/multiple "venue" (one customer to many venues)
"end user" = "otrs customer" that calls from a "venue" (many to many)
"estate manager" = member of "customer" (many estate managers to one customer), manager of "venue" (one estate manager to many venues)

First blush guess would be that the venue would be either a Service, CustomerID, or DynamicField
It would be "easiest" if the venue was a CustomerID, but that won't work because an end user can be of a random venue.
To mitigate that CAN be to create a new end user entity for each Customer ID. This isn't necessarily out of the question unless it's just going to be unwieldy to do this.
Then, the estate manager needs only to have "CustomerIDs" for each venue, and only estate managers can see "Company Tickets". See this.

After that comes a big mess of customergroups, whether you want the estate managers to manage queues on the admin side, or ACLs based upon service or DynamicFields.

(Summary: If you could treat the estate managers like department heads, this is easy. However, it's a bit more problematic if the "employees"/"end users" roam departments.)

[cairey]

Hi Crythias!

Thanks for your really quick response. Really appreciated....

In one respect, I'm glad that my question was not a one word answer, and suspected that our requirement may present a number of approaches to resolution. I will "mull over" your suggestions and work out a plan based on your input. If ok, I'll "present" my suggested approach back on here, for any further constructive criticism, if you're available.

Once again, really appreciate your input.

Cheers

Chris