How Can We Help?
Send a support request by email or on the form below. This page also covers what to put in it, when the desk is open, and what to do if a request stops moving.
Where to Send It
A fault, a first request and a piece of new work go to different places. All three reach the same team, and all three get a reply within 24 hours on a working day.
Something is broken
Write to sales@omegaswift.com. Put the system and the number of people stuck in the subject line. The mail opens a ticket, and the reply carries a reference you can quote from then on.
Send the form
The form is further down this page. Use it if you do not yet have a contact on our side, or if you would rather write the whole thing out in one go than start a mail thread.
New work or a question
A new build, a change to what was agreed, a quote, or a question about what you are paying for. Send those through the contact page and they reach the people who would do the work.
Write It Out Once
Use the message field for the whole story rather than a summary. Nothing you put in it is wasted. The detail that looks pointless to you is often the line that tells us which system we are looking at.
- 1The request lands in the same queue as an email and is given a reference.
- 2It is read and sorted against everything else waiting, by what has stopped.
- 3An engineer picks it up and replies to the address you gave us, quoting the reference.
Submit a Support Request
If you already work with us, name the system and the team it belongs to, so the request can be matched to the right agreement.
What to Put in a Fault Report
None of this is a form to fill in. It is what an engineer needs before they can start. Send it up front and the first reply moves the work forward instead of asking you a question and losing a day.
- Who is affected
- One person, one team, or every customer trying to place an order. That is what decides which request gets picked up first, so put it in the first line.
- What you were doing when it broke
- The page, the screen, the button, the order number. A fault that only shows up on one path is much quicker to find when we know the path.
- The exact error text
- Copied out as text if you can, or a screenshot of the whole window rather than a crop of the message. The address bar and the rest of the screen usually tell us which system we are in.
- When it started
- Roughly what time it first happened, and whether it has happened before. Logs are searched by time, so an hour is more useful to us than a day.
- What changed recently
- A release, a password reset, a new laptop, a plugin update, a change your own team made. Most faults follow a change, and naming it saves us a morning of guessing.
- How to reach you
- An email address somebody is actually watching today. If the fault is with your own login or mailbox, give us a second address as well.
When the Desk Is Open
- Monday to Friday
- 9:00 to 18:00 India Standard Time. Requests are read as they arrive and worked through the day by what has stopped, not by what arrived first.
- Outside those hours
- Cover outside the working day is agreed per client and written into your agreement. If yours includes it, the route named in it applies. If it does not, your request is queued and picked up the next working morning.
- Planned work
- Updates and releases run in windows agreed with you and are sent to you in advance. A system that is down during one of those windows is planned work rather than a fault.
If a Request Stops Moving
Pushing a request along is part of the process, not a complaint about it. The steps run in this order.
- 1
The request is logged and given a reference
Every request gets a reference and a priority. Quote that reference on anything you send afterwards so it joins the same thread instead of opening a second one that nobody connects to the first.
- 2
Say on the ticket that it needs to move
If the priority looks wrong to you, or nothing has happened for a day, reply on the ticket and say so plainly. Written on the ticket, it is visible to everyone looking at the queue. Said in a corridor, it is not.
- 3
Tell us what has actually stopped
Orders, invoices, sign ins, a delivery you cannot make. Naming the thing that has stopped moves a request faster than asking for it to be urgent, because it lets us compare it against everything else in the queue.
- 4
Escalate to your delivery contact
Your agreement names somebody on our side who owns delivery and somebody on yours who can approve. That pair is the route for anything still stuck, and for anything that needs a decision rather than a fix.