I'm pretty familiar with Windows Failover Clustering. It is a large chunk of admin work and budget (if actually fault tolerant. i.e. no using a single SMB3 file server for shared storage). It
frequently weekly or monthly fails over for no discernible reason. When it fails over, service is lost for a few moments while the new active server takes over the resources (IP address, disk, etc.). The ongoing maintenance is irritating because some settings must be setup on each machine. This can require failing the server over and repeating config changes. Some things support shared configuration, avoiding this. (e.g. IIS, however IIS is not natively clusterable and requires setting up a script to migrate it between servers)
All that to say, be sure your company is aware of the costs before deciding to go this route.
A slightly less involved option is Network Load Balancing (NLB). You can use it as active/active. It will handle failures and avoid failed servers. It does not require shared storage as failover clustering does. Bear in mind that it's designed for load balancing, not availability. You can set it up for an active/passive type of scenario by giving one server full priority, but split-brain may be possible there. There could also be some network level adjustments required, depending on how you set up NLB.
There also exists the DNS Round Robin approach where you essentially setup a DNS record that points to multiple IP addresses. Each IP address belonging to a different server with your service installed. The DNS server returns the IP addresses in rotating order. But the viability of this depends heavily on the client's implementation. Often, the client's system will pick one and cache the result. This can lead to perceived downtime because the particular server that the client cached could be the one that's down.
In any case, your service really needs to be setup to be stateless. Otherwise, the next request could be handled by a server which is unaware of the user's previous session on a different server. (State could be centralized, but again it would need to be in the cluster so it wasn't a single point of failure. You'll notice clustering is a black hole which absorbs surrounding concerns too. Speaking of which...)
None of this addresses other single points of failure, like network, database, hardware drivers (yes drivers... some people go as far as getting different hardware from different manufacturers to ensure that a driver or hardware bug doesn't impact all systems).
You could also look at taking advantage of a cloud offering for redundancy, like Azure in the MS world. There is too much to list on this topic, but these services tend to offer a number of high availability features including at the network, storage, and database levels.
I'm sure this is not a complete list of your options. And as always none of them are strictly "better"... there are trade-offs.
I also thought of hardware load balancers. It's a network device like a router or switch with servers plugged into it. But the basic idea is that it listens on an IP, and requests to that IP get forwarded to the connected servers in an alternating manner. Only using one load balancer is a single point of failure, since it is one device that can cut off access if it fails. In order to do redundant load balancers, you need redundant network paths and a routing protocol which can handle that.