¿Cómo facturas tus servicios web?

Question

Al desarrollar un nuevo servicio web, no he podido encontrar mucha información sobre cómo las empresas facturan sus servicios web.

¿Facturen por solicitud o solo ciertas solicitudes, es decir, GET o POST?

-serían rastreados a nivel de aplicación o servidor?

¿Facturen por ancho de banda?

-de nuevo ¿cómo esta puede seguir en una base por usuario

¿Debo pagar una suscripción a simplemente tener acceso?

-esto es suponiendo que solo se les concede una clave de API después de que se haya realizado el pago.

¿Una combinación de las anteriores o de otras opciones?

Gracias por su ayuda.

Answer 1

Como todas las cosas en una economía de mercado, el precio, pero también la inconveniencia (o conveniencia) y el riesgo asociado con el pago real (independientemente del monto) es una función de lo único y genial y valorado su servicio o producto es.

Por lo tanto, es imposible responder a la pregunta, pero en términos muy genéricos, es decir, en forma de sugerencias. Usted modelo de facturación real puede basar en uno o varios de los siguientes factura

• para una cuota de instalación de una sola vez
• proyecto de ley sobre una base de suscripción (es decir, por un período definido, con importes máximos definidos explícitamente de uso)
• factura por mantenimiento
• factura por acto, es decir, una cierta cantidad (posiblemente en una lista de precios unitarios decrecientes). Dichos actos se deben contar en el nivel del servidor, (El lado del cliente puede incluir algún tipo de auditoría/monitoreo/registro, pero el servidor debe ser la fuente autorizada de información)
• factura por volumen (por ejemplo número de MBytes transferidos, etc.), esto es aplicable a los servicios donde hay una gran variación en el volumen de información producida por cada "acto".

En general, el precio y la modalidad de la contabilidad deben parecer justos, para ambas partes, particularmente para el comprador, y normalmente, cuanto más simple, mejor. El precio no debe ser necesariamente bajo, siempre que pueda demostrar que el servicio prestado es efectivamente valioso, y que usted invirtió y asumió el riesgo de introducir el servicio, o que los gastos continuos asociados con la ejecución del servicio son evidentes.

Answer 2

Supongo que Depende ™ de lo que hace el servicio. En términos generales, yo diría que debes facturar cuando proporciones algún valor intrínseco; cómo determinas qué es ese criterio de facturación es bastante específico del dominio. Puede haber alguna propiedad del servicio provisto que le permita determinar cuánto facturar.

Por ejemplo, supongamos que tiene un servicio web que realiza un cálculo. Puede decidir que por cada cálculo exitoso que realice, se le cobrará una tarifa fija, digamos $0.01, pero se les permitirá a los usuarios descontar si hay un problema de validación, como una solicitud no válida. Alternativamente, si esos cálculos son vagamente de larga duración, es posible que tenga un modelo de carga basado en algún tipo de métrica de tiempo de CPU.

Su punto sobre las suscripciones es bueno, y esta es un área en la que podría beneficiarse al permitir un par de modelos comerciales; uno para atender a los usuarios que podrían realizar muchas solicitudes por mes, en cuyo caso una suscripción fija podría tener sentido, y una para atender a los usuarios que hacen algunas solicitudes ad-hoc. En el último caso, por supuesto, si usted solo atrae a esos clientes, entonces no obtendrá un buen retorno de la inversión. Algún tipo de término medio, mediante el cual tiene una pequeña suscripción, pero luego permite que los clientes compren un "bloque" o un "paquete" de solicitudes en la parte superior sin incurrir en costos de procesamiento adicionales, podría funcionar.

Answer 3

Muchos de los que he visto facturan por tiempo, como mensualmente o anualmente. Algunos le permiten pagar por mes, algunos requieren una parte (o la totalidad) de la tarifa por adelantado. El acceso puede estar restringido emitiendo un certificado de seguridad para el servicio web que expira cuando expira la cuenta del cliente, o posiblemente haciendo que envíen un ID de cliente y permitiendo que el servidor compruebe si se permite que la ID del cliente tenga una respuesta (pero está abierto a personas robando la identificación del cliente de otra persona;)).

Supongo que si tiene un servicio que envía y recibe grandes cantidades de datos, podría tener sentido facturar por solicitud de servicio, pero la facturación podría ser más complicada. ¿Es probable que los clientes realicen docenas de solicitudes por día o solo unas pocas? ¿Cuánto facturar por transacción? $ 100? $ 0.01? Todo eso dependería de la naturaleza del servicio. Si desea seguir esa ruta, probablemente deba asegurarse de que a los clientes solo se les facturen las solicitudes que se responden con éxito (No me gustaría que se me facture aunque mi aplicación cliente no haya recibido el mensaje completo del servicio web de tu servidor).

Answer 4

Por solicitud o como suscripción, y sí, el ancho de banda puede ser una variable que se usa para establecer la tarifa. Depende del valor de vincular al cliente o de tener una miríada de clientes que lo usan de manera flexible. No hay una respuesta correcta a la pregunta que se ajusta a todos o incluso a la mayoría de los casos.

Si miro los servicios que he hecho en el pasado, el modelo de suscripción sería el mejor modelo para usar. En algún momento, un tick de $ por solicitud parece ser el mejor enfoque, pero nunca antes había tenido un servicio configurado de esa manera.

Answer 5

La mayoría de los servicios web que saben de forma gratuita para dos cosas:

• volumen de "uso". En general, se otorga acceso "libre" a volúmenes bajos (es decir, menos de X hits/hora de una combinación determinada de cuentas de direcciones IP). Esto es similar a, por ejemplo, twitter, que le da 150 hits/hora a su servicio, ya sea desde su nombre de usuario, o IP única o combinación de los dos (por lo que no abusar de él cambiando las direcciones IP con frecuencia). Si desea un mayor volumen, pague por ese acceso y generalmente se lo asigna por cuenta (en el caso de twitters puede obtener una cuenta de desarrollador [gratis] que le da 20K o más visitas por hora)
• Profundidad de detalles, acceso a caracteristicas. De nuevo, las cuentas gratuitas obtienen una cantidad mínima de acceso, pero no tienen acceso a más datos ni a funciones más avanzadas (filtrado, etc.). Muchos de los servicios de google funcionan de esta manera, si todos tienen acceso básico, pero si desea capacidades más refinadas (mayor búsqueda, más datos, resultados más rápidos), debe comprar un código de cuenta con la funcionalidad correspondiente.

No he visto realmente o participado en ningún proyecto con pago por rendimiento, o pago por hit/modelos de acceso ya que son muy difíciles de facturar de manera confiable y muy difícil de explicar a los clientes, incluso si usa rangos escalonados o con bandas. ¿Cómo le dice a sus clientes cuántas visitas han utilizado, especialmente en un sistema distribuido, con redundancia fallida, etc. Si tuviera que pagar $ 0.01 centavos por acceso, me gustaría saber exactamente cómo se mide, y qué hace la compañía? tenía en su lugar para controlar el acceso, y qué tan precisa era su supervisión, etc.

No es imposible, y definitivamente se puede hacer, y puede funcionar bien en grandes escenarios a granel.

Answer 6

Estoy de acuerdo con lo que ha dicho Rob y Des. Una cosa para recordar es que una suscripción es un concepto realmente simple con el que todo el mundo está acostumbrado y cómodo (si le das el precio correcto). Si desea abarcar a un público amplio, mire cómo lo hacen los proveedores de pago: tienen métodos de pago ligeramente diferentes según la cantidad de transacciones que realice por año. Habrá una suscripción fija más un cargo por transacción y ambos varían según el número de transacciones. Este es el más flexible, pero depende si tiene sentido para su negocio.