Custom service request software for partner networks

One request, different needs

Say a client reports a fault to an installer. The installer records the problem and adds a photo, but another company in the network is to do the repair. The coordinator passes the matter to it. From that moment each party needs a slightly different view of the same work.

The installer wants to know whether someone has picked up their request. They should be able to go back to their own description and photo and check whom the matter was passed to and what stage it is at. They can then answer the client without phoning head office. They need no access to the service technician's later notes or the coordinator's internal arrangements.

The company doing the repair needs the client's contact details, the fault description and the photo to prepare the visit. It records how its work went and can come back to it later. There is no reason for it to gain access to the installer's other requests along the way. Head office, in turn, has to see everything: what came in, whom the matter was passed to and what happened during the repair. Its internal notes stay visible only to authorised staff.

This is one possible split of access. In your network the installer may need different information. Settle it on a specific request, because a general instruction to “pass the matter to a partner” does not say what should stay visible to the earlier participant. When the system does not make this distinction, the coordinator has to pick files by hand and copy parts of the history.

Can your current service request system already do it?

Before you order an app, ask the administrator to show such a hand-over in the tool you use. Look at the matter from both partners' accounts. Will the service technician open the photo? Will the installer still see the status without getting an email with internal notes on the repair? Will head office be able to rebuild the course of the matter without searching mailboxes? The check should also cover the moment before the hand-over, when the future contractor has no access to the request yet.

Changing the person or company assigned to the matter does not answer these questions on its own. Permissions can also follow from the settings of the organisation the user belongs to. For example, Zendesk Support assesses ticket visibility separately at the organisation level and in the end-user profile. When these settings conflict, the one that gives wider access applies. That is how this specific permission setting works in Zendesk; it is no common rule for all systems (Zendesk documentation).

If the demo reveals a problem, establish with the vendor whether it comes from configuration, plan limits or a missing feature. Ask about accounts for outside partners and roles with limited access. A partner who only accepts selected jobs may need far fewer features than a head-office employee. The options available and their terms have to be checked for the specific product.

Configuration, an extension or your own app

When the ready system supports the split of information you need, start with configuration. The cost of the change then also covers tidying existing accounts and showing partners how to work. Before renewing the contract, compare the available plans and other SaaS products. A high bill for rarely used accounts is a reason for such a comparison, and on its own it does not settle whether building pays.

An extension makes sense when the current system runs requests well and one piece of work is missing. It could be a simple view for the partner or a record of why a matter was handed over. The requests and their history can then stay in the current tool. You do need to check whether the supported way of connecting lets you share the right data with the partner and record their actions. If the coordinator still has to copy the repair result into the main system, part of the problem remains.

Your own workflow is worth considering when partners constantly pass matters to each other, and the access and history needed cannot be handled by configuration or an extension. The scope can be limited to working with partners and a connection to the current CRM. Leave a full system replacement for the case where keeping the current tool really prevents the change you need.

AI is not required for such a workflow. It can help shorten a long fault description, if the team needs that. Assigning the matter and access to data should still follow the agreed rules.

What will cost time after launch

When comparing offers, count the coordinator's work on one hand-over. If they have to send photos separately, set up an account and later retype the reply, write these steps down with how often they recur. Next to the subscription, you then see the real work the change is meant to simplify. Assess in the same way the time needed to invite a new partner, remove their access and help them when they cannot find a job.

With your own app, some of the SaaS vendor's duties pass to the company and its supplier. Someone has to maintain the connections to the CRM, respond to errors and update the app. Settle who helps the coordinator if a request does not reach a partner, and who trains the people joining the network. These duties should have an owner and a place in the maintenance offer.

Changing the system also needs decisions about open matters. A request description without photos or repair history may not be enough for further work. Before migrating, check what can be moved and how you will keep the assignment to partners. For closed matters, settle how the archive is used and how data is exported after the contract ends.

When ordering an app, also agree that it can be handed to another supplier. You will need rules for access to the code and the hosting accounts, documentation and a record of changes and maintenance work. That lets you judge how much work taking over the system will need before dependence on a supplier becomes a problem.

How to start a conversation with Syntalith

When a partner also needs the history of a specific device, the scope of preparing service information with AI helps. Partner access and the hand-over of jobs need separate arrangements in a service network project.

Syntalith builds custom apps. In a service network, a useful starting point is one hand-over where the coordinator has to do the system's job today. From that you can set the scope of the partner view and the connection to your current tool, and then compare such a project with what a ready product can do. The aim is to remove specific steps, such as retyping the repair result, while keeping the full history at head office.

For the first call, the system's name, the plan you use and an anonymised request that shows the problem are enough. Tell us what the coordinator does outside the system and what the partner cannot check for themselves. You do not need to write out all the permissions beforehand. A custom app at Syntalith starts from €3,000 net (pricing). If you also need a place for wider customer service, read the comparison of a custom customer portal and a CRM add-on.

What a partner request workflow 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.