The short version
- Bought-in capacity is not a sign of weakness but a costing decision: a permanent senior for Cisco, security or automation only pays from a certain number of similar projects per year.
- The three common models differ mainly in who owes the result — time, a defined deliverable, or a complete work package under your brand.
- Four points belong in the contract regardless of model: roles, customer protection, confidentiality, and handover of the artefacts.
- The collaboration rarely fails on technology. It fails on unclear responsibility during an incident and on documentation that stays with the provider.
For an IT provider the scarce resource is rarely sales and almost never hardware. It is the person who can own a campus migration without anyone reading over their shoulder. That person is expensive, hard to find and usually deployed elsewhere.
When buying in is the right decision
The question is not a matter of principle but of utilisation. A permanently employed senior in a specialist field pays for themselves when enough similar projects arrive each year to keep them both busy and technically sharp. Both matter: a specialist without regular projects in their field loses the capability they were hired for.
Buying in is therefore typically right when one of these patterns applies: the speciality comes up two to five times a year. A single project is larger than what your team can carry alongside its regular work. Or you need a second opinion with responsibility attached for a limited period, not just an opinion.
Three models — the difference is in the deliverable
| Model | Who owes what | Fits when |
|---|---|---|
| Time-based | Availability and qualification, not the outcome | Your team leads and you need extra hands with depth |
| Deliverable-based | A defined result with formal acceptance | The scope can be described clearly — migration, design, assessment |
| White-label work package | A complete package under your brand | The customer should see one contact: you |
The models combine, and in practice they do: a deliverable-based design followed by time-based support during rollout. What matters is that it is clear at any moment which one applies — because that determines who decides in case of doubt.
What belongs in the contract
Roles and decision paths
Who talks to the end customer, who decides technically, who approves changes? Without those three answers, the first conflict opens a gap the customer notices.
Customer protection
A clear agreement that the end customer stays yours — no direct approach, no separate offer, not even after the project ends. That is the basis on which you let a provider near your customer at all.
Confidentiality
An NDA that also covers credentials, network documentation and the findings from the assessment. Usually that is your customer's NDA, passed through.
Handover of the artefacts
Everything produced — design document, configuration templates, test reports, acceptance record — transfers into your possession and into your tools. This is the point at which long-term dependency is decided.
Behaviour during incidents
After acceptance the customer calls you. What has to be settled is how you reach the original engineer, within what time and until when — otherwise the handover is a cut rather than a transition.
The three mistakes that cost the customer relationship
- Direct contact without agreement. An engineer who casually suggests a better solution to the end customer means well and still damages your position. That is a matter of agreement and discipline, not of goodwill.
- The responsibility gap after acceptance. The project is done, the bought-in engineer is gone, the first incident arrives three weeks later. If nobody knows the history at that point, the handover was incomplete.
- Documentation that stays with the provider. If you only hold the target state as a PDF but not the templates and data it came from, you cannot maintain it. The next change then means buying in again — this time without a choice.
The third point is the decisive one and the most frequently overlooked. That is why we deliver our work as artefacts that remain usable without us. Which ones belong to which project stage is described in the article on accepting a network project.
How we hold to this
We deliver under your partner brand — with clear roles, customer protection and an NDA. The end customer stays your customer; we appear the way you define. What we do not offer we state up front: we are not a Cisco partner, and we do not handle procurement. What we deliver is engineering capacity with CCNP-certified engineers and a method whose results you keep.
Details on the collaboration and the fields we deliver in are under enterprise networks, network automation and network security.