Engagement model
Documented, reviewed, and not dependent on one person.
Every procedure at STP is written down and coordinated, specifically so that no part of your estate (or ours) lives only in one engineer's head. That is a deliberate design choice about risk, and it shapes how every engagement runs.
Four phases
How an engagement runs
- 01
Discovery
We look at what exists before proposing anything. For infrastructure that means a site survey; for platforms it means reading the estate and talking to the people who operate it. You get a written current-state picture, which is frequently the first time an organisation has one.
You receiveCurrent-state documentation and a plain statement of what we found
- 02
Design
A design that records not just what will be built but why each decision was made, including the options we rejected. That matters two years later when someone asks why the fabric looks the way it does.
You receiveDesign document with rationale, bill of materials, and a phased plan
- 03
Delivery
Phased switchover, sequenced to minimise impact on your working day, with a defined rollback point before each phase. Out-of-hours and weekend work where operations require it. Every project is reviewed by a second senior engineer who did not do the work.
You receiveWorking system, plus as-built documentation that matches reality
- 04
Handover or operation
Either we hand over with runbooks and training, or we keep operating it under subscription. Both are legitimate; we will tell you which we think fits your team. A handover is not complete until someone on your side can execute the runbook.
You receiveRunbooks, documentation pack, training: or an ongoing service schedule
Support commitments
A severity model, so "urgent" means the same thing to both of us.
Most disputes about support are really disputes about priority. We classify every ticket against the definitions below, agreed with you in advance, so nobody has to argue about whether something counts as critical while it is still broken.
| Severity | Definition | Response |
|---|---|---|
| P1: Critical | A business-critical service is down or a security incident is active. Multiple users or an entire site cannot work. | Immediate: live engineer engaged, continuous work until service is restored |
| P2: High | A business-critical service is degraded, or a single user is completely blocked on essential work. A workaround may exist but is not sustainable. | Same business day |
| P3: Normal | A fault or request affecting productivity without stopping it. Most day-to-day support falls here. | Within the agreed service-schedule target |
| P4: Scheduled | Planned change, onboarding, project work or a request with a future date. | Scheduled by agreement |
The commitment that does not vary: A live engineer calls you back within 1 hour. A person answers the phone. You are not put in a queue, and you are not left waiting on hold to report that your business has stopped.
Specific clock targets per severity are set in each client's service schedule, because a bank's P1 and a hospitality group's P1 have genuinely different economics. We would rather commit to numbers we have agreed with you than publish a number that means nothing.
Deliverables
Documentation is a deliverable, not a favour.
A system that works but is undocumented is a liability with a delay on it. Depending on scope, an engagement produces:
- Current-state assessment produced during discovery
- Design document recording decisions and the options rejected
- As-built drawings and rack elevations
- Cable schedules identifying both ends of every run
- Labelled serial number inventory
- Network diagrams and IP address documentation
- Photographs of completed physical installations
- Runbooks for operational procedures
- Restore and failover test results where in scope
All of it is yours. You can hand it to a different supplier, and it will make sense to them, which is the actual test of whether documentation is real.
Questions
- How does STP price work?
- Infrastructure build work is normally priced as a fixed-scope project after a survey, so you are not exposed to open-ended time and materials. Operational services (help desk, managed IT, Network-as-a-Service, Conference-as-a-Service) are monthly subscriptions, generally priced per endpoint, per site or per room depending on the service. We quote after discovery rather than before, because a number produced without a survey is a guess.
- What happens if something goes wrong outside working hours?
- Cover outside standard hours is set in your service schedule. STP's standing commitment is that a live engineer (not an automated queue) calls you back within one hour of your call. Organisations with 24×7 requirements, which includes most of our financial and betting-sector clients, contract for explicit out-of-hours cover.
- Will you work alongside our existing IT team or supplier?
- Yes, and it is common. The usual split is that we take infrastructure, monitoring and escalation while your team stays close to users and the business. Where another supplier is already in place we define the boundary in writing, because an undefined boundary between two suppliers is how incidents become arguments.
- Do you sign NDAs?
- Yes. Most of our work is under confidentiality, which is why our published case studies describe engagements at sector level rather than naming clients.
Start with discovery.
Most engagements begin with us looking at what you already have and telling you what we found. That conversation costs you nothing.