Technical Support Engineer

Technical Support Engineer | B2B SaaS

Remote, South Africa · Independent Contractor · Initial 6-month services agreement · £1,200 - £1,600 per month · Client contact: Product Lead

Keepnet isn't just scaling, we're redefining human risk and secure behaviour management in cybersecurity. Trusted by global enterprises including Vodafone, Merck, Arriva and Hershey, we reduce human cyber risk through AI-driven automation, with Agentic AI now extending that capability further.

Support is where the product meets reality. Every ticket is a customer telling us something true about the platform, and every ticket is either a problem we keep answering, or a problem we solve once and remove at the source.

The services cover customer issues end to end: investigate the evidence, reproduce the problem, hand a proven case to the Product Lead where a code fix is needed, keep the customer informed throughout, then help remove the underlying cause from the product, the documentation or the onboarding flow.

This is a technical engagement, not a script-reading helpdesk. It involves reading logs and error records, reproducing bugs in test tenants, and coordinating with our Product Lead in a fast moving SaaS scaleup.

This is a fully remote, independent contractor engagement for a provider based in South Africa. The service availability requirements are set out in the engagement terms below.

Before you apply. This engagement requires prior customer-facing B2B SaaS support experience: a multi-tenant, cloud-based platform that customers configure and run inside their own organisation. The category matters far less than the model, and security experience is welcome rather than required. Internal IT, device support, retail and consumer call centre experience alone won't provide the platform troubleshooting background this engagement needs.

Why This Engagement Matters

Today, one person runs global support at Keepnet alongside their product responsibilities. That is possible because of how the operation is built:

• Discipline. Nothing is answered from memory, and nothing closes without a cause recorded
• Documentation quality. The help centre is maintained to the point where most questions never become tickets
• AI agents accelerate the analysis. Evidence-based work that used to take an hour of log reading now takes minutes, so the time goes into judgement rather than retrieval
• Monitoring. We see errors and failures in our own records, at tenant level, without waiting to be told
• Proactive support. A significant share of issues reach the customer from us first. The conversation starts with "we noticed this on your tenant and here is what we've done", not "sorry to hear that"
• A working relationship with product. Causes get fixed properly, so the same problem doesn't return as a different ticket next quarter

As our customer base grows we need a dedicated provider for this function, so support scales with the business and senior product time goes into building rather than answering. You are inheriting a functioning machine, not repairing a broken one, and the standard is the thing we're asking you to protect.

The Product Lead is the client contact for this engagement, which is deliberate. The patterns you find in the queue go into the roadmap rather than into a backlog nobody reads. Support here is a product function, not a cost centre.

Behaviour matters more than product knowledge in this engagement. Our platform and our domain can be picked up in weeks, and we will onboard you to both. How you behave when a customer is stuck cannot be taught in the same way, so that is what we assess hardest.

This engagement suits someone who:

• Goes and looks. When something is unclear, the answer is "I'm checking that now", followed by actually checking it in the logs, in Sentry, in the tenant configuration
• Says "I'm confirming this and coming back to you at 14:00", and then comes back at 14:00
• Reproduces the problem themselves before saying anything about its cause
• Is more interested in why the ticket exists than in how fast it can be closed
• Doesn't interrogate the customer. You ask for the one or two things you genuinely cannot find yourself, not a list of "have you tried" questions that put the work back on them
• Doesn't act as a relay. Passing a case up without investigating it first is not support work
• Notices when documentation is wrong or a screen is confusing, and does something about it instead of working around it
• Stays calm and constructive with a frustrated customer, every time, without exception

How escalation works here

The Product Lead owns the interface with engineering, and that is deliberate. You are not expected to raise development tickets, manage a backlog, chase engineers or judge whether an engineering output is correct. That work sits with the Product Lead, and it stays there.

Your side of it is the part that decides whether the process works at all:

• You establish that it is a real defect, with the evidence to prove it, and not a configuration or environment issue
• You hand the proven case to the Product Lead in a state that can go straight to engineering
• You keep ownership of the customer relationship while the fix is being built: the customer hears from you, on schedule, not from silence
• You follow up with the Product Lead until the fix comes back, verify it against your own reproduction steps, then answer and close the ticket yourself

The customer has one point of contact throughout, and that is you. The engineering queue has one point of contact, and that is the Product Lead.

What's In It for You

End-to-end ownership, and a real mandate to fix the cause

You own the ticket from first response to confirmed resolution, including the stretch where the fix sits with someone else. And when you show that a category of tickets is caused by a bug, a documentation gap or confusing UX, there is an established route to getting it changed, not a suggestion box.

A direct line to product

You coordinate with the Product Lead on escalations and release verification. Your ticket data shapes what we build next, and you'll see your findings land in the release notes you're reading.

Paid in sterling

A fixed monthly fee in GBP, invoiced monthly, under an initial six-month services agreement, renewable by mutual agreement. The fee is reviewed at each renewal. The scope of the engagement can be extended by agreement as the business grows.

Certification

You are expected to hold, or obtain at your own initiative, Intercom certification within 90 days of commencement.

A modern support stack

Intercom as the system of record, Sentry for error and event records, Slack and Microsoft Teams for collaboration, Jira for escalations, and Claude, ChatGPT and Cursor as daily working tools. You have the visibility to answer most questions yourself, without asking the customer to do your diagnostics for you.

Remote working

Deliver the services fully remotely from South Africa, with regular virtual collaboration with the Keepnet team: structured enough to keep momentum, flexible enough to do your own best work.

Scope of Services

The services include:

Solving the case

• Managing the inbound queue in Intercom: triaging by severity and business impact, responding inside SLA, and always telling the customer when their next update is coming
• Investigating before asking. Checking the error and event records, platform and audit logs, browser console and network traces, API requests and responses, mail flow and tenant configuration first. Going to the customer only for the specific detail that cannot be seen from our side
• Reproducing the issue in a test tenant. If it doesn't reproduce, keeping going: matching it against the records for that tenant, timestamp and user, and narrowing it down from the data rather than sending the customer a checklist
• Stating only what has been verified. Nothing goes to a customer as expected behaviour, a known issue or a root cause unless you can point to the record that shows it
• Escalating with a finished investigation, not a forwarded email. Everything handed over carries reproduction steps, tenant and user IDs, UTC timestamps, the relevant error event and log excerpts, and what has already been ruled out, so it can go straight into the engineering queue without rework
• Working the monitoring, not just the inbox. Reviewing the error records daily, spotting failures at tenant level before anyone reports them, and contacting the affected customer with the problem and the action already taken. Tickets you prevent count as much as tickets you close
• Tracking the two-week release cycle: reading every release note on the day it ships, testing the new and changed functionality in a sandbox tenant, verifying hotfixes against the original reproduction steps, and going back to every customer whose ticket was waiting on one

Removing the cause (standing process here, not an extra)

• Classifying every resolved ticket by root cause: product bug, documentation gap, UX friction, configuration or environment issue, missing feature, or genuine one-off. No ticket closes unclassified
• Running root cause analysis on the categories that repeat. Not "three customers asked about this last month", but why they had to ask at all, and what change makes the question unnecessary
• Closing documentation gaps directly: writing and updating help centre articles, setup guides and troubleshooting pages so the next customer self-serves
• Surfacing UX friction with proof: when customers consistently misread a screen, miss a setting or take the wrong path, capturing it (steps, screenshots, how many customers) and putting it to the Product Lead as a change proposal, not a complaint
• Raising bugs in a state that can be acted on immediately: reproducible, scoped, affected versions and tenants identified, customer impact quantified
• Reporting with evidence, not anecdotes: ticket volume by cause, trend over time, and which fixes would remove the most volume
• Verifying your own analysis: once a root cause change ships, confirming the related ticket category actually drops. If it doesn't, the analysis was wrong and you say so plainly
• Using AI tooling to move faster, within approved guidelines, and verifying its output before it reaches a customer

What You'll Bring

Must have

• At least 3 years supporting a B2B SaaS product, in technical support, application support, product support or a customer-facing engineering role
• Experience with the customers this engagement serves: B2B security or IT buyers. CISOs, security managers, IT and SOC teams, platform administrators. You can talk to them about their environment without either pretending to be an engineer or retreating into scripted language
• Comfortable in a multi-tenant model: you know that a setting changed in one tenant is not a platform-wide fault, and you check which is which before saying anything
• A structured method you can describe, and walk us through on a real case
• Practical log analysis, browser developer tools, HTTP status codes and REST/JSON basics
• Evidence of root cause work, not just ticket work: a change you argued for and got shipped, an article that killed a recurring question, a workflow you redesigned
• Written and spoken English strong enough to represent the brand unsupervised, with a customer under pressure, on your own judgement
• Experience with Intercom or a comparable platform (Zendesk, Freshdesk, HubSpot Service Hub, Front): inbox workflow, macros, help centre content, reporting
• Self-learning: you pick up an unfamiliar product from documentation without waiting to be taught
• The self-discipline to deliver from a fully remote setup

Onboarding to Keepnet covers

• The Keepnet platform and architecture
• The cybersecurity and human risk domain
• Email security specifics: SPF, DKIM, DMARC, mail flow and gateway behaviour
• Our Sentry and monitoring workflows
• Our escalation and root cause process

Bonus

• A cybersecurity background of any kind, or experience with a platform in our space (KnowBe4, Proofpoint, Mimecast, Hoxhunt, Abnormal, or similar)
• Microsoft 365 or Google Workspace mail flow administration
• Basic read-only SQL
• SSO and provisioning depth: SAML, OIDC, SCIM, Active Directory or Entra ID
• Familiarity with Cloudflare, Nuxt, Vue or PostgreSQL
• Exposure to ISO 27001, SOC 2 or GDPR requirements in a customer-facing context

How We Engage: Independent Contractor Terms

This is an independent contractor engagement with Keepnet Labs Ltd (UK) under a services agreement, it is not employment. We expect you to already be set up to work in that capacity:

• You operate as an independent contractor, either in your own name as a registered provisional taxpayer with SARS, or through your own registered business entity
• The initial term is six months, renewable by mutual agreement
• This is a non-exclusive engagement. You may provide services to other clients, provided there is no conflict of interest with Keepnet or its customers
• You may, with our prior written agreement, provide a suitably qualified substitute to deliver the services
• Fees are payable for services delivered against the agreed scope, not for hours attended
• You invoice Keepnet monthly for services delivered, and are paid against invoice
• You are responsible for your own tax affairs and statutory obligations in South Africa. Keepnet does not operate South African payroll and does not withhold PAYE or make UIF or SDL contributions on your behalf
• This engagement does not carry employee benefits such as paid annual leave, sick pay or pension contributions. The fee reflects this
• You provide your own working setup: home office, a laptop capable of performing to the needs of the engagement, reliable fibre internet, a load-shedding contingency (UPS or inverter and backup connectivity), and a quality headset and camera
• Services are to be available to customers during UK business hours as a commercial requirement of the engagement, because that is when our customers and our engineering team are online. How you organise your time outside those service windows is your own
• Any engagement is subject to reference and background checks completed before start

How We Work

Three rules sit above everything else in this engagement:

• Check first, then speak. No statement about cause reaches a customer without the record behind it, and nothing is misrepresented: where a fix has no date, we say that plainly and give the next update time. A theory is not a finding. If something is unverified, it goes out labelled as unverified, to the customer and to us. "I assumed" is not an answer here. "I'm checking X, I'll come back at 14:00" is
• The diagnostic work is ours, not the customer's. We don't send question lists in place of investigation, and we don't ask for anything we can retrieve ourselves
• No customer should ever have to chase us. The next update time is always stated, and always met, including when the answer is that work is still in progress

Alongside those: customer data is handled under UK GDPR and our ISO 27001 controls, AI tooling is used only as approved (no customer data or tenant identifiers in unapproved tools), and every material finding and commitment is written into the ticket.

Deliverables for the Initial Engagement Period

• Queue handled independently and inside SLA
• Escalations to the Product Lead complete enough to go to engineering without rework
• The two-week release note and hotfix verification cycle running reliably
• Monitoring reviewed daily, with proactive outreach to affected customers as routine rather than exception
• Root cause classification maintained on every closed ticket, and the first trend report delivered to the Product Lead
• At least three root cause improvements identified and taken forward: documentation, UX or product

Pay: R25 900,00 - R34 000,00 per month

Application Question(s):

• Which SaaS platform did you support, who were its customers, and what did a typical hard case look like?
• Describe a customer issue where the reported cause turned out to be wrong. What did you check, in what order, to establish what was actually happening?
• Tell us about a recurring ticket you eliminated at source. What was the root cause, what did you change, and how did you prove the volume dropped?
• How do you use AI tools in your support work, and how do you verify their output before it reaches a customer?

Work Location: Remote