DEMONSTRATION ENVIRONMENT · illustrative data only · demo-tac.zenoa.nz
Assistance Centre Profix Consulting
End-to-end walkthrough

How the Profix Consulting Technical Assistance Centre works

STAGE 01 / 11

Onboarding your organisation

Before any connection exists, we agree exactly what will be supported and who is responsible for it.

  • We record the systems in scope — applications, servers, or both.
  • We confirm whether each server is reachable from the internet or sits on a private network. Both are supported.
  • A primary DevOps engineer is assigned to your account.
  • A project manager is assigned alongside them, accountable for timelines.
STAGE 02 / 11

Choosing the right connection

The connection method follows what you actually run — there is no single approach forced on every customer.

  • Web applications — an encrypted tunnel between your server and the Assistance Centre.
  • Windows or Linux systems — a site-to-site or remote-access VPN tunnel for diagnosis.
  • Publicly exposed or private-only, the outcome is the same: one encrypted, dedicated path.
STAGE 03 / 11

Establishing the connection, step by step

Setting up the path is a defined sequence — nothing is improvised, and nothing needs your firewall opened inbound.

  • The connector dials out from your side, so no inbound rule is required.
  • A named low-privilege access account is created — never direct root.
  • The path is tested, then immediately closed again.
STAGE 04 / 11

Keys nobody can read

The tunnel authenticates itself. Its credentials are generated automatically and held in code.

  • Keys are generated by the system at establishment time.
  • They are not visible to our engineers.
  • They are not visible to your team either.
  • Nobody can hand over, reuse or mislay a credential they never had.
STAGE 05 / 11

Closed until you ask

A standing connection you cannot see into is a standing risk. Ours does not stay open.

  • The tunnel sits dormant — established, but closed.
  • No engineer can reach your systems while it is closed.
  • It opens only in response to a request from you.
STAGE 06 / 11

You raise a request

Two ways in, and they behave identically — use whichever suits the moment.

  • Open a ticket directly in the Assistance Centre portal, or
  • simply email [email protected].
  • Either way the system reads the request and raises a ticket automatically.
  • Nothing is handled informally — every request becomes a tracked ticket.
STAGE 07 / 11

Routed to a named engineer

The ticket goes to the person who already knows your environment.

  • It is assigned first to your primary DevOps engineer.
  • If they are unavailable, it escalates to your project manager.
  • The project manager reassigns it to an available engineer immediately.
  • A request is never left waiting for someone who is not there.
STAGE 08 / 11

Access opens, and is recorded

The moment work begins, the dormant tunnel activates — and everything done through it is captured.

  • The engineer picks up the ticket.
  • The system issues an access request against your environment.
  • The standby tunnel activates automatically.
  • Every action taken is recorded from that moment until the work ends.
STAGE 09 / 11

Inside the session

You watch the work happen. One pane for conversation with the engineer and project manager, one for the console they are working in.

  • Engineers connect as a named low-privilege account, never directly as root.
  • Root access requires a deliberate sudo su, which is itself flagged in the recording.
  • A timer shows exactly how long an engineer has been on your system.
  • You can comment at any point — it is added to the ticket thread.
STAGE 10 / 11

Held to the clock

Oversight is automatic, so progress does not depend on anyone remembering to chase.

  • Standard tickets — the project manager is alerted every hour.
  • Urgent tickets — the project manager is alerted every 25 minutes.
  • Alerts continue until the work is done, keeping delivery inside agreed timelines.
STAGE 11 / 11

Reported, then closed by you

The ticket does not close because we say it is finished. It closes because you agree it is.

  • The engineer completes the work and closes their part of the ticket.
  • You receive an email with a complete report of the activity performed.
  • The same report is logged in the portal for you to review at any time.
  • Reply by email or in the portal — once you confirm, the ticket closes automatically.
Skip to sign in →