Hi,

I'm also looking into solving the "customer's support contract is in
trouble => reduce / cut his access to OTRS" problem, *without* changing
code shipped with OTRS (no HTML mods, no PL script tweaks, etc.) and in a
manner that can be automated (integrated with our contract management
system)

= My conclusions so far =

- Disabling a customer account is excessive as a 1st response to a problem
with his support contract. It would result in him being unable to login and
OTRS just saying "Login failed! Your user name or password was entered
incorrectly." without an option to transmit additional info such as "...
your account has been disabled because ...". There's another problem with
disabling a customer account and that's OTRS leaving his existing sessions
operational. Thus, the customer can still interact with OTRS for quite some
time after his account was disabled if he had an active session before
disabling occurred. It's non-obvious how session-killing-on-account-disable
can happen because the provided "otrs.DeleteSessionIDs.pl" can't delete
specific user session(s). It can either delete all active sessions or only
those that have expired. I haven't yet investigated what happens if an
account is disabled and the customer responds to an issue via email. That
may yield other surprises.

- Ideally, when a problem with his support contract occurs, the customer
would have his access changed to a "read-only" mode until the problem is
fixed. The only way I've found to do that is to change his permissions in
"Customers <-> Groups" from "rw" to "ro". The trouble with this approach is
that it requires manual intervention and remembering exactly for which
groups you downgraded the rights (on some groups the customer may have
permanent "ro" rights so when the support contract problem is fixed you
need to know for which groups the access should be switched back to "rw"
and for which groups it should be left to "ro").

- There is no mechanism provisioned in OTRS to show a message to certain
customers in the customer interface. Something like "There is a problem
with your support contract!!!". Ideally, something like this would manifest
itself in about the same manner as messages for admins do when they show up
in the admin interface announcing "do not use root account for operational
work" or "scheduler is not running".

- There is no way to add dynamic fields to anything except tickets and
articles. So you can't easily mark a customer account as being "in trouble"
unless you use some convention and write something in his "Comment" field,
which would be a fragile solution, or if you use a different/additional
customer backend which is way more complicated than what I'm confident to
explore at this time. Even if you do mark a customer account as being "in
trouble", OTRS doesn't make it in any way easier for you to reduce his
access to the system.

= Solution I'm playing with =

1. Create a queue that all customers can access, dedicated to handling
customer support contract problems.

2. When such a problem occurs for customer X, automatically post a ticket
in this queue and assign it to customer X (via OTRS web services, generic
interface, etc.) and, in the OTRS database, "group_customer_user" table,
set permission_value to 0 for customer X (by user_id) where permission_key
is "rw", except for the group related to the queue from step 1. It is
possible that an entry in this table doesn't exist for "ro" permissions
(depending on how the "rw" permission was created from UI). If it doesn't
exist, create it. OTRS doesn't set permission_value to 0, it just deletes
the row. So by looking for 0 on that column when it comes to restore
customer X's access rights, you'll know you'll find entries modified by
this mechanism.

3. From now on, customer X has read-only access to all his previous tickets
and he can only interact with the tickets related to support contract
troubles.

4. When the support contract trouble is solved, update the table from step
2 by setting permission_value to 1 where it is 0 for the targeted customer.

There are more issues to take under consideration (I haven't finished
elaborating the whole solution) such as:

- How will agents know, just by working normally, that a ticket belongs to
a customer who's support contract is in trouble. A possible solution would
be to add a dynamic field to tickets that is automatically updated at step
2 for all non-closed tickets.

I hope I was clear and if you or anyone else has some feedback I would
warmly welcome it.

/bogdan

On Thu, Oct 11, 2012 at 10:21 AM, Adrià García-Alzórriz <
adria.garcia-alzor...@adam.es> wrote:

> Hi there,
>
> I'm interested in adding more fields in Customer details. It can be
> possible with OTRS? I think that Dynamic Fields are available only in
> Tickets or Articles.
>
> I try to keep helpdesk offers support if a customer didn't pay his
> previous bill, so a *visible* message (such pop-up, custom HTML) would
> be great.
>
> Disabling customers or add text comments into customer's profile are
> insufficient for us beacause in first case the agent can't find the
> customer when opens a phone ticket; in the second one, if customer
> creates a ticket via mail it can be difficult to notice these kind of
> administrative messages.
>
> Do you have any ideas?
> Many thanks!
>
> --
> Adrià García-Alzórriz <adria.garcia-alzor...@adam.es>
>
> ---------------------------------------------------------------------
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Reply via email to