¿Estoy cobrando demasiado a mi cliente por mi acuerdo de nivel de servicio (SLA)?

Question

Así que he conseguido un proyecto de 6 cifras para un sistema de gestión de empleados que gestionará sus empleados para 4 de sus empresas. Este sistema de gestión de empleados integrará una solución de hardware biométrico en estaciones informáticas que se comunican con iPads (para los gerentes/recepcionistas de cada empresa) todo ello conectado a un servidor basado en la nube. El proyecto durará unos 3 meses, y el cliente tiene derecho a todos los pequeños e intrincados cambios de software que quiera durante el primer año, después de lo cual el servicio cuesta 8.000 libras al año para mantener la solución que voy a implementar.

El problema: Todo eso está muy bien, pero me cuesta explicarles que les cobraré 8.000 al año para que sigan funcionando después del primer año gratis.

Aquí están mis razones para cobrar eso:

Dos razones principales

• Me Blaaaady trabajado tan duro en ese primer año libre la aplicación de todos los cambios de características que de repente se dan cuenta de que requieren nuevos rápido para implementar, pequeñas actualizaciones de características a veces grandes en la aplicación de software actual que siento que necesito para hacer mi dinero de vuelta en el segundo y tercer año a causa de las horas adicionales puestas en después de la finalización del proyecto.
• Apple, pase lo que pase, tendrá actualizaciones anuales del sistema operativo iOS para todos los dispositivos, y lo mismo ocurrirá con MAC OS X. Así que estas aplicaciones tendrán que ser actualizadas independientemente anualmente de todos modos.
• Copias de seguridad del servidor, y de las bases de datos. <- esto suena muy tonto cuando le digo al cliente esto.

Pequeñas razones adicionales pero que no necesariamente pesan de manera significativa en el coste del SLA

• Proporciono al cliente un acceso directo a mí, un servicio telefónico 24 horas al día, 7 días a la semana, a diferencia de los correos electrónicos o cualquier otro método de comunicación o de tener que pasar por mi recepcionista, eso lo reservo para los proyectos más pequeños. A mi cliente le encanta esto y seguro que lo utiliza siempre que es posible, enviándome muchos mensajes cada vez que necesita una nueva función, o cuando necesita cambiar algo en el back-end.
• Los costes del servidor, es una cantidad tan nominal que podría pagarlo de mi bolsillo ya que sólo cuesta unos 40€ al mes, no es que vaya a asumir el coste ;)
• Flexibilidad: ofrecemos una actitud de servicio sin problemas.

Todo se ejecuta en mi lado, si quería, sólo tengo que redirigir el servidor en otro lugar y todas las aplicaciones dejarán de existir para los otros proyectos que he trabajado con este cliente.

Pero en lo que respecta a esto, eso es todo. Mi cliente me pregunta qué pasará después del primer año gratuito si no se requieren actualizaciones en el segundo año, ¿tendrá que seguir pagando los 8.000? Es una buena pregunta, pero ese no es el punto, le he dicho que estos son los costos de funcionamiento para la gestión del servicio que estoy proporcionando.

¿Podría alguien ayudarme a esbozar otras cosas importantes que posiblemente estoy pasando por alto en este acuerdo SLA que podría ayudar a justificar el coste? Me parece que el aspecto del desarrollo de la aplicación es más que suficiente para justificar ese coste, ya que algunas empresas cobran entre 25 y 30 mil libras esterlinas en concepto de actualizaciones y revisiones de la aplicación, mientras que él es capaz de venir a verme en cualquier momento del año y enviarme una nueva lista de características requeridas sin ninguna molestia.

Answer 1

En el caso de los acuerdos SLA, debería poder realizar una estimación basada en las tareas fijas y en el trabajo medio previsto para las mejoras/los errores.

Para tareas fijas:

• Los costes del servidor. Si estás pagando por esto súmalo y añádelo al resto del total. No lo absorba sin más.
• Esbozar un plan de actualización. Por ejemplo, actualizar todo el software del servidor mensualmente. Todo el software de los dispositivos mensualmente. Aunque acabe siendo algo trivial, prevea que sea una tarea de X horas que planifique y sume para el año. Esto hace que, como mínimo, mandes organizarte.
• Copias de seguridad y base de datos: si es realmente necesario y lo haces en un horario, cuenta. Describa el programa. "Copia de seguridad mensual dirigida del código y de la base de datos. Plan de recuperación en caso de fallo". Si está automatizado, probablemente una verificación+mantenimiento menor. Promedie las horas por mes aquí y sume. Aplique la tarifa por hora.

Para actualizaciones/correcciones:

• Por lo general, una combinación de la media del año pasado y las expectativas para el año que viene, si es que va a ser dramáticamente más lento. ¿No se han necesitado actualizaciones en la segunda mitad del primer año libre? Tendrá que calibrar esto y asumir un cierto mínimo aquí. Si planificas un arreglo para el año y terminas con 6, te estás comiendo el costo. Es mejor tener un mínimo previsto de 5, y está bien comerse un par si sucede. También te pagan por estar disponible para esos casos, cuando de otra manera podrías dedicar tu tiempo exclusivamente a otro cliente. Es una especie de anticipo. Calcula las horas y aplica la tarifa por hora.
• Asistencia 24 horas al día, 7 días a la semana. Has dicho que era para un cliente pequeño, así que probablemente sea mínimo. Sin embargo, lo anotaría como parte del total que estás tratando de justificar. Estás proporcionando algo grande aquí.
• Flexibilidad - A algunas empresas les gusta que los SLA se expresen como "para problemas de tamaño moderado: se acusará recibo de todas las solicitudes de problemas por correo electrónico en un plazo de 4 horas, se propondrá una solución en un plazo de 8 horas y se desplegará la solución en un plazo de 48 horas", "para problemas importantes, en un plazo de 4 días", etc. Son formas de cuantificar el servicio SLA, y que generalmente se solucionan las cosas rápido. Esto se paga, ya que la versión más barata sería el plazo de 1-2 semanas, etc.

Para la posibilidad de que no se necesiten correcciones, se sigue aplicando el SLA. Se le paga por mantener una posible disponibilidad, con una respuesta rápida y fiable. Es una garantía para el cliente de que si las cosas van mal, se resolverán. Es un contrato de 1 año, y quizás el año siguiente sería una estimación reducida basada en la menor expectativa de necesidades.

Answer 2

No creo que sean razones pequeñas, especialmente la primera. Así es como yo lo explicaría:

"Tengo que reservar un tiempo en mi agenda para estar disponible si tienen preguntas o problemas. Ese tiempo cuesta dinero. Si no reservo ese tiempo y usted tiene un problema, de repente tengo que dejar de lado todo el resto de mi trabajo, lo que no es justo para esos otros clientes. Tengo que hacerlo independientemente de que lo uses o no".

Además, no creo que parezca una tontería lo de las copias de seguridad del servidor y las bases de datos. Ten en cuenta que no se trata sólo de las copias de seguridad, sino también de la recuperación si hay un problema. Eso llevará su tiempo, y ocurrirá en el peor momento posible. Su tarifa tiene que tener en cuenta esa posibilidad. Y seamos sinceros, no se trata sólo de un proceso automatizado para ejecutar la copia de seguridad. También hay que verificar de vez en cuando que las copias de seguridad siguen realizándose (¿cuántas veces hemos visto que algo se rompe?)

Answer 3

He aquí un enfoque diferente. En lugar de 8.000 al año, ofrece al cliente tu tiempo disponible en trozos más pequeños:

8k / año 750 / mes 200 / siete días hábiles 75 / por CADA incidente (con alguna limitación!!!)

El cliente tendrá que espabilarse rápidamente. Las copias de seguridad y el mantenimiento no son nada triviales, y tal vez establezcas un precio aparte solo por eso.