Business process automation, built as software that fits how you work.
When a process runs on email, spreadsheets and memory, the work of keeping it moving falls on people. AbharWorks builds the software that carries it: scoped in writing, built in stages, and checked against the scope.
The process exists. It lives in inboxes.
A request arrives by email and is copied into a spreadsheet. Approval is a reply from a manager, found later by searching. Someone keeps a list of what is waiting and chases it. The status of anything is learned by asking.
It works while the same few people are there and the volume is small. Then someone is away, a request is missed, and nobody can say where it stopped.
This is for you if
- a process that matters runs on email, spreadsheets and reminders;
- approvals are slow because nobody can see what is waiting for whom;
- the same details are entered more than once, by more than one person;
- customers or staff ask for a status that should be visible to them;
- ready-made software has been tried and your process did not fit it.
It is not for you if you have already chosen an automation product and need someone to configure it. The product's own partners do that.
What gets built
A web application around one process, with a view for each person who takes part in it.
Requests and approvals.
A request is made once, goes to the right person, and shows where it is until it is closed.
Scheduling and assignment.
Bookings, visits and tasks given to people or teams, with what is due and what is late in view.
Onboarding.
The steps a new customer, supplier or member of staff goes through, with the documents each step needs.
Records and documents.
What was submitted, who changed it and when, kept with the case it belongs to.
Status and reporting.
What is open, how long each step takes, and where work waits, without anyone compiling it by hand.
The process first, then the software
Automating a process as it stands also automates what is wrong with it. So the work starts on paper.
- 1
Fit call. Which process, who takes part in it, and what it costs you today. If it is not a fit, you will hear that on the call.
- 2
The process as it is. Every step, who does it, what they need, and the exceptions that nobody mentions until asked.
- 3
What to remove before building. Steps that exist only because of the spreadsheet are dropped, not rebuilt.
- 4
A written scope. What is in, what is out, and how each item will be accepted as done. You approve it before work starts.
- 5
Build in stages. You see working software as it progresses, and the people who will use it try it early.
- 6
Measured. A baseline before, a comparison after: how long a request takes, how many are waiting.
If the process has to exchange data with systems you already run, that is scoped with it: see API and systems integration.
What this is, and what it is not
This is software development. What we commit to is a product built to the written scope, checked item by item against what was agreed, and handed over so you can run and extend it. It is not the sale or set-up of an automation product, and it comes with no promise of a specific saving: what it saves is measured afterwards, against the baseline.
Common questions
- Why build software when automation products exist?
- If a product fits your process, use it. This is for a process that does not fit one, or that is central enough to be worth owning.
- Can it start with one process?
- It should. One process, scoped and delivered, before a second is considered.
- Will it work with the systems we already have?
- Where they offer a way to exchange data, yes. What is possible is checked before the scope is written.
- How much will it cost?
- It depends on the scope, which is why the scope is written first. You get a fixed figure for an agreed scope, not an open-ended estimate.
- Can it be in Arabic and English?
- Yes. Multilingual products, including Arabic, are a regular part of the work.