There's a technician coming to the apartment in a few hours. The fiber is already lit — previous tenant had the same ISP, same service, the little green lights on the ONT are blinking happily. And yet, someone has to drive here, walk in, and do something that apparently can't be done remotely.
The truck roll that technically shouldn't need to happen. And you're bracing for the experience, because the last time you dealt with an ISP tech here, it was... let's say, not a warm exchange.
Don't ask questions, let me work, I'll be out in twelve minutes. And if you mention you want to use your own access point instead of their router's Wi-Fi, they look at you like you've just asked them to perform open-heart surgery on a gerbil.
Which is the part that really throws people. You assume an ISP technician understands networking. That seems like a reasonable assumption. And then the interaction suggests something else entirely.
The prompt is basically: who are these people, what does their day actually look like, how much training do they get, and is the perpetual bad mood a personality problem or a systems problem? And also — is this just Israel, or is this the job everywhere?
That's the right question to start with. Because the behavior is so consistent that it can't just be a run of bad luck with individual techs. Something structural is producing it.
We've got about two hours before the doorbell rings, so let's figure out what's actually going on behind the clipboard and the snappy one-word answers.
Let's start with the thing that already feels absurd before the tech even arrives. The fiber is active. The previous tenant had service from the same ISP. Why does a human being need to physically show up?
Because the Ministry of Communications says so. Regulation four point three point two requires a physical activation signature for fiber connections. Someone has to visually inspect the termination point and confirm the fiber isn't damaged. And the ONT serial number has to be matched against the system.
The previous tenant's service was disconnected at the OLT — the optical line terminal at the central office. The port is still there, the fiber is still physically connected, but it's been de-provisioned. The tech has to re-provision it: log into the system, associate the port with the new account, confirm light levels are within spec.
Which raises the obvious question: why can't that be done remotely? The OLT is software-controlled. The ONT is already registered. The fiber isn't moving. This is a database update with a truck attached to it.
The answer, frustratingly, is that the regulation is a holdover from the copper DSL era, when line quality varied wildly from apartment to apartment. A physical inspection made sense when you were dealing with corroded copper pairs that might have been sitting unused for six months. But fiber is digital. If the light level is good, the connection is good. There's no gradual degradation that a visual inspection catches.
The regulation is solving a problem that no longer exists, and the result is thousands of unnecessary truck rolls per month. And each one of those rolls is a tech who's already behind schedule before he even parks.
Which brings us to the schedule. And this is where the behavior starts to make sense. Israeli fiber techs are assigned ten to twelve jobs per eight-hour shift. That's thirty-five to forty-five minutes per job, including travel. In a dense city like Tel Aviv or Jerusalem, travel between jobs might eat fifteen of those minutes. So you're looking at maybe twenty minutes on-site to do everything.
Twenty minutes to park, find the building, get inside, locate the wall box, inspect the fiber, re-provision the port, set up the router, configure the Wi-Fi, get a signature, and leave. And that's if everything goes perfectly.
Everything almost never goes perfectly. The building's telecom closet is locked and the va'ad bayit didn't provide the key. The previous tenant painted over the wall box. The ONT is behind a bookshelf that wasn't moved before the appointment. Any one of these burns ten minutes, and suddenly the tech is behind for the rest of the day.
When you say "actually, I'd like to use my own router," what the tech hears is: "I am about to destroy your schedule.
Because setting up a customer-owned router is not in the script. The script says: plug in the ISP router, connect to the ONT, run the setup wizard, confirm the Wi-Fi is broadcasting, get the signature, leave. Anything outside that is undocumented, unsupported, and — critically — creates callback risk.
Explain the callback risk. Because I think that's the invisible whip.
If a customer calls back within a certain window — usually forty-eight to seventy-two hours — to report a problem, it counts against the tech's metrics. Even if the problem is the customer's own equipment. Even if the customer unplugged something and forgot. The callback gets logged as a failed installation. Too many callbacks and the tech loses shifts, gets put on probation, or is let go.
Helping you set up your Ubiquiti Dream Machine is not just extra work — it's a liability. If something goes wrong, the tech gets dinged. If he sticks to the script and something goes wrong with the ISP router, he's covered because he followed procedure.
He has no training on your equipment anyway. ISP technicians are not network engineers. They are installation specialists trained on a specific device lineup — usually one or two router models, one ONT model, and a fixed set of procedures. Most of them cannot explain what a VLAN tag does. They've never seen an OSI model diagram. They don't know what DHCP stands for beyond "it gives out IP addresses.
Which sounds shocking until you look at the hiring pipeline. Most techs in Israel come from vocational high schools — ORT, Amal — or they're post-army. Some are Mamram or Unit 8200 dropouts who didn't make the cut for intelligence units and ended up in civilian telecom. They get two to four weeks of classroom training.
Two to four weeks. They learn fiber splicing, ONT configuration, basic router setup. They learn the script. They do not learn networking theory. No subnetting, no routing protocols, no bridge mode configuration. They are not paid to understand the network. They are paid to execute the script.
The pay reflects that. Average salary for an ISP tech in Israel is around seven thousand five hundred shekels a month — about two thousand one hundred dollars — according to the Central Bureau of Statistics labor survey from the first quarter of this year. No equity, no bonuses. Some are contractors, which means no benefits either.
You have a young person, often early twenties, making just above minimum wage, with four weeks of training, carrying a quota of ten to twelve jobs a day, where every deviation from the script threatens their metrics and their job security. And then a customer says "I'd like you to put the ONT in bridge mode so I can use my own router.
The tech has no idea what bridge mode is. Or he knows what it is but has never been trained to configure it. Or he knows how to do it but also knows that if he does it and something breaks, the callback hits his record. So he says no. Not out of malice, but because saying yes is all risk and no reward.
He says it gruffly, because he's got eleven minutes left on this job and his next appointment is already texting him asking where he is. The gruffness is not a personality flaw. It's time-management triage.
There's a case study that illustrates this perfectly. Tech in Tel Aviv, eleven jobs scheduled. Job number four is a customer who wants to use a Ubiquiti Dream Machine. The tech has no training on Ubiquiti. He has no credentials to access the ONT's bridge mode settings — those are often locked behind a supervisor login he doesn't have. His next job is twenty minutes away and he's already five minutes behind. He says no and leaves. Not because he's a jerk, but because saying yes would cascade into overtime without pay and potentially a callback that hurts his numbers.
This is where the cognitive conservation piece comes in. Techs develop scripts for every interaction — not just the technical script, but the social script. "Where's the wall box?" "The Wi-Fi password is on the sticker." Any deviation triggers cognitive load they aren't paid to handle. The "don't ask questions" attitude is literally them conserving mental bandwidth for the next six jobs.
It's the same phenomenon you see in any high-volume, low-autonomy job. The brain automates everything it can because there's no slack in the system for thinking. Thinking takes time, and time is the one resource the tech has zero of.
Who actually takes this job? For a lot of these guys, this is not a career. It's a stepping stone or a fallback. The ones who are good at it and curious about networking tend to leave within a year or two for better-paying jobs in enterprise IT or at the ISPs' network operations centers. The ones who stay are often the ones who've learned to survive the quota system by not thinking too hard.
Which creates a selection effect. The techs who would actually be excited to help you configure your Dream Machine are the ones who've already left the field. The ones who remain are the ones who've optimized for speed and script compliance. It's not that they're incapable of understanding networking — it's that the job selects against curiosity over time.
The system eats its own talent. And then the customer stands there wondering why the person sent to activate their internet seems to actively resent being asked a technical question.
Now, is this unique to Israel? The short answer is no. The same job design produces the same behavior everywhere, just with different cultural veneers. In the US, Comcast and Spectrum techs have quotas of four to six jobs per day with seventy-five-minute windows, so they're less rushed per interaction but still operating under the same metric pressure. In Germany, Deutsche Telekom techs are salaried with no per-job quota, which leads to more patient interactions — but also wait times of two to three weeks for an appointment.
You trade gruffness for availability. The German tech is relaxed and helpful, but you waited three weeks for him. The Israeli tech is at your door tomorrow morning, but he's got the emotional bandwidth of a caffeinated hummingbird.
In Japan, NTT techs are famously polite — bowing, wearing spotless uniforms, using little mats for their tools — but they are also famously rigid. They will not touch non-NTT equipment under any circumstances. The politeness is a cultural overlay on the same structural rigidity. The script is the script, whether it's delivered with a bow or a grunt.
The Israeli cultural overlay is what we call dugri — direct, blunt, no wasted words. What reads as rudeness to someone from a higher-context culture is often just efficiency in a culture where softening language is considered a waste of everyone's time. The tech isn't angry. He's just not performing emotional labor he's not paid for.
That's the core insight. The behavior is not personal. It's not even cultural, really — the culture just determines the flavor of the brusqueness. The behavior is structural. The job is designed to produce exactly the experience the prompt describes.
Which means the question isn't "why are these techs so grumpy?" The question is "what would it take to redesign the job so that the incentives align with good customer experience?
That's where it gets interesting, because the answer involves regulatory reform, union agreements, and a fundamental rethinking of what the technician's role actually is in a fiber world. But before we get to solutions, I think we need to look harder at what a typical day actually feels like from inside the van.
Let's do that. Let's walk through a day in the life — the routing, the quotas, the moments where the system collides with reality. Because once you see it from the tech's side, the gruffness stops looking like a mystery and starts looking like the only rational response to an impossible job.
We've established the structural recipe: brutal quotas, narrow training, metric-driven fear of callbacks, and a regulatory framework that forces truck rolls for what should be a database toggle. But I want to step back and frame the question the prompt is really asking, because it's more interesting than "why are these people grumpy.
It's: is this a personality problem or a systems problem?
The prompt already tips us toward the systems answer without quite naming it. The observation that the behavior is consistent — gruff, snappy, don't ask questions — across different techs, different cities, different ISPs. That's not a personality pattern. That's an output.
A personality pattern would show variance. Some techs would be chatty, some would be grumpy, some would be meticulous, some would be sloppy. But what users report is a remarkably narrow behavioral band. That screams incentive alignment, not individual disposition.
The three things we need to pull apart are: who actually ends up in this job and what they're taught, what a typical day looks like from the inside including the quota math and the routing pressure, and then why that combination reliably produces the behavior the prompt describes.
We've already started pulling on those threads, but I want to be explicit about the order, because each layer explains the next. The hiring pipeline and training set the ceiling on what the tech can do. The daily schedule sets the floor on what the tech has time to do. And the gap between those two — between capability and capacity — is where the gruffness lives.
The gap is the gruffness. The tech might actually know how to do what you're asking, but the schedule makes it impossible. Or the schedule might have slack today, but the training never covered it. Either way, the customer's request falls into the gap.
The prompt gives us a perfect case study for that gap. The fiber is already lit from the previous tenant. Same ISP, same service. The user is standing there thinking: this visit is theater. And the tech is standing there thinking: I have to do this visit or I don't get paid, and also I have nine more after it.
The user's specific context makes the absurdity sharper. This isn't a new installation. Nothing is being pulled, spliced, or mounted. The ONT is on the wall, blinking green. The previous tenant unplugged their router and left. The new tenant plugs in a router. That should be the end of it.
Yet legally it can't be. The Ministry of Communications regulation requires a physical activation signature. The tech has to visually confirm the termination point isn't damaged and match the ONT serial number to the system. Even if nothing changed. Even if the previous tenant disconnected service yesterday.
Which is the definition of technically redundant but legally mandatory. The regulation is protecting against a risk that, on fiber, barely exists. Copper lines corrode. Fiber doesn't. A visual inspection of a fiber termination catches almost nothing that a light-level reading at the OLT wouldn't already flag — and that reading happens automatically. The OLT constantly monitors signal strength from every ONT on the network. The physical inspection is solving a problem that remote telemetry already solved.
The truck roll is a regulatory fossil. And the tech is the one who has to live inside the fossil.
Now, is this behavior unique to Israel? The prompt seems to suspect it might be local — this is a very Israeli experience, the dugri communication style, the particular flavor of brusqueness. But we've already flagged that the same job design produces the same behavior everywhere. The dugri just removes the veneer. The refusal is the constant. The tone is the variable.
The unfiltered version is useful, actually. It makes the structural pressure more visible. When the German tech politely explains he can't help with your third-party router, you might think it's a policy choice. When the Israeli tech just says "lo, ani lo nogea bazeh" and turns his back, you feel the system.
"No, I don't touch that." Three seconds, no explanation, interaction over. It's almost a pure expression of the incentive structure. The explanation would take time he doesn't have, and the explanation wouldn't change the outcome, so why waste the words?
That's the thing the prompt is really circling. The user assumes an ISP technician understands networking, because that seems like a reasonable assumption. And the interaction shatters that assumption so completely that it forces you to ask: wait, who are these people and what do they actually know?
Which is exactly what we're going to map out. The hiring pipeline, the training curriculum, the daily routing, the quota pressure. And by the time we're done, the gruffness won't look like a mystery. It'll look like the only rational adaptation to a job that was never designed for the customer's benefit.
It was designed for the ISP's cost structure. The customer experience is a side effect. And the tech is the one who absorbs the friction between those two things. Every time a customer asks for something outside the script, the tech has to choose between his metrics and your satisfaction. The system is set up so that choosing your satisfaction costs him personally and gains him nothing.
Let's walk through who he is, what he learned, and what his day actually looks like. Because once you see the math, you can't unsee it.
The hiring pipeline is where the whole thing starts making sense. Most techs come from two tracks. First, the vocational high schools — ORT, Amal — where students pick a technical stream around tenth grade. Telecommunications is one of them, but it's broad. They're learning basic electronics, maybe some Cisco CCNA-lite material if the school is well-funded. Most aren't.
The second track is post-army. You finish your service, you're twenty-one, twenty-two, you need a job. The telecom companies recruit aggressively at army discharge fairs. They pitch it as a tech career — "work with cutting-edge fiber networks." What they don't say is that the cutting edge is a script on a tablet and a van with no air conditioning.
Some of the recruits are Mamram or Unit 8200 dropouts — people who trained for intelligence tech roles but didn't make the final cut. They've got more technical aptitude than the job requires, which makes them simultaneously overqualified and underprepared. Overqualified because they could probably learn bridge mode configuration in an afternoon. Underprepared because the job won't let them.
Two to four weeks of classroom training. The curriculum is entirely procedural. How to strip fiber, how to cleave it, how to use the fusion splicer, how to connect the ONT, how to run the setup wizard on the ISP router. They learn the physical layer and the device configuration layer. Nothing in between.
No OSI model. No DHCP internals beyond "it assigns addresses." If you asked a typical tech to explain what happens when your router sends a DHCP discover packet, you'd get a blank look. Not because they're unintelligent — because the training explicitly doesn't cover it.
That's by design. The ISP doesn't want network engineers in the field. Network engineers ask questions, suggest improvements, notice inefficiencies. Installation specialists follow the script and close the ticket. The training produces exactly what the business model needs.
The pay seals it. Seven thousand five hundred shekels a month on average — roughly two thousand one hundred dollars. Some are lower, around six thousand five hundred. Some push nine thousand if they're senior or working overtime. No bonuses tied to customer satisfaction. Some are contractors without benefits.
You've got a twenty-three-year-old with maybe a vocational diploma or a partial army tech background, four weeks of procedural training, making just above minimum wage, and the only thing between him and unemployment is his metrics. He's not paid to think. He's paid to close tickets.
Close them fast. The quota is the real architecture of the job. Ten to twelve jobs per eight-hour shift. In Tel Aviv, where traffic between neighborhoods can eat fifteen minutes easily, you're looking at twenty minutes on-site to do everything.
Twenty minutes to park — and parking in Tel Aviv is its own blood sport — find the building, get past the entrance code the customer forgot to provide, locate the telecom closet or the wall box, inspect the termination point, re-provision the port, connect and configure the ONT, set up the ISP router, confirm the Wi-Fi is broadcasting, get the signature, and leave. Then drive to the next one. Eleven more times.
The math is brutal. If you spend an extra five minutes on three jobs, you're half an hour behind by the end of the day. The last customer is waiting, angry, and you're working unpaid overtime. The system punishes thoroughness and rewards speed.
Which is why the gruffness is not a personality trait. It's time-management triage. Every word the tech says to you is a word he's not using to finish the job and get to the next one. The "don't ask questions" attitude is literally him protecting his schedule from conversation overhead.
The schedule is not just his problem. The routing is assigned by a central dispatcher who may or may not account for traffic, parking availability, or the fact that job number three is in a building where the elevator has been broken since 2019. The tech has no control over the order or the clustering. He gets the list and he executes.
Let's play out the case study. Tech in Tel Aviv, eleven jobs. Job number four is a customer who wants to use a Ubiquiti Dream Machine. The tech has no training on Ubiquiti. He's never seen the Dream Machine interface. He has no idea if it supports the ISP's VLAN tagging requirements or PPPoE credentials.
Even if he did know, he probably doesn't have the credentials to put the ONT in bridge mode. That setting is often locked behind a supervisor login or a back-end system he can't access from the field. His tablet lets him activate the port and register the ONT serial number. It doesn't let him change the ONT's operating mode.
The customer says "just put it in bridge mode and I'll handle the rest." The tech hears: "spend ten minutes navigating a menu I don't have access to, on equipment I'm not trained on, to enable a configuration that, if it fails, will generate a callback that counts against my record.
His next job is twenty minutes away and he's already five minutes behind. He says no. Not because he's mean. Because yes is all downside. Yes means delay, yes means callback risk, yes means possibly staying late without pay, yes means explaining to his supervisor why job number four took forty minutes instead of twenty.
The system has made "no" the only rational answer. And it's delivered without explanation because explanation takes time, and time is the one resource the system has stripped from him entirely.
The callback metric is the invisible whip in all of this. If the customer calls the ISP within forty-eight to seventy-two hours with any problem, it's logged as a failed installation. Even if the problem is the customer's own router. Even if the customer unplugged the ONT by accident. The tech's numbers take the hit.
Too many callbacks and the tech loses shifts, gets put on probation, or is let go. So the rational strategy is to minimize variables. Stick to the script, use only the ISP equipment, don't touch anything the customer brought. If it works with the ISP router, the ticket is clean. If the customer swaps in their own gear later and something breaks, that's a new ticket, not a callback.
That's the answer to the question the prompt keeps circling: why does someone who works with networks seem to not understand networking? It's not that they can't understand. It's that the job has selected for people who've learned not to exercise that understanding, and the ones who want to exercise it have already left.
The selection effect is real. The techs who are curious about networking, who would actually enjoy helping you configure your Dream Machine — those people leave within a year or two. They go to enterprise IT, or they move up to the ISP's NOC, or they start their own low-voltage contracting business. The field loses its best people constantly.
The ones who stay are the ones who've adapted to the quota system. They've learned to move fast, say no, not get drawn into conversations, not care too much about the customer's unusual setup. The job rewards compliance and punishes curiosity. Over time, that shapes who remains.
It's a filter that screens for exactly the behavior the prompt describes. The gruff, snappy, don't-ask-questions tech is not a broken version of the ideal tech. He's the ideal tech, as defined by the system that employs him.
The Ministry of Communications regulation — four point three point two — locks the whole thing in place. The physical activation requirement means the truck roll is mandatory even when the fiber is active and the ONT is already registered. The tech has to show up, visually inspect the termination point, confirm the serial number, and sign off. Even if nothing changed. Even if the previous tenant canceled service this morning.
The tech is driving across town to do something that a remote database update could accomplish, because a regulation written for copper phone lines hasn't been updated for fiber. And he's doing it ten times today.
Which is where the knock-on effect kick in. The quota system doesn't just make techs fast. It makes them develop scripts — not just the technical procedure, but the entire social interaction. "Where's the wall box?" "Wi-Fi password is on the sticker." Every word is pre-optimized. There's no improvisation because improvisation burns time.
It's the same thing you see in air traffic controllers or emergency room triage nurses. When the volume is high and the margin for error is zero, the brain automates everything it can. The "don't ask questions" attitude isn't rudeness — it's the tech protecting his mental bandwidth for the remaining seven jobs.
The router setup paradox is the perfect illustration. The ISP trains techs on exactly one or two router models with a documented setup wizard. When a customer says "I'll use my own," the tech hears "I need you to do something undocumented on equipment you've never seen, and if it doesn't work, the callback hits your record.
Even if the tech is technically curious and would enjoy figuring out your Dream Machine, the risk calculus is broken. If he sets up the ISP router and it works, his metrics are clean. If he helps you with your own equipment and something fails — even if it's your fault — the callback counts against him. The system punishes the exact behavior the customer wants.
The paradox is: the tech who says "sorry, I can't help with that" is behaving perfectly rationally. The tech who says "sure, let me take a look" is taking a personal risk for zero personal gain. The incentive structure has made helpfulness a liability.
This isn't just Israel. Let's look at how the same job plays out elsewhere, because the pattern is remarkably consistent once you control for the cultural overlay. In the US, Comcast and Spectrum techs have quotas of four to six jobs per day with sixty-to-ninety-minute windows. More time per job, but also more ground to cover — American suburbs are spread out in a way Israeli cities aren't.
The Comcast tech in Philadelphia has seventy-five minutes per job, but he might drive thirty of those minutes between stops. The Bezeq tech in Haifa has forty-five minutes total, but his next job is probably in the same neighborhood. The density changes the math, but the pressure is the same shape.
The equipment question plays out similarly. In the US, DOCSIS is more uniform than fiber ONT configurations. A Comcast tech can approve a customer-owned modem because the compatibility list is well-defined and the provisioning is standardized. But ask them to configure a third-party router behind that modem, and suddenly you're back in the same gap.
They'll activate the modem. They won't troubleshoot your Ubiquiti setup. The boundary is drawn in a slightly different place, but it's still a boundary.
Germany is the interesting counterexample. Deutsche Telekom techs are salaried — no per-job quota. They take their time, they explain things. The interactions are pleasant. But the tradeoff is wait time. Two to three weeks for an appointment is normal. When you remove the quota pressure, you also remove the throughput incentive, and the queue backs up.
You pick your poison. Israel gives you a tech tomorrow morning who acts like you're stealing minutes from his life. Germany gives you a tech in three weeks who'll sit down and have a coffee with you. The system design determines both the speed and the demeanor.
Japan is the one that really drives the point home. NTT technicians are legendary for politeness. They wear white gloves. They lay out little mats for their tools so they don't scratch your floor. And they will not, under any circumstances, touch non-NTT equipment. The refusal is absolute. It's just delivered with a bow instead of a grunt.
The rigidity is the constant. The tone is the variable. The Japanese tech bows and says "sumimasen, dekimasen." The Israeli tech shrugs and says "lo, ani lo nogea bazeh." Same answer, different soundtrack.
Which brings us to the cultural overlay in Israel specifically. Dugri communication — direct, blunt, no padding. In a high-context culture like Japan or the UK, "no" gets wrapped in fifteen words of apology and hedging. In Israel, "no" is one syllable and the conversation is over. What reads as rudeness to an English-speaking audience is often just the local efficiency dialect.
The tech isn't angry. He's just not performing emotional labor he's not compensated for. In a culture where softening language is considered wasteful rather than polite, the structural brusqueness of the job comes through unfiltered.
That's the structural insight this whole thing builds toward. The behavior the prompt describes — gruff, snappy, script-bound, resistant to anything non-standard — is not a personality flaw and it's not a cultural quirk. It's the output of a system designed to optimize for ticket closure speed and cost minimization. The job produces this person in every country. The culture just determines whether he scowls or bows while saying no.
The real question isn't "why are Israeli techs like this?" It's "why do we design the job this way everywhere, and what would it take to change it?
The answer to the first part is simple: because the ISP's cost structure treats the technician as a variable expense to be minimized, not a customer experience asset to be invested in. The answer to the second part is where it gets harder — regulatory reform, union renegotiation, and a fundamental rethink of what the role should be in a fiber world. But that's a whole other conversation.
For now, the practical takeaway is: when the tech shows up at your door, you're not dealing with a person in a bad mood. You're dealing with a person inside a system that has systematically stripped away every incentive to be helpful. Knowing that doesn't make the interaction warm, but it makes it legible.
The tech's standing in your doorway in about twenty minutes. What do you actually do with all of this?
First thing — have the ONT model number and your own router's MAC address written down somewhere. Not on your phone, not in an email you have to search for. On a piece of paper, or a sticky note on the wall next to the ONT. The tech is not going to wait while you dig through settings menus.
The MAC address is the thing he might actually need if the ISP's system requires device registration. Having it ready is a ten-second gift to his schedule, and he'll notice.
Second — ask him to put the ONT in bridge mode before he leaves. This is a standard request. He may act like it's not. He may say it's impossible. It's not impossible. Every ONT deployed by Israeli ISPs in the last five years supports bridge mode. The setting exists. Whether he has access to it or is willing to try is a different question, but the request itself is completely normal.
If he refuses — which he might, for all the structural reasons we just spent twenty minutes mapping — don't argue. Arguing burns his time and gets you nothing. Just let him finish the script, sign the tablet, let him leave.
Then call the ISP's business line — not the general support line, the business or technical line if you have it — and ask for technical escalation. The phone support team can remotely enable bridge mode on the ONT. They have access to the back-end configuration that the field tech's tablet doesn't. It might take twenty minutes on the phone, but it'll get done.
The fourth thing — and I'm serious about this — offer the tech a coffee or a cold drink. It's June in Israel. He's been in a van with questionable air conditioning since seven in the morning. A cold bottle of water or a coffee resets the interaction for about thirty seconds, and thirty seconds is enough time to ask one question while he's drinking it.
It's not bribery. It's just acknowledging that he's a human being inside a brutal system. And sometimes that acknowledgment is enough to get a little slack — maybe not bridge mode, but maybe he'll tell you which DNS servers the ISP uses, or confirm that the ONT supports your speed tier, or leave you a spare ethernet cable.
The broader takeaway for anyone listening: ISP technicians are not network engineers. They are installation specialists. Treat them like plumbers, not architects. A plumber will connect your pipes and make sure the water runs. He will not design your home's water pressure system or advise you on which filtration setup is optimal. Same deal here.
Have your own equipment pre-configured before the tech arrives. If you're planning to use your own router, set it up ahead of time — DHCP, LAN subnet, Wi-Fi SSIDs, everything. The tech's job is to get internet to the ONT. What happens after the ONT is your domain. Don't expect him to troubleshoot your gear.
The systemic piece — the thing that should change — is that the Ministry of Communications needs to update regulation four point three point two. Remote activation for same-ISP same-premises moves should be allowed. The physical inspection is a copper-era fossil. Fiber doesn't degrade the way copper does. If the OLT says the light level is good, the connection is good.
A regulatory update there would eliminate thousands of unnecessary truck rolls per month. That frees up tech time for actual new installations, reduces wait times, and takes the most absurd version of this interaction off the board entirely.
For anyone listening who's got an appointment coming up — check your ISP's policy on customer-owned equipment before the tech arrives. Some ISPs have a documented procedure. Some don't. Knowing which bucket you're in determines whether the conversation is "here's the form" or "I'll handle this myself after you leave.
The system isn't going to change before the doorbell rings. But knowing what you're looking at when you open the door — that changes the interaction. You're not dealing with a grumpy person. You're dealing with a person-shaped output of a quota machine.
Here's the question that sticks with me after all of this. XGS-PON is rolling out across the country — sixty-two percent of households as of March, according to the Ministry of Communications broadband report. Symmetric ten-gigabit fiber. The physical layer is becoming a commodity. At some point, does the technician role just evaporate?
It's a fair question. If the fiber is pre-installed in the building, the ONT is pre-provisioned, and the activation is essentially a software toggle, what's left for a human to do? You could imagine a world where the customer plugs in the ONT themselves, scans a QR code, and the provisioning happens automatically.
We're already seeing pieces of that. Some ISPs in South Korea and Singapore ship self-install kits where the ONT is pre-authorized and the customer just plugs it in. No truck roll
