{"id":21533,"date":"2026-11-12T19:20:00","date_gmt":"2026-11-12T18:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=21533"},"modified":"2026-10-25T22:43:27","modified_gmt":"2026-10-25T21:43:27","slug":"support-as-a-hidden-cost-self-service-tickets-or-paid-onboarding","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/saas-internet-earning\/support-as-a-hidden-cost-self-service-tickets-or-paid-onboarding\/","title":{"rendered":"Support as a hidden cost: self-service, tickets or paid onboarding?"},"content":{"rendered":"

Online software can have low server costs and still require substantial support. Setting up accounts, importing data and answering questions takes paid time. Planning therefore needs both cost per customer and the hours the team can actually provide.<\/p>\n

\"Ticket
Editorial comparison \u00b7 hypothetical inputs, not provider prices<\/figcaption><\/figure>\n

Three different services<\/h2>\n

Self-service means help without individual handling by the team, such as a clear guide or an invoice-download function. Depending on configuration, Stripe\u2019s customer portal provides invoice and payment features of this kind. [1<\/a>] A portal does not fix an unclear error message in the product itself.<\/p>\n

A ticket is a recorded support request, such as a failed import. Paid onboarding instead provides agreed help at the start: setup, training or data transfer, for example. The offer states the included tasks and when the work is complete. Unlimited support after setup is an additional service.<\/p>\n

Product improvements before more help articles<\/h2>\n

Ten identical import questions may mean that matching file columns to data fields is unclear. A preview showing that mapping could prevent more questions than a longer guide. Problems affecting many customers and creating avoidable work are useful starting points for investigation.<\/p>\n

A click on a help page does not prove that a request was avoided. Better evidence includes whether the task succeeds afterwards and whether the same problem still leads to later contact. Fewer requests alongside more cancellations would not show convincing success.<\/p>\n

Capacity with realistic working hours<\/h2>\n

All money figures below are hypothetical euros excluding VAT. Five hundred active customers averaging 0.4 tickets each produce 200 monthly tickets. If self-service actually prevents 20%, 160 remain. At fifteen minutes each, these require forty hours. Adding 10% for follow-up questions gives forty-four hours. The 20% is an assumption, not measured effectiveness.<\/p>\n

One person with eighty paid monthly hours and 70% allocated to tickets has fifty-six hours for handling them. Against forty-four required hours, twelve remain spare. At \u20ac30 per paid hour plus \u20ac50 for support software, the planned team costs \u20ac2,450 monthly: 80 \u00d7 30 + 50. That is \u20ac4.90 per customer.<\/p>\n

All eighty hours are paid, not only the fifty-six assigned to tickets. The rest may include documentation and other work. Fewer tickets therefore do not automatically reduce the cost of an unchanged team. The calculator separates required headcount from the cost of people already assigned; setup or maintenance outside those hours needs additional costing.<\/p>\n

Peaks change the promise<\/h2>\n

Forty-four handling hours per month do not guarantee a reply within one day. A faulty software release may trigger many simultaneous requests. Opening hours, holidays, sickness and urgent cases also determine reply times.<\/p>\n

A support promise states contact channels, available hours and priorities. A security incident or failed import may need faster and different handling than a design suggestion. Spare hours in a monthly calculation do not mean that a person is available at night or at weekends.<\/p>\n

Paid onboarding without hidden product gaps<\/h2>\n

An example setup takes two hours at an internal cost of \u20ac40 per hour, initially costing \u20ac80. At a price of \u20ac149, \u20ac69 remains for preparation, payment fees, other expenses and profit. The \u20ac69 is not yet profit. Adding unlimited data migration can quickly make the price insufficient for the actual work.<\/p>\n

Custom changes need their own scope and price. Using early business customers as an example, Y Combinator describes the risk of turning a reusable software product into separate consulting projects. [2<\/a>] A fixed list of setup tasks makes offers comparable. Repeated steps can also become better guides or product functions.<\/p>\n

A combined experiment<\/h2>\n

A possible four-week test records each request\u2019s reason, handling minutes and follow-up work. It also records whether a predefined task succeeds, such as the first data import. Comparable customer groups receive either improved help or the previous process; random allocation can reduce differences between groups. Four weeks alone does not guarantee reliable evidence, especially with few cases. The scope and completion of paid setup are recorded separately.<\/p>\n

Evaluation considers working time, costs and completed tasks together. Fewer tickets help when tasks still succeed. More setup revenue helps only if the extra work remains affordable. Measured monthly support cost per customer can then be entered into the profitability calculator.<\/p>\n

\n

Related tools<\/h2>\n