10/15/2026 - Articles
The project ends, but customer support continues. Here’s how to organize support and maintenance after project completion—with a clear handover, sufficient capacity, and billing that clearly documents the services you provide.
Establish a dedicated service framework: The project delivers a defined outcome; ongoing support needs its own responsibilities and service agreements.
Use tickets for individual requests: A ticket documents a question, incident, or requirement. It can belong to a service or a project.
Plan the handover before project completion: Clarify outstanding issues, knowledge transfer, request channels, and responsibilities before the project team moves on.
Separate capacity from the support budget: Available staff ensure requests can be handled; the contract defines the scope of services and billing.
Connect your processes: BCS brings Ticketing & Services together with planning, time tracking, and business management functions.
Friday: The customer accepts the new portal. The development project is now complete.
Monday: A user needs help logging in.
Tuesday: The first scheduled maintenance takes place.
Wednesday: A request for an additional interface comes in. By now, the project team is already working on its next assignment. Who takes over?
Support and maintenance after project completion need a dedicated organizational framework with clear responsibilities. Support can begin immediately upon acceptance or follow an agreed stabilization phase during which the project team helps manage the transition. An agreed service start date gives both sides clarity: The customer knows whom to contact, and staff know which services they are responsible for.
Support, maintenance, and operations serve different purposes.
Support helps users with questions and incidents.
Maintenance covers agreed measures to maintain a solution and keep it working.
Operations may include regular checks and keeping the solution available.
The services the provider actually delivers depend on the specific agreement. A maintenance contract therefore does not automatically cover every support request or subsequent enhancement.
A project, a service, and a ticket also serve different purposes. A project delivers a defined outcome, a service provides the framework for ongoing support, and a ticket records an individual request. Tickets can belong to either a project or a service.
| Framework | Purpose | Example |
|---|---|---|
| Project | Deliver a defined outcome with dedicated planning and a formal close. | Implement a customer portal. |
| Service | Provide ongoing support for an existing solution. | Maintain a portal and support its users. |
| Ticket | Handle a specific request within a project or service. | Investigate a login issue or record a change request. |
The same logic applies after a website relaunch or the commissioning of a facility. The scope and processes differ, but assigning work to the right framework remains important. Our article What Is a Project? explores the distinction between projects and day-to-day operations in more detail.
Start planning the handover before the final project meeting. The project manager, service manager, and account manager should work together to document the following outcomes.
Document what has been delivered, customer acceptance, and known limitations. Assign someone responsible for each outstanding issue.
Distinguish between outstanding project work, ongoing support, and additional requests. A request does not become a support service simply because it is reported later.
Identify the systems, locations, or products covered. Clarify service hours, priorities, response targets, and escalation paths.
Specify who on the customer’s side approves additional services. Also describe which services your offering excludes.
Appoint a service manager, the staff responsible for handling requests, and a backup.
Define when the team should involve the former project manager or a specialist. This saves the customer from having to work out your internal responsibilities when an incident occurs.
Hand over current documentation, configurations, version details, contacts, and key decisions. Check the required permissions and manage access credentials through the designated secure process.
Have the service team work through a typical request using this information. This reveals knowledge gaps more effectively than a full handover folder.
Tell the customer where to submit requests and what information you need.
Define internal rules for assigning requests, updating statuses, and communicating. Give the team a simple rule for urgent cases and requests outside the agreed scope.
Reserve capacity for ongoing support and specify where staff should record their time.
Review service types, billing rules, and approvals with the person responsible for commercial management. Schedule an initial review after the service starts.
Can an employee who was not involved in the original project identify the solution being supported, find the relevant documentation, and determine the next step? If not, close the gap before the service starts.
A good ticket starts by answering five questions:
Who is reporting the issue or request?
Which solution does it concern?
What exactly is happening?
What impact does the problem have?
Who is responsible for the next step?
Add the time of the incident, the affected version, and helpful files where relevant to the case.
A blocked business process needs a different response than a question about how something is displayed. Define clear criteria and agree on an escalation path. “The customer has followed up for the third time” should not be your only criterion for setting priorities.
Response time is the time allowed for an agreed reply or initial qualified action. Resolution time is the time taken to resolve the issue. Define the starting point, service hours, and any pauses in the service level agreement (SLA), rather than treating these two timeframes as equivalent.
Back to the portal example: The support team investigates the login issue as part of the agreed service. A request for a new interface, however, first requires an effort estimate and approval. Your team records the request in a ticket and starts a new project if the scope warrants it. A ticket alone does not authorize every requested change.
Multiple small requests also deserve a joint review. If they concern the same change, group them into a planned work package. This prevents the service scope from expanding unnoticed.
BCS in practice: Staff record communication, priority, responsibility, and time spent directly on the ticket. BCS can link requirements to project tasks and user stories. The Ticketing & Services feature page explains these connections. The blog article Ticket Is Trump: Ticketing Systems in Support covers the basics of organizing tickets.
Customers are assigned to the relevant projects. This allows them to view or create tickets exactly where they belong. At the same time, internal staff can collaborate across projects and group companies when they work with the same customers or on the same technical topics. […]
Of course, the success of a ticketing system also depends on consistently following processes and documenting information properly. BCS provides the right structure for this: Tickets, responsibilities, history, and customer relationships can all be tracked centrally. This helps us in our day-to-day work and ensures that support requests do not disappear into individual inboxes or personal files.
“Someone will fit it in.” That sounds straightforward—until an urgent support request collides with a full project schedule. Ongoing support therefore needs a dedicated place in capacity planning. Past support effort provides an initial guide. You also need to consider
Service hours
Required skills
Absences
Workload from parallel projects
Recurring checks and typical user questions create a baseline workload. Scheduled maintenance requires additional capacity at specific times. The team needs spare capacity and reliable backup coverage for unplanned incidents. Once the service starts, comparing these planning assumptions with actual time entries shows whether they reflect day-to-day work.
Example calculation: After accounting for absences and internal tasks, a team has 120 hours available per week. It allocates 25 hours to ongoing support and another 15 hours to a maintenance window. This initially leaves 80 hours for project work that week. If the team also reserves capacity for unplanned incidents, that figure decreases accordingly. A financial support budget does not create additional working time.
BCS accounts for recurring service effort through baseline workloads and temporary workloads through capacity allocations. Capacity allocations also help prevent overbooking. This incorporates ongoing support into the planning of new projects and shows managers which capacity is already committed to service work.
Learn more about resource management with BCS. Our article on resource planning in project management explains how to systematically compare demand and availability.
When assigning tickets, we often schedule work to begin at a future date so that the planned effort is immediately reflected in resource utilization forecasts. […] Our operations contracts require close coordination and collaboration with our customers. […] Customers can view the project overview to stay informed about the current status. They can also read our team’s ticket comments and add their own to provide us with the information we need. Customers always have an overview of their available support budget, which adds transparency.
The agreement with the customer determines how you bill for services. Record time even for services covered by a flat fee: You need this data to assess the actual effort and the accuracy of your cost estimates. However, a time entry does not automatically create an additional invoice item.
| Model | Clarify in advance | Check during day-to-day work |
|---|---|---|
| Flat fee or subscription | Included services, limits, and contract term. | Obtain separate approval for additional requests and review the effort involved. |
| Support budget or block of hours | Usage rules, validity period, and what happens when the budget or hours are used up. | Compare usage against the agreed allowance and notify the customer in good time. |
| Time-based billing | Rates, service types, and required supporting records. | Review time entries, activity descriptions, and approvals. |
| Separate enhancement order | Deliverable, price or budget, and authorization to proceed. | Keep enhancement effort separate from ongoing support. |
Recurring services are a demanding area. Alongside traditional licensing models, monthly and annual subscriptions, flat fees for maintenance and support, and other recurring models are becoming increasingly important. These involve numerous variations: payment models, free periods, contract terms, cancellation notice periods, start dates, and billing periods. Over time, these aspects cannot be managed reliably through individual knowledge, memory, or isolated lists. BCS helps us standardize these commercial requirements more effectively. Deadlines, items, billing periods, and follow-up reminders can be managed in a more structured way. At the same time, we see further potential for improvement in this area.
“Two hours for Customer A” tells you little when the customer pays a flat maintenance fee and is also billed for training based on time spent. Allocate the time to the specific activity and agreement. Also define who reviews time entries before invoicing.
BCS connects time tracking with commercial processes. Invoicing with BCS supports different billing rules, hourly rates, and service records. This allows you to prepare invoices based on documented work.
If a request exceeds the agreed scope, explain the effort involved and the next step to the customer. Obtain the required approval. A clear agreement on the work to be performed prevents disputes more effectively than a detailed explanation on the invoice later.
Separating organizational responsibilities should not create information gaps. The project team, service team, and commercial department therefore need connected data. BCS brings these work areas together.
Since BCS 26.2, the Services workspace has been available as a separate module that can be activated. It brings together long-term support, maintenance, and operations services. Roles such as service manager and service administrator clarify responsibilities, while appointments, checklists, workflows, and follow-up reminders support day-to-day work.
A service task provides the overarching context for work and time entries. Tickets record individual requests within it. Staff record time against services, service tasks, or tickets. Customers use the support portal for their requests; permissions determine which information they can access.
You can collect customer feedback directly on the ticket. Review feedback alongside time spent handling requests and recurring issues. Also compare effort and revenue: Frequent follow-up questions may indicate missing documentation, while consistently high effort may point to inaccurate cost estimates.
The BCS Ticketing & Services feature page outlines the features for customer service, project work, and ongoing support. The ERP functions of BCS explain the related commercial processes.
How far along is your service handover? Select the items your team has already clarified. The results show which next steps are still outstanding.
This checklist does not transmit any information or save any results. Use your selections to prepare for a joint review with your team.
Appoint a service manager for ongoing support. The project manager hands over knowledge and outstanding issues; the service team delivers the agreed services. The account manager remains the point of contact for changes to the commercial terms.
Agree on a stabilization phase that suits the solution and the level of risk. Document its duration, tasks, and handover criteria. A simple website may need a different timeframe than a business-critical application. There is no universally applicable number of days.
No. Review the reported issue and the existing agreements. Distinguish between outstanding project work, potential defects, included support, and separately commissioned services. Do not classify a request as billable solely based on when it was received.
Notify the customer in good time and follow the agreed procedure: obtain approval for additional budget, arrange further services billed by time spent, or postpone non-urgent work. Define in the contract how you will handle urgent cases and obligations already covered.
Use a few clearly defined metrics: response target compliance, age of open tickets, effort per service, budget usage, and customer feedback. Compare similar requests and timeframes. A long handling time alone explains neither its cause nor the quality of the work.
No. Review which system manages each process and how order, time, and billing data come together. Identify an authoritative source for each data item and define how corrections are handled. The items customer reference shows how a service provider uses BCS for project work, resource planning, effort tracking, and billing.
Kai Sulkowski is the Online Marketing Manager at Projektron GmbH in Berlin. As an IPMA-certified project management expert, he focuses on the organization of project work and ongoing services, as well as the practical use of business software. He draws on his many years of experience in editorial work and SEO to present complex subject-matter and technical concepts in a clear and practical way.
How does a ticketing system help with customer requests? This article shows how to connect communication, prioritization, time tracking, and billing in customer support.
Good service starts with an easy-to-use point of access. Learn how Projektron worked with Reutlingen University to improve its support portal from the customer’s perspective.
Project work and ongoing support rely on the same staff. This article explains how to plan resource demand and availability and identify bottlenecks early.
When does a project end, and what belongs to day-to-day operations? Learn about the characteristics of a project and how it differs from tasks and processes.
Illustration of the transition from a completed project to ongoing support: An arrow leads from a document with a check mark to a gear with a wrench.
