Shared services: agree on the work each company can expect

Two companies ask for work in the same week, and the team has capacity for one. Each company sees only its own date, so the manager settles the order by phone and moves it into a spreadsheet no one else can see.

Two requests, one available team

Say two companies want to prepare product materials in the same week. Both entered an expected date in their own tool. The service centre already has other confirmed work, so it cannot promise both requests in full. The manager needs to talk about a realistic scope, and the people making the requests need to know whether their date has been accepted.

In the proposed app, the manager sets the new demand against the agreed work. They can offer the first company a smaller scope on an earlier date, and the second a later delivery. The people who made the requests see the proposals for their own matters. The confirmed arrangement goes into the team's plan together with the scope it covers.

This lets you talk about the consequences of a new urgent request. The person deciding sees which previously agreed work has to move. The app does not choose priorities for the group. The company names who may change the centre's commitments to the companies and how such a change is agreed.

Shared service centre planning may already be available

Atlassian describes capacity planning in Jira Plans, including a view of the team's workload and changes to the available work in an iteration. Before choosing an extra tool, check whether this feature is available and whether it fits the way you plan.

If your current system shows the shared team, and the requesters understand the difference between an expected and an agreed date, making better use of its plan is enough. A separate register is more justified when demand comes from several companies' systems and the manager regularly retypes the arrangements. An integration can then bring the requests in and return the confirmed date to the source.

Your own workflow makes sense when you need a shared way of negotiating scope that the available modules do not handle well. The centre's team should see the whole plan, and each company its own arrangements. Internal comments about other companies need not appear in its view.

The scope worth seeing before you buy

When comparing offers, use one week with competing requests. Can the manager put forward a workable proposal, and can the requester tell what has been confirmed? That is a better basis for scope than the number of forms and notifications. You do not need to move all task management at once.

At launch, keep the work already accepted and the people responsible for the arrangements. The export should cover the scope, the date and later changes. Agree with the supplier who looks after the connections and what happens when a date change does not get back to the company. Access to the code and documentation and ownership of the data matter if the app's support changes hands later.

Discuss the service centre's work plan with Syntalith. It is enough to describe how two competing requests were settled last time. We will compare your current tool with the connection or the app you need. Syntalith's apps start from €3,000 net, and we set the scope after a free process review (pricing).

What service centre planning software costs and when it pays back

Where to start

In the free process review we choose one process and count the team's volume and working time, and within 2 working days you get a written summary with a price. We build as part of AI apps, and we price maintenance separately.